It seems that C++ programming can be cumbersome for some users. Well, OTB allows you to work also in other programming languages as for instance Python. The Pylab Project which gathers numeric and scientific Python packages such as NumPy, SciPy and Matplotlib is considered as having the same features as some commercial scientific environments. Some people consider that Pylab is even more powerful than these commercial tools, since you get for free the power of a full featured and general purpose programming language as Python.

Recently I needed to quickly plot the temporal profiles of several pixels coming from temporal image series in order to easily assess the impact of a correction algorithm. I have to admit that my first idea was to generate simple ASCII files with the pixel values and then feed these files to Gnuplot. However, I found a more elegant (at least from my point of view) way to do this.

I use the OTB Python bindings in order to read my images (2 GeoTiff files with 49 bands each). Using the “GetPixel” method, I access the pixels I want to plot. Finally I use pylab to plot 2 temporal profiles (before and after correction). Here goes the code.

import sys

if( len(sys.argv) != 5):
    print("Usage: "+sys.argv[0]+" series1 series2 x0 y0")
    exit()

import itk
import otbImages
import otbIO
import pylab

# Types

ImageType = otbImages.VectorImage[itk.D, 2]
ReaderType = otbIO.ImageFileReader[ImageType]

# Pixel coordinates

index = itk.Index[2]()
index[0] = int(sys.argv[3])
index[1] = int(sys.argv[4])

# Import first series
readerBefore = ReaderType.New()
readerBefore.SetFileName(sys.argv[1])
readerBefore.Update()

pixBefore = readerBefore.GetOutput().GetPixel( index )

# Import second series
readerAfter = ReaderType.New()
readerAfter.SetFileName(sys.argv[2])
readerAfter.Update()

pixAfter = readerAfter.GetOutput().GetPixel( index )

# Chek that both series have the same length

if( pixBefore.GetSize() != pixAfter.GetSize() ):
    print("Series have different lengths")
    exit()

# Plot

vectorBefore = \
 [pixBefore.GetElement(i) for i in range(pixBefore.GetSize())]
vectorAfter = \
 [pixAfter.GetElement(i) for i in range(pixAfter.GetSize())]

pylab.xlabel("Date")
pylab.ylabel("Reflectance")
pylab.plot(vectorBefore, label="Raw")
pylab.plot(vectorAfter, label="Clean")
pylab.legend(loc='upper left', shadow=True)
pylab.show()

And here you can see a result example.

Temporal profiles

Of course, you can imagine to make this script a little bit more interactive in order to choose other pixel coordinates, etc., but I hope you grasp the power of this approach. By using the OTB Python bindings and other freely available open source Python goodies (NumPy, SciPy, Matplotlib, rpy) you get the user friendly approach of Octave, Scilab and their commercial counterparts plus the power of OTB (which in turn makes available ITK, OSSIM, etc.).

Isn’t it great?

Generating a patch is not straightforward for the user (he needs to compare with the original version if he still has it) and worst, he doesn’t get the benefits of version control systems.

On the other side, the project member integrating the patch has to find the correct version against which the patch applies, he has to fight with the line breaks if the patch was submitted by email.

The more obvious solution is to give access to the version control system to the potential contributors: this way, they can fully contribute and the integration is easy. But that raises another question: do you really want anybody to be able to put his/her contribution without any check? Sometimes, the contribution could break another capabilities, sometimes a different solution to fix the problem might be more appropriate, sometimes, this is not the time to integrate risky modifications… That the case why in most open source projects, the core team of people with commit access is limited.

With the availability of distributed VCS (mercurial, git, bazar), part of this problem disappear: the user can work locally and benefit from the VCS, it also makes the patch generation easier. But there is still the problem of sharing. The main argument of the DVCS is that a contributor can go out and say “hey guys, here is my cool version, come and pull from it”, but that involve him setting up a public repository. Unlikely if he is just interested in using the program and on his way fixed a bug.

To make this process easier, we’ve just created a “sandbox” repository for OTB which works as a testing environment that isolates untested code changes and outright experimentation from the production environment or repository. Here is how it works:

1. Clone the main OTB repository:

   hg clone http://hg.orfeo-toolbox.org/OTB

   as normal

2. Set up your mercurial identity, in Linux, edit the ~/.hgrc and put the following lines:

   [ui]
   username = Your Name <email-where-we-can@contact.you>

3. work as usual, commit locally as you would do for your own project
4. when you are happy, push to the sandbox

   hg push http://hg.orfeo-toolbox.org/OTB-SandBox

   If necessary, use the -f option (we will sort out the mess). When ask for the login use “anonymous” with the password “otb”.

5. We will be informed that something new is in the sandbox, but you can also drop a mail at otb-users@googlegroups.com to provide more explanations.
6. We will then review the corrections, test them and then merge them into the main repository.

This way, the fix, the new capability, etc will be maintain in the upcoming version of OTB. And also, the user will have the chance to appear in our latest codeswarm.

It’s just as usual: download it from http://www.orfeo-toolbox.org/otblive/, burn it on a CD, put it on a computer and restart.

This is the screen you should get:

OTB Live CD desktop

To help you get started with OTB, follow the guide on the help page:

OTB live CD, help page

You can also try the numerous applications directly out of the box:

OTB live CD, example of applications

Now, a few more word on what’s going on behind the scene to build this CD. All this process is coming from various sources (Gnu Linux Magazine France, several websites, tons of trial and errors).

First, you need to get the iso image from the latest xubuntu (www.xubuntu.org). We are going to unpack all this to be able to work on it. Go into your working directory (start from a clean one, you’ll be putting a lot of mess there), and make sure you have at least 5GB free.

