An avian carrier's blog – Photo and imaging Atom feed

  2. The resynthesizer miracle (2005-10-28)

    Once in a while, I find a very good plugin for GIMP (the GNU image manipulation program). The last one I stumbled upon was the resynthesizer plugin.

    With this plugin, you can create tileable textures, remap textures or remove objects from an image in a very easy way.

    I have tested the latest feature (removing objects from an image) on two different images (credits to Nadine).

    Removing a scratch from a girl’s skin

    As you can see in the image below, this (otherwise gorgeous) friend of mine has an ugly scratch on her back:

    If you select (very roughly) the scratch and ask for its removal using the resynthesizer plugin, it’s gone:

    Yes, that’s it. It has been replaced by new skin automatically.

    Removing a plane from the sky

    I also tried it on a bigger image:

    By very roughly selecting the plane, do you think it will be possible to remove it? Here is the result:

    Impressive, eh? Out of curiosity, I made GIMP compute the difference between both images. Here is the result:

    Yes, you can even use this plugin, after applying the right black and white threshold (1-255 is white, 0 is black), to get an alpha mask of the plane.

    I hope that this plugin will be included in the next version of GIMP.

    Oh, of course, GIMP and the resynthesizer plugin are both available as Free Software.

  3. blenderdist (2005-08-21)

    When doing some heavy 3D rendering with Blender, I realized that one of my animation was going to take 53 hours to render. Existing distributed rendering systems such as DrQueue were fine but require that some software other than Blender or basic interpreters (such as Python or Perl) is installed on the contributing machines.

    So I wrote a simple Python script called blenderdist.py which only needs blender and python to run. A server is launched with:

    % python blenderdist.py --server PORT JOBDIR RENDERDIR

    and will monitor the status of job files (three lines each, the blender file, the first frame to render and the last one to render) in JOBDIR. Resulting frames are placed under RENDERDIR/jobname. Job names have to end with .job and if a file named JOBNAME.job.suspend is present, its rendering is suspended to allow urgent jobs to be rendered first.

    Clients are launched with:

    % python blenderdist.py --client HOST PORT

    The server constantly monitors its source code. Whenever the Python script changes, the server relaunches itself (without loosing its state saved in a checkpoint file) and the next time the clients connect to it they will receive the new version of the program and relaunch themselves too.

    I have currently a dozen machines working as I type, most of them out of my control. Some friends of mine have agreed to run the script and are contributing CPU cycles for my rendering. This proves to be very helpful. The program is much less powerful than generic ones such as DrQueue, but it does not require that disk space is shared between machines or setting up complex scripts. It just gets the job done.

    Note: as this script has been written for a one-time shot need, I place it under the public domain, do whatever you want with it.

    Getting blenderdist

    You can get the current development version of blenderdist using git:

    git clone git://github.com/samueltardieu/blenderdist.git

    This will create a blenderdist directory in which you will be able to record your own changes.

    You can also browse the blenderdist repository on GitHub.

    Contributing to blenderdist

    Reporting bugs and asking for features

    If you find a bug or have an idea for a new feature, you might consider adding a new issue. The more precise you will be in your description, the more useful it will be.

    Submitting patches

    Patches are gladly accepted from their original author. Along with any patches, please state that the patch is your original work and that you license the work to the blenderdist project under a license compatible with the current one (public domain license).

    To propose a patch, you may fork blenderdist repository on GitHub, and issue a pull request. You may also send patches and pull requests by email.

  5. What can you get from free software? (2005-03-09)

    I described in another post how and why I wrote recoverjpeg, a program that recovers lost digital pictures on corrupted media. This software is totally free (both as in free beer and as in free speech); the only reward I counted on was to receive some excerpts of recovered pictures to illustrate the software's web page. However, I received much more.

    At this time, the return on investment for this software is:

    • around ten thousands of my own pictures that had been mistakenly erased (that alone would have been more than enough);
    • a bottle of champagne from a satisfied user (thank you Blaise);
    • two boxes of liquorice pepper candies from a satisfied user (thank you Phil);
    • a handful of very beautiful pictures from a satisfied user (thank you Volker);
    • a beer and a picture from a satisfied user (thank you Erwan).

    And this is just the beginning. Not bad for 326 lines of code.

  6. How recoverjpeg saved my day (2004-12-29)

    People sometimes do stupid things. I do at least. After I experienced a fatal disk crash a few days ago (the disk could not even be seen in the BIOS), I congratulated myself for having done a full online backup of thousands of pictures I had been taking for years with my digital cameras on my second hard disk a few days before the event.

    I bought two new serial ATA disks1 and reinstalled the system (first FreeBSD, then Debian GNU/Linux, as support for serial ATA is much better with the latter), setup software RAID-1 redundancy to avoid losing my system disk the next time a hard drive fails, and my computer went up and running again. When I was done, I decided to test other operating systems on my reshaped computer and installed Microsoft Windows XP Pro on my older hard disk2 on a newly created 10GB partition, with the intention of playing with it for a few hours and deleting it afterwards, as I have no use for it.

    Then I realized that… I had not transferred my digital pictures to my new disks; the only online copy was located on the disk I just reconfigured. Sure, I could remember burning two DVD as a backup three or four months before, but I was unable to locate them in my appartment. The pictures were buried somewhere under or around the new XP installation.

    I happened to have written a small Python program a few weeks before to recover JPEG pictures from a friend compact flash memory card which would not list any of the images he had taken during his african trip. On most filesystems, chances that pictures are stored in consecutive disk sectors are good, as this is the simplest thing to do. Of course, some pictures will get stored in the holes made by removing pictures interactively, and some may have been overwritten by newly shot ones.

    While the program did a good job on a 128MB file (a copy of the failing memory card), using it on a 80GB drive was going to be very painful. Especially since I expected to having to refine the algorithm in order to recover as many pictures as possible. The pictures had been taken with several brands of cameras and I had to be as close as possible to the JFIF file format while maintaining a high speed.

    I decided to take a few hours to rewrite my program in C and to reduce the number of system calls to a minimum (the Python program was using tons of read()). I also wrote a small shell script to be run on top of recovered pictures which would sort them in directories named after the date the pictures had been taken, using the exif tags.

    Amazingly enough, it did a very good job. The outcome of running the program on my 80GB drive with 10GB being used for the XP installation was:

    • 9538 pictures sorted by date (a few of them were corrupted in a way that no software can detect as they are valid JFIF files) and taken on 337 different days
    • 1310 pictures without date (some of them were correct pictures whose exif data had been corrupted)
    • 8301 pictures too small to be real digital pictures (no error there, most of them were thumbnails of real pictures previously made by software such as gqview)
    • 71 invalid JFIF files
    • 4 pictures recorded at a date of 0000-00-00 (probably a bug in a friend’s Olympus camera used to take the pictures)

    That makes it a total of 19222 pictures, using 11GB worth of disk space. I could find pictures for every single major event I was able to remember. Needless to say I was and still am today very happy. I sent the program to a few friends for testing3 and released it under the name recoverjpeg under the GNU General Public License.

    I hope it will work out for you as well as it did for me. If it does, do not hesitate to send me a few pictures that have been recovered using it (800 × 600 format) so that I can put them on recoverjpeg WWW page.

    1 Ok, I admit, when I was in the shop, I also bought a new motherboard, a new CPU and more RAM.

    2 At this point, I was happy that Windows XP did not recognize the serial ATA drives as I was sure it could not trash them.

    3 This way, we found out that mmap()-ing block devices was not supported under FreeBSD, while it worked fine under Linux or Solaris. The program was adapted to use huge read() chunks to increase portability.