Convert images sequence from one format to another

for i = 1:942

filename_in = sprintf('/home/gaipaul/Desktop/data/logitech/%08d.jpg',i);
I = imread(filename_in);
Ig = rgb2gray(I);
Ig = imresize(Ig,0.3);
filename_out = ['/home/gaipaul/Desktop/data/logitech/gray/' int2str(i) '.pgm'];
imwrite(Ig,filename_out);

end

Smooth scrolling - Emacs hackery

Emacs mouse wheel scrolling can be abrupt or "jumpy" and cause one to lose their tracking. This is a hack that rebinds the mouse wheels to some functions that scroll one line at a time, pausing for a slight delay between each scroll. The times are tweakable to achieve different effects (like a scroll that slows down as it nears the end of its duration):

(defun smooth-scroll (increment)
(scroll-up increment) (sit-for 0.05)
(scroll-up increment) (sit-for 0.02)
(scroll-up increment) (sit-for 0.02)
(scroll-up increment) (sit-for 0.05)
(scroll-up increment) (sit-for 0.06)
(scroll-up increment))

(global-set-key [(mouse-5)] '(lambda () (interactive) (smooth-scroll 1)))
(global-set-key [(mouse-4)] '(lambda () (interactive) (smooth-scroll -1)))



A more generic function is as follows, though it cannot pause for variable lengths of time. You could use this if you want to more easily change the number of lines scrolled:

(defun smooth-scroll (number-lines increment)
(if (= 0 number-lines)
t
(progn
(sit-for 0.02)
(scroll-up increment)
(smooth-scroll (- number-lines 1) increment))))

(global-set-key [(mouse-5)] '(lambda () (interactive) (smooth-scroll 6 1)))
(global-set-key [(mouse-4)] '(lambda () (interactive) (smooth-scroll 6 -1)))



I have only tested these on GNU Emacs (version 23.0.60). If they do not work on XEmacs, I would appreciate any tips you could send me. Write me at "dzwell at [this domain]".

Making movies from image files using ffmpeg/mencoder

+convert all our images to jpeg's
for f in *ppm ; do convert -quality 100 $f `basename $f ppm`jpg; done

+encode the images files into a movie using either mencoder or ffmpeg
 mencoder "mf://*.jpg" -mf fps=10 -o test.avi -ovc lavc
                             -lavcopts vcodec=msmpeg4v2:vbitrate=800
 ffmpeg -r 10 -b 1800 -i %03d.jpg test1800.mp4

Using gdb/ddd to debug child processes

If you have tried to debug a child process using ddd, you may have noticed that ddd steps into the parent (and not the child) after the call to fork(). It is possible to debug the child as well, but it requires a special procedure. Since the child is a seperate process, it will require a second debugger window, and we will make use of gdb's ability to "attach" to a process which is already running.

Before you start, you must do the following:

• Make sure your call to fork() assigns a value to some variable so you can read it easily, e.g. "pid = fork()".
• Make sure you place a sleep() statement in the child as the first line of code after the fork(), e.g. "sleep(60)" [make the sleep() long enough for step 4 below ...]. The sleep() statment can be removed once debugging is complete.
• Compile your program with the "-g" option set, e.g. gcc myProg.c -o myProg -g

Now you are ready to start:

1. Start 2 copies of ddd in the background, like "ddd myProg & ddd myProg &". It is important that the two copies being running concurrently.
2. Pick (arbitrarily) one window to be the "parent" and set a breakpoint after the call to fork() (but not in any code the child will be executing ... that is, set the breakpoint somewhere in the parent's code ... if you set the breakpoint in the child's code, DDD will kill the child as soon as it is created!).
3. Run the parent to the breakpoint. Note the value returned by fork(), i.e. the process ID of the child.
4. In the "child" window, type "attach " in the gdb console window where is the child's process ID. Note: the gdb console is found at the bottom of the ddd window; this is where you can type commands directly to gdb.
5. Set a breakpoint in the child after the sleep() statement, and click on "cont" (in the popup "Command Tool" window) to allow the child to continue execution to the breakpoint.

Shared libraries and static libraries

3.2 Shared libraries and static libraries

Although the example program above has been successfully compiled and linked, a final step is needed before being able to load and run the executable file.

If an attempt is made to start the executable directly, the following error will occur on most systems:

$ ./a.out
./a.out: error while loading shared libraries:
libgdbm.so.3: cannot open shared object file:
No such file or directory

This is because the GDBM package provides a shared library. This type of library requires special treatment--it must be loaded from disk before the executable will run.

External libraries are usually provided in two forms: static libraries and shared libraries. Static libraries are the ‘.a’ files seen earlier. When a program is linked against a static library, the machine code from the object files for any external functions used by the program is copied from the library into the final executable.

Shared libraries are handled with a more advanced form of linking, which makes the executable file smaller. They use the extension ‘.so’, which stands for shared object.

An executable file linked against a shared library contains only a small table of the functions it requires, instead of the complete machine code from the object files for the external functions. Before the executable file starts running, the machine code for the external functions is copied into memory from the shared library file on disk by the operating system--a process referred to as dynamic linking.

Dynamic linking makes executable files smaller and saves disk space, because one copy of a library can be shared between multiple programs. Most operating systems also provide a virtual memory mechanism which allows one copy of a shared library in physical memory to be used by all running programs, saving memory as well as disk space.

Furthermore, shared libraries make it possible to update a library without recompiling the programs which use it (provided the interface to the library does not change).

Because of these advantages gcc compiles programs to use shared libraries by default on most systems, if they are available. Whenever a static library ‘libNAME.a’ would be used for linking with the option -lNAME the compiler first checks for an alternative shared library with the same name and a ‘.so’ extension.

In this case, when the compiler searches for the ‘libgdbm’ library in the link path, it finds the following two files in the directory ‘/opt/gdbm-1.8.3/lib’:

$ cd /opt/gdbm-1.8.3/lib
$ ls libgdbm.*
libgdbm.a  libgdbm.so

Consequently, the ‘libgdbm.so’ shared object file is used in preference to the ‘libgdbm.a’ static library.

However, when the executable file is started its loader function must find the shared library in order to load it into memory. By default the loader searches for shared libraries only in a predefined set of system directories, such as ‘/usr/local/lib’ and ‘/usr/lib’. If the library is not located in one of these directories it must be added to the load path.⁽¹⁰⁾

The simplest way to set the load path is through the environment variable LD_LIBRARY_PATH. For example, the following commands set the load path to ‘/opt/gdbm-1.8.3/lib’ so that ‘libgdbm.so’ can be found:

$ LD_LIBRARY_PATH=/opt/gdbm-1.8.3/lib
$ export LD_LIBRARY_PATH
$ ./a.out
Storing key-value pair... done.

The executable now runs successfully, prints its message and creates a DBM file called ‘test’ containing the key-value pair ‘testkey’ and ‘testvalue’.

To save typing, the LD_LIBRARY_PATH environment variable can be set automatically for each session using the appropriate login file, such as ‘.bash_profile’ for the GNU Bash shell.

Several shared library directories can be placed in the load path, as a colon separated list DIR1:DIR2:DIR3:...:DIRN. For example, the following command sets the load path to use the ‘lib’ directories under ‘/opt/gdbm-1.8.3’ and ‘/opt/gtk-1.4’:

$ LD_LIBRARY_PATH=/opt/gdbm-1.8.3/lib:/opt/gtk-1.4/lib
$ export LD_LIBRARY_PATH

If the load path contains existing entries, it can be extended using the syntax LD_LIBRARY_PATH=NEWDIRS:$LD_LIBRARY_PATH. For example, the following command adds the directory ‘/opt/gsl-1.5/lib’ to the load path shown above:

$ LD_LIBRARY_PATH=/opt/gsl-1.5/lib:$LD_LIBRARY_PATH
$ echo $LD_LIBRARY_PATH
/opt/gsl-1.5/lib:/opt/gdbm-1.8.3/lib:/opt/gtk-1.4/lib

It is possible for the system administrator to set the LD_LIBRARY_PATH variable for all users, by adding it to a default login script, such as ‘/etc/profile’. On GNU systems, a system-wide path can also be defined in the loader configuration file ‘/etc/ld.so.conf’.

Alternatively, static linking can be forced with the -static option to gcc to avoid the use of shared libraries:

$ gcc -Wall -static -I/opt/gdbm-1.8.3/include/
   -L/opt/gdbm-1.8.3/lib/ dbmain.c -lgdbm

This creates an executable linked with the static library ‘libgdbm.a’ which can be run without setting the environment variable LD_LIBRARY_PATH or putting shared libraries in the default directories:

$ ./a.out
Storing key-value pair... done.

As noted earlier, it is also possible to link directly with individual library files by specifying the full path to the library on the command line. For example, the following command will link directly with the static library ‘libgdbm.a’,

$ gcc -Wall -I/opt/gdbm-1.8.3/include
   dbmain.c /opt/gdbm-1.8.3/lib/libgdbm.a

and the command below will link with the shared library file ‘libgdbm.so’:

$ gcc -Wall -I/opt/gdbm-1.8.3/include
   dbmain.c /opt/gdbm-1.8.3/lib/libgdbm.so

In the latter case it is still necessary to set the library load path when running the executable.

Compile and Link Gil image processing library (boost)

x_gradient.cpp

[NOTE: gcc compiles programs to use shared libraries by default on most systems, if they are available. Whenever a static library ‘libNAME.a’ would be used for linking with the option -lNAME the compiler first checks for an alternative shared library with the same name and a ‘.so’ extension. ]

To link using libjpeg.so (dynamically, by default for g++)

~Desktop/$ g++ -I/usr/local/include/boost-1_37 -ljpeg x_gradient.cpp

Alternatively, static linking can be forced with the -static option to gcc to avoid the use of shared libraries:

~Desktop/$ g++ -Wall -static -I/usr/local/include/boost-1_37 -L/usr/lib/ dynamic_image.cpp -ljpeg


Be sure to install all 'libjpeg62' 'libjpeg62-dbg' 'libjpeg62-dev' 'libjpeg-progs' through Synaptic Package Manager.