mkdir mnt
sudo mount -o loop xubuntu-8.10-desktop-i386.iso mnt

mkdir extract-cd
rsync --exclude=/casper/filesystem.squashfs -a mnt/ extract-cd

sudo modprobe squashfs
mkdir squashfs
sudo mount -t squashfs -o loop mnt/casper/filesystem.squashfs squashfs

mkdir edit
sudo cp -a squashfs/* edit/

sudo umount squashfs
sudo umount mnt

Now, you have unpacked all the system, you can ‘chroot’ yourself on it:

sudo cp /etc/resolv.conf edit/etc/
sudo cp /etc/hosts edit/etc/

sudo chroot edit
mount -t proc none /proc
mount -t sysfs none /sys
export LC_ALL=C

Here, you are root on the live cd system, all the command you pass in this environment won’t affect your own computer. The few lines above are required every time you have to go in the chroot environment. Some of the modification below will require you to go in and out. In this case, it’s better to keep two terminals open.

Now that we are here, we need to make some space for OTB. Don’t forget that everything has to fit on 700MB. Actually as the filesystem is compressed (squashfs), you can count on around 2GB.

aptitude update
dpkg-query -W --showformat='${Installed-Size} ${Package}\n'| sort -nr | less
aptitude remove --purge thunderbird
aptitude remove --purge gnome-games-extra-data gnome-games gnome-games-data gnome-games-servers
aptitude remove --purge gimp gimp-data gimp-help-common gimp-help-en libgimp2.0
aptitude remove --purge gnumeric-common gnumeric-doc gnumeric-gtk gnumeric-plugins-extra gnumeric

You can choose what you want according to your own taste. One part which is quite space consuming is the localization packages. They can be removed by:

aptitude remove --purge `dpkg-query -W --showformat='${Package}\n' | grep language-pack | egrep -v '\-(en|fr)'`

Usually, I keep only the two official languages for OTB: English and French.

Now we need to remove some libraries which became unused:

vim /etc/apt/sources.list

Uncomment the two lines:

#deb http://archive.ubuntu.com/ubuntu intrepid universe
#deb-src http://archive.ubuntu.com/ubuntu intrepid universe

and run deborphan:

aptitude update
aptitude install gedit
aptitude install deborphan

aptitude remove --purge `deborphan`
aptitude remove --purge `deborphan`
aptitude remove --purge `deborphan`

It’s time to fill up some of the space we’ve just freed and install the libraries necessary for OTB:

aptitude install libglu1-mesa-dev
aptitude install cmake g++ libgdal1-1.5.0 libgdal1-dev libfltk1.1 libfltk1.1-dev fluid libcurl4-gnutls-dev libfftw3-dev
ln -s /usr/lib/libgdal1.5.0.so  /usr/lib/libgdal.so
mkdir /otb

From outside of the chroot (normal environment), you can copy OTB sources and documentation:

sudo cp -r OrfeoToolbox-2.6.0 edit/otb
sudo cp -r OrfeoApplications-2.6.0 edit/otb
sudo cp OTBSoftwareGuide-2.6.pdf edit/otb
sudo cp -r Doxygen/ edit/otb/

Now, in the chroot, you can compile OTB libs and applications:

cd otb
mkdir OTB-Binary
mkdir OTB-Binary-Applications
cd OTB-Binary
ccmake ../OrfeoToolbox-2.6.0/

c
CMAKE_BUILD_TYPE -> Release
OTB_USE_CURL -> ON
USE_FFTWD -> ON
c
g

make -j 2

cd ../OTB-Binary-Applications
ccmake ../OrfeoApplications-2.6.0/
c
e
OTB_DIR -> /otb/OTB-Binary/
CMAKE_BUILD_TYPE -> Release
c
c
g

make -j 2

Now, you have all the basic ready. In another post later on, we may cover some personalization issues (start logo, splash screens, etc).

We are now going to build the CD. Before that, clean the mess you’ve create on the chroot (you don’t want your typos to be burnt on hundreds of CDs around the world):

aptitude clean
rm -rf /tmp/*
rm /etc/resolv.conf
echo "127.0.0.1 localhost" > /etc/hosts
umount /proc
umount /sys
rm -rf ~/.bash_history
exit

We are now going to update the list of packages on the live CD:

chmod +w extract-cd/casper/filesystem.manifest
sudo chroot edit dpkg-query -W --showformat='${Package} ${Version}\n' > extract-cd/casper/filesystem.manifest
sudo cp extract-cd/casper/filesystem.manifest extract-cd/casper/filesystem.manifest-desktop
sudo sed -ie '/ubiquity/d' extract-cd/casper/filesystem.manifest-desktop

Then we need to rebuild the compressed filesystem:

sudo rm -rf extract-cd/casper/filesystem.squashfs
sudo mksquashfs edit extract-cd/casper/filesystem.squashfs

Add the checksum:

sudo -s
rm extract-cd/md5sum.txt
(cd extract-cd && find . -type f -print0 | xargs -0 md5sum > md5sum.txt)
exit

And build the iso image:

cd extract-cd
sudo genisoimage -r -V "OTB Live 2.6.0" -publisher "Somebody" -p "You" -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o ../otblive-2.6.0.iso .
cd ..

Now you have the image, you can give it a try before burning it by using qemu/kvm:

kvm -cdrom otblive-2.6.0.iso -boot d -m 512

All this process should be working quite well, it has be tested with Xubuntu 8.10 Intrepid, 8.04 Hardy, 7.10 Gutsy and with OTB 2.0, 2.2, 2.5 (unofficial) and 2.6. The hardest part is usually to be able to fit everything on the 700MB of the CD. Using a live USB key is a relief, but more on that later…