I was perusing a recent copy of Linux Format and encounter a feature describing a self-hosted alternative to the likes of Flickr: Gallery. From my quick look, it looks fully featured, offering themes and even shopping cart facilities for those who want to sell their wares. The screenshots on the the open source project’s website look promising but, for a fuller appraisal, I would need to spend some time trying to bend it to my will. Before anyone mentions it, I am aware that WordPress can be used for photoblogging but this tool seems to take things a bit further. It’s the sort of thing about which I might have wondered given the pervasiveness of content management systems these days. My own custom built photo gallery is devoid of a slick back end, hence why Gallery caught my eye, but I’ll continue with it and may even get to adding the needful myself.
Archive for Graphics
ImageMagick and Ubuntu 9.04
Using a command line tool like ImageMagick for image processing may sound a really counter-intuitive thing to do but there’s no need to do everything on a case by case interactive basis. Image resizing and format conversion come to mind here. Helper programs are used behind the scenes too with Ghostscript being used to create Postscript files, for example.
The subject of helper programs brings me to an issue that has hampered me recently. While I am aware that there are tools like F-Spot available, I am also wont to use a combination of shell scripting (BASH & KSH), Perl and ImageMagick for organising my digital photos. My preference for using Raw camera files (DNG & CRW) means that ImageMagick cannot access these without a little helper. In the case of Ubuntu, it’s UFRaw. However, Jaunty Jackalope appears to have seen UFRaw updated to a version that is incompatible with the included version of ImageMagick (6.4.5 as opposed to 3.5.2 at the time of writing). The result is that the command issued by ImageMagick to UFRaw – issue the command man ufraw-batch to see the details – is not accepted by the included version of the latter, 0.15 if you’re interested. It seems that an older release of UFRaw accepted the output device ppm16 (16-bit PPM files) but this should now be specified as ppm for the output device and 16 for the output depth. In a nutshell, where the parameter output-type did the lot, you now need both output-type and output-depth.
I thought of decoupling things by using UFRaw to create 16-bit PPM files for processing by ImageMagick but to no avail. The identify command wouldn’t return the date on which the image was taken. I even changed the type to 8-bit JPEG’s with added EXIF information but no progress was made. In the end, a mad plan came to mind: creating a VirtualBox VM running Debian. The logic was that if Debian deserves its reputation for solidity, dependencies like ImageMagick and UFRaw shouldn’t be broken and I wasn’t wrong. To make it fly though, I needed to see if I could get Guest Additions installed on Debian. Out of the box, the supported kernel version must be at least 2.6.27 and Debian’s is 2.6.26 so additional work was on the cards. First, GCC, Make and the correct kernel header files need to be installed. Once those are in place, the installation works smoothly and a restart sets the goodies in motion. To make the necessary Shared folder to be available, a command like the following was executed:
mount -t vboxfs [Shared Folder name] [mount point]
Once that deed was done and ImageMagick instated, the processing that I have been doing for new DSLR images was reinstated. Ironically, Debian’s version of ImageMagick, 6.3.7, is even older than Ubuntu’s but it works and that’s the main thing. There is an Ubuntu bug report for this on Launchpad so I hope that it gets fixed at some point in the near future. However, that may mean awaiting 9.10 or Karmic Koala so I’m glad to have the workaround in the meantime.
On Photoshop Elements 7
In recent days, I have been playing around with Photoshop Elements 7, doing the same sort of things that I have been doing with Elements 5. Reassuringly, I can still find my way around, even if the screen furniture has been moved about a little. My Pentax K10D is recognised and I am able to set white balance to get sensible results. On the images that I was testing, things started to look too warm in the Cloudy and Shade settings but that’s all part and parcel of processing photos taken in early November. The results of my exertions look decent enough and you can see them in a post on my hillwalking blog.
I realise that Adobe has been promoting the ability to easily airbrush unwanted objects from images and enhance blue skies but there’s no point having all of that if functionality available in previous versions does not work as expected. Thankfully, this is largely the case but there are a few niggles. I have working the new Elements on a Windows XP SP3 virtual machine running in VirtualBox 2.04 on Ubuntu 8.10 so I don’t know if that contributed in any way to what I encountered. One gigabyte of memory is allocated to the VM. The files were stored in the Ubuntu file system and accessed using VirtualBox’s functionality for connecting through to the host file system. File access was fine but I was unable to directly open a file for full editing from the Organiser, something that I have doing very happily with Elements 5. I also noted a certain instability in the application and using the hand tool to get to the top left hand corner of an image sent the thing into a loop, again something that Elements 5 never does. Otherwise, things work as they should but what I saw points to the need for an update to correct any glitches like these and I hope that there is one. For now, I will persevere and see if I can make use of any additional functionality along the way.
- Adobe Photoshop Elements 7 Editor
- Adobe Photoshop Elements 7 Organiser
Running Photoshop Elements 5 on Ubuntu and openSUSE
When you buy a piece of software and get accustomed to its ways of working, it is natural to want to continue using it. That applied to a number of applications when I moved over to Linux in the latter half of last year and one of these was Adobe’s Photoshop Elements 5.0, a purchase made earlier in the year. My way forward was to hang on to Windows by way of VMware. However, Elements fails to edit or save files in the Linux file system accessed through VMware’s shared folders feature. I have yet to work out what’s happening but the idea of using a more conventional networking arrangement has come to mind.
Another idea that intrigued me was the idea of using WINE, the Windows API emulator for Linux. You can get it in the Ubuntu and openSUSE software repositories but the WINE website has more to say on the subject. That’s only the first stage though as you might see from WINE’s Wiki page on Photoshop and its kind. However, their advice is a spot incomplete so I’ll make it more explicit here. You need to run Winetricks from its online home as follows:
wget kegel.com/wine/winetricks; sh winetricks fakeie6
wget kegel.com/wine/winetricks; sh winetricks mdac28
wget kegel.com/wine/winetricks; sh winetricks jet40
The first line flicks a switch to fool Microsoft components to install thinking that they are installing into a Windows system with IE on board. Without this, the rest will not happen. The second installs Microsoft’s native ODBC drivers; Elements will not function at all without these if my experience is any guide. The last step is to add JET support so that Elements’ Organiser can get going. With all of these in place, having a working Photoshop Elements instance under Linux should be a goer. Apart from the odd crash, things seem to be working OK on Ubuntu and openSUSE seems hospitable too. Further experimentation may reveal more.
Update: The WINE Wiki has now been updated (and links back here!). As per dank’s comment, the above lines can be condensed into what you see below:
wget kegel.com/wine/winetricks; sh winetricks fakeie6 mdac28 jet40


