Posts tagged "tricks":
Installing OTB has never been so easy
You've heard about the Orfeo Toolbox library and its wonders, but urban legends say that it is difficult to install. Don't believe that. Maybe it was difficult to install, but this is not the case anymore.
Thanks to the heroic work of the OTB core development team, installing OTB has never been so easy. In this post, you will find the step-by-step procedure to compile OTB from source on a Debian 8.0 Jessie GNU/Linux distribution.
Prepare the user account
I assume that you have a fresh install. The procedure below has been tested in a virtual machine running under VirtualBox. The virtual machine was installed from scratch using the official netinst ISO image.
During the installation, I created a user named otb
that I will use
for the tutorial below. For simplicity, I give this user root
privileges in order to install some packages. This can be done as
follows. Log in as root or use the command:
su -
You can then edit the /etc/sudoers
file by using the following
command:
visudo
This will open the file with the nano
text editor. Scroll down to
the lines containing
# User privilege specification root ALL=(ALL:ALL) ALL
and copy the second line and below and replace root
by otb
:
otb ALL=(ALL:ALL) ALL
Write the file and quit by doing C^o
ENTER
C^x
.
Log out and log in as otb
. You are set!
System dependencies
Now, let's install some packages needed to compile OTB. Open a
terminal and use aptitude
to install what we need:
sudo aptitude install mercurial \ cmake-curses-gui build-essential \ qt4-dev-tools libqt4-core \ libqt4-dev libboost1.55-dev \ zlib1g-dev libopencv-dev curl \ libcurl4-openssl-dev swig \ libpython-dev
Get OTB source code
We will install OTB in its own directory. So from your $HOME
directory create a directory named OTB
and go into it:
mkdir OTB
cd OTB
Now, get the OTB sources by cloning the repository (depending on your network speed, this may take several minutes):
hg clone http://hg.orfeo-toolbox.org/OTB
This will create a directory named OTB
(so in my case, this is
/home/otb/OTB/OTB
).
Using mercurial commands, you can choose a particular version or you can go bleeding edge. You will at least need the first release candidate for OTB-5.0, which you can get with the following commands:
cd OTB hg update 5.0.0-rc1 cd ../
Get OTB dependencies
OTB's SuperBuild is a procedure which deals with all external libraries needed by OTB which may not be available through your Linux package manager. It is able to download source code, configure and install many external libraries automatically.
Since the download process may fail due to servers which are not
maintained by the OTB team, a big tarball has been prepared for you.
From the $HOME/OTB
directory, do the following:
wget https://www.orfeo-toolbox.org/packages/SuperBuild-archives.tar.bz2 tar xvjf SuperBuild-archives.tar.bz2
The download step can be looooong. Be patient. Go jogging or something.
Compile OTB
Once you have downloaded and extracted the external dependencies, you
can start compiling OTB. From the $HOME/OTB
directory, create the
directory where OTB will be built:
mkdir -p SuperBuild/OTB
At the end of the compilation, the $HOME/OTB/SuperBuild/
directory
will contain a classical bin/
, lib/
, include/
and share/
directory tree. The $HOME/OTB/SuperBuild/OTB/
is where the
configuration and compilation of OTB and all the dependencies will be
stored.
Go into this directory:
cd SuperBuild/OTB
Now we can configure OTB using the cmake
tool. Since you are on a
recent GNU/Linux distribution, you can tell the compiler to use the
most recent C++ standard, which can give you some benefits even if OTB
still does not use it. We will also compile using the Release
option
(optimisations). The Python wrapping will be useful with the OTB
Applications. We also tell cmake
where the external dependencies
are. The options chosen below for OpenJPEG make OTB use the gdal
implementation.
cmake \ -DCMAKE_CXX_FLAGS:STRING=-std=c++14 \ -DOTB_WRAP_PYTHON:BOOL=ON \ -DCMAKE_BUILD_TYPE:STRING=Release \ -DCMAKE_INSTALL_PREFIX:PATH=/home/otb/OTB/SuperBuild/ \ -DDOWNLOAD_LOCATION:PATH=/home/otb/OTB/SuperBuild-archives/ \ -DOTB_USE_OPENJPEG:BOOL=ON \ -DUSE_SYSTEM_OPENJPEG:BOOL=OFF \ ../../OTB/SuperBuild/
After the configuration, you should be able to compile. I have 4 cores
in my machine, so I use the -j4
option for make
. Adjust the value
to your configuration:
make -j4
This will take some time since there are many libraries which are going to be built. Time for a marathon.
Test your installation
Everything should be compiled and available now. You can set up some
environment variables for an easier use of OTB. You can for instance
add the following lines at the end of $HOME/.bashrc
:
export OTB_HOME=${HOME}/OTB/SuperBuild export PATH=${OTB_HOME}/bin:$PATH export LD_LIBRARY_PATH=${OTB_HOME}/lib
You can now open a new terminal for this to take effect or use:
cd source .bashrc
You should now be able to use the OTB Applications. For instance, the command:
otbcli_BandMath
should display the documentation for the BandMath application.
Another way to run the applications, is using the command line application launcher as follows:
otbApplicationLauncherCommandLine BandMath $OTB_HOME/lib/otb/applications/
Conclusion
The SuperBuild procedure allows to easily install OTB without having to deal with different combinations of versions for the external dependencies (TIFF, GEOTIFF, OSSIM, GDAL, ITK, etc.).
This means that once you have cmake
and a compiler, you are pretty
much set. QT4 and Python are optional things which will be useful for
the applications, but they are not required for a base OTB
installation.
I am very grateful to the OTB core development team (Julien, Manuel, Guillaume, the other Julien, Mickaƫl, and maybe others that I forget) for their efforts in the work done for the modularisation and the development of the SuperBuild procedure. This is the kind of thing which is not easy to see from the outside, but makes OTB go forward steadily and makes it a very mature and powerful software.
xdg-open or "computer, do what I mean"
Command line nerds1 say that graphical user interfaces are less efficient since the former use the keyboard and the latter tend to need the use of the mouse.
Graphical user interface fans say that command line based work-flows need the user to know more things about the system. Although I don't see why this would be an issue (what's the problem with getting to know better the system you use every day?), I can see one clear advantage to the point-and-click work-flow.
When the user wants to open a file, double-clicking on it just works. On the other hand, on the command line, the user needs to call the appropriate application and pass the file name as argument:
evince my_document.pdf
That means that the user has to know which is the application that is going to correctly deal with the given file. For example, this won't work:
evince my_movie.mp4
because evince
is a document viewer and it only understands formats
as pdf
, postscript
, dejavu
or dvi
, but it is not able to
understand MPEG-4
videos.
So how can one replicate the point-and-click behavior on the command line? It would be nice to have something like:
open my_file
and that auto-magically the appropriate application was chosen.
It is of course possible, and it can be done in the same way as the graphical desktop environment does it: using xdg-utils.
Inside a desktop environment (e.g. GNOME, KDE, or Xfce), xdg-open simply passes the arguments to that desktop environment's file-opener application (gvfs-open, kde-open, or exo-open, respectively), which means that the associations are left up to the desktop environment. Therefore, on the command line, one can do:
xdg-open my_file.pdf
and the appropriate application will be used (evince
on GNOME,
okular
on KDE, etc.).
When no desktop environment is detected (for example when one runs a standalone window manager, e.g. stumpwm), xdg-open will use its own configuration files.
Sometimes, the default associations between applications and file
types may not suit the user. For instance, in my case, MPEG-4
videos
were open with mplayer
, but I prefer vlc
. The xdg-mime
tool is
meant to help you change the default associations:
xdg-mime default vlc.desktop video/mp4
The vlc.desktop
parameter is an xdg
desktop file which describes
the vlc
applications. On my Debian GNU/Linux system, this files are
located in /usr/share/applications
. So I was able to look in there
to see what applications xdg-open
could use.
The parameter video/mp4
passed to xdg-mime
is the type of file we
want to associate the application with. In order to know what type of
file we are dealing with, xdg-mime
can query it for you:
xdg-mime query my_movie.mp4
And the answer is:
video/mp4
Now, what happens if there is no desktop file for an application I want to use? For instance, remote sensing image visualization is not possible with the standard image viewers available on GNU/Linux. I personally use the OTB IceViewer, which is a lightweight application using the rendering engine developed for Monteverdi2.
In this case, I have to create a desktop file for the application. I
my case, I have created the otbice.desktop
file in
/home/inglada/.local/share/applications/
with the following contents:
[Desktop Entry] Type=Application Name=OTB Ice Viewer Exec=/home/inglada/OTB/builds/Ice/bin/otbiceviewer %U Icon=otb-logo Terminal=false Categories=Graphics;2DGraphics;RasterGraphics; MimeType=image/bmp;image/gif;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-xbitmap;image/tiff;image/jpeg;image/png;image/x-xpixmap;image/jp2;image/jpeg2000;
The file has to be executable, so I have to do:
chmod +x /home/inglada/.local/share/applications/otbice.desktop
After that, I can associate the IceViewer with the image formats I want:
xdg-mime default otbice.desktop image/tiff
And it just works.
Watching YouTube without a browser
The other day I was curious about how many streaming video sites among those I usually visit had made the move from flash to HTML5.
The main reason is that my virtual Richard Stallman keeps telling me that I am evil, so I wanted to remove the flash plug-in from my machine.
An the fact is that many sites have not switched yet. As far as I understand, YouTube has, at least partially. Therefore, the title of this post is somewhat misleading.
I have been using youtube-dl for a while now in order to download videos from many sites as YouTube, Vimeo, etc. My first idea was therefore to pipe the output of youtube-dl to a video player supporting the appropriate format. Since I usually use vlc I just tried:
youtube-dl -o - <url of the video> | vlc -
This works fine, but has the drawback of needing to manually type (or copy-paste) the URL of the video. So the command line on a terminal emulator is not what I find convenient.
Most of the video URLs I access come to me via e-mail, and I read e-mail with Gnus inside Emacs, I decided that an Emacs command would do the trick. So I put this inside my .emacs:
(defun play-youtube-video (url) (interactive "sURL: ") (shell-command (concat "youtube-dl -o - " url " | vlc -")))
This way, M-x play-youtube-video, asks me for an URL and plays the video. So, when I have an URL for a video on an e-mail (or any other text document on Emacs) I just copy the URL with the appropriate Emacs key stroke and call this command. For convenience, I have mapped it to key binding:
(global-set-key (kbd "<f9> Y") 'play-youtube-video)
So this is good, though not yet frictionless.
Sometimes, the video URL will appear on an HTML buffer, either when I am browsing the web inside Emacs with w3m or when the e-mail I am reading is sent in HTML1. In this case, I don't need to manually copy the URL and I just can ask w3m to do the work.
(defun w3m-play-youtube-video () (interactive) (play-youtube-video (w3m-print-this-url (point)))) (global-set-key (kbd "<f9> y") 'w3m-play-youtube-video)
So far, this has been working fine for me and I don't have the ugly non-free flash plug-in installed, and VRMS is happier than before.
Footnotes:
I use w3m as HTML renderer for Gnus with (setq mm-text-html-renderer 'w3m)
.
Finding commands and key bindings in GNU/Emacs
Since I use GNU/Emacs for everything, I can't remember all the key
bindings for all the different modes (org-mode, gnus, geiser,
etc.). So I often use the command names using M-x command-name
.
Sometimes, I don't even remember the exact name of the command and I
will use the TAB completion to see suggestions. But for that, I need
to remember the beginning of the name of the command. If I remember a
part of the name of the command, say, find, typing M-x --find
followed by TAB will propose all available commands whose name
contains find.
So far so good.
If I don't know at all the name of the command, there are a couple of
things that I can do. One would be browsing the menus in the menu
bar, but since my menu bar is hidden1 in order to increase
screen real estate, I would need to show it (M-x menu-bar-mode
),
and grab the mouse. Instead, pressing F10
, a pop-up menu which can
be keyboard driven appears and I can browse the menus.
I only would do this if I was bored, but this is rarely the case, so
I prefer another possibility. I use C-h m
, which is bound to the
describe-mode
command which displays the documentation for all
active modes for the current buffer.
In this documentation there is a table showing all the available key bindings and the corresponding commands. When in an org-mode buffer I get this:
key binding --- ------- C-a org-beginning-of-line C-c Prefix Command C-e org-end-of-line TAB org-cycle C-j org-return-indent C-k org-kill-line RET org-return C-y org-yank ESC Prefix Command | org-force-self-insert ...
Usually, this allows me to find the command I need and recall (at least for 5 minutes) the corresponding key binding.
If I am not sure if a command does what I need, I can always use the
describe-function
(bound to C-h f
) command to get its
documentation. If I invoke the command with the cursor on one of the
commands of the table above, this will be used as default command to
be described by describe-function
.
Nice and efficient.
Footnotes:
I have (menu-bar-mode -1)
in my .emacs
.