I promise I will not turn that into a habit, but after quite a few months and more than 100 entries in this blog, I feel like it is time for a little rant indepth analysis summary of where we stand. I mean of where Linux stands as far as photography is concerned.
Graphics and photography have been Apple’s chasse gardée for years but for quite some time, MS Windows is on par with the Mac and the system of choice for photographers boils down to personal preferences more than anything else. Mac users have the exclusivity of Apple Aperture, but Photoshop and Lightroom, Adobe’s behemoths, are available on both platforms – and the CS4 64 bits version of Photoshop for Mac will be delayed due to the necessity to porting it to Cocoa. Maybe Adobe could port it to QT and offer a Linux version, but I digress…
So what about Linux then?
My goal with this entry is to brush a big picture of where Linux stands as far as photography is concerned. What are the achievements, where improvement are needed and being worked on and which pieces are still missing. I will survey what I consider the 3 main areas that an OS has to cover for serious photography work: color management, printing support and workflow.
Note that this is a summary of subjects that are covered in more detail elsewhere in this blog; I provide internal links where appropriate.
Color Management is about ensuring color consistency throughout all your work (graphic chain). What you see on your screen has to match what will come out of your printer and viewing your image on another monitor should not alter its colors. Obviously, Color Management is a crucial part of an OS that is used for photography.
This is certainly an area where Linux has done great progress recently. Most application are CM aware and Xorg has been supporting monitor profiles VGC Tags loading through xcalib and dispwin. We also have Argyll supporting most monitor calibration tools, including the cheaper ones like Huey and Spyder, the notable exception being the newly born Spyder 3.
Missing and being worked on, we find a GUI way to calibrate a monitor – the next version of LProf should offer that. Missing as well is a central way to manage profiles: I should not need to tell each and every application to use AdobeRGB as editing profile, where my monitor profile is and which rendering intend I want. Oyranos’s aim is to provide such a framework, but it isn’t widely used yet – only in Cinepaint, afaik. It would be a waste to have each application or desktop environment developing a different framework – the openicc mailing list hosted at freedesktop is the central place where this type of discussion is being held.
The one missing piece is printer calibration. Recently, with A3 prints becoming an available standard and multiple paper references, “affordable” printer colorimeters are starting to appear on the market. These aren’t supported under Linux for now, so the printer/paper/ink profile’s measurements have to be done in another OS. I don’t think anyone is working toward supporting these products in Linux.
Speaking of printing, this is another area where digital photography has modified (most) photographers habits. It is now possible to handle our images ourselves from capture to exhibition quality print. Even if it is still possible to send images to processing labs, home printers allow very high quality print and can be coupled with a vast choice of papers – yes it has a (high) price, but it is also a great side of the creative photographic process.
Printing manufacturers basically have to handle 2 problems: 1) make (very) small drops of ink placed (very) precisely on the paper; 2) blend the drops from the different ink colors in a way that allows subtle nuances and perfectly continuous gradients.
The fist task is in the hardware hands and although there are minor differences, all the leading manufacturer (ie Epson, HP and Canon) achieve very good results both in terms of quality and longevity, as long as you pick the right combination of ink and paper.
The second task, however, is in the driver’s hands. Obviously, I am not able to test all models from all manufacturers, but here is the situation: HP has been sponsoring HPIJS and HPLIP as high quality driver for Linux which works for most HP printers and includes bells & whistles such as scanning. It also offers a high quality photo mode which I have been using for a while with (almost) complete satisfaction. On the Epson side, the Gutenprint project aims to “provide high quality printing for UNIX (including Macintosh OS X 10.2, 10.3, and 10.4) and Linux systems that in many cases equal or exceed proprietary vendor-supplied drivers in quality and functionality”. Canon has recently joined the A3 photography quality club with its Pixma Pro line. However, these aren’t yet supported in Linux.
So have a check at the Gutenprint / Hplip website before you buy a new photo printer if you want to make sure it works with Linux.
Here is a little checklist to be able to do high quality photo printing under Linux:
- Check if your printer is supported, especially for Black & White output; borderless printing is a hit and miss as well.
- If you have a colorimeter, use Windows to create your custom ICC print profiles or (if you only need a couple of profiles) have someone do them for you.
- printer color management is not always transparent. You have to convert your file to your printer profile manually before sending it to the printer – at least with Cinepaint, which offers the most advanced color management
OK, this looks like a lot of hassle but these are things you do only once: choosing a printer, a paper / ink combination and having an ICC profile made for this combination. And converting a file to the printer profile is more a habit to take than anything else; plus support for Color Management is being worked on in Gutenprint. My experience of printing under Linux has been a success – although it is rather limited.
From loading your picture from your camera to tagging and archiving them, workflow is very important and… quite hard to define. Workflow is about how seamless the photographic process is: loading images, sorting them out, post-processing, printing, tagging and archiving them. And all of that while keeping the highest quality for the images, of course.
So this means either one software doing everything with the danger of becoming dog slow, over-complicated and a useability nightmare or having several specialized applications working hand in hand with the danger of the apps not working seamlessly together and ending up in an over-complicated process. Well, it is all dealing about complexity, and indeed, digital photography processing is a complex process.
How to go about it?
Open Source Software Development (and its “bazaar” development model) has shown an ability to tackle major projects such as the Linux kernel or (more recently) OpenOffice or Firefox – though not without bumps on the road.
However, the Unix tradition is more like “one tool for one task” and we have seen numerous tools on Linux for most photography related tasks. Some are command line based: GREYCStoration (denoising), DVD-Slideshow, xcalib and the ArgyllCMS suite (calibration) not to forget the powerful imagemagick suite. UFRaw (raw converter) can be used both as a command line tool or with a GUI. Add to the mix Gimp, Cinepaint and Krita (editing), Rawstudio (raw converter) a myriad of image viewers (GThumb, Gwenview, Gview or Mirage), a couple of “image management programs” (F-Spot and Digikam) and a few metadata and tags editors (jbrout, xmpmanager…)
You guessed it: it is a mess bazaar. A few chosen examples:
- I can achieve high quality denoising by choosing the parameters in a Gimp-plugin but then I have to run the command-line version of GREYCStoration to keep a 16bits / channel image.
- I can view my JPEG images in Rawstudio but not modify them. I can view RAW thumbnails in GThumb but I can’t do anything with them; but GThumb allows me to view and modify JPEG.
- The only way to edit a picture in 16bits modes is with Cinepaint; it does the job but misses quite a few “must have” like preview for unsharp mask, effect layers, etc. Krita has proved to crashy for me and Gimp is limited to 8 bits.
The list goes on. Basically, it is working, but it is clunky. So what do we need, what is missing and being worked on and what is definitely not on the radar screen?
High bit depth editing
Linux definitely needs a credible high quality photo retouching program. Cinepaint has a Ferrari engine inside an old 2CV, while Gimp has the 2CV engine inside a Ferrari. Krita is taking more the direction of a high flying painting program than a photo editor. So this piece is badly needed although being worked on with Cinepaint’s next generation (Glasgow) and the integration of GEGL in Gimp.
If I was a billionaire in charge of a Linux distribution, I would hire Sven and Mitch to work on Gimp full time… now that the plan is clear and that real productive work is being done, that would be a project with high visibility in the community. Without this, Linux will just not cut it for serious photography.
Another important step is the RAW conversion. Again, the balance between the possibilities of RAW tweaking and the necessity to keep the software reactive and its complexity under control is tricky. If you read this blog, you’ll know that my favorite converter is Rawstudio for its speed, simplicity and “well-thoughtness” – it is developed by people who were photographers before being software developers… However how do I correct lens vignetting, purple fringing and distortion? That is where the Lensfun project comes in: a database of lenses / body characteristics that allow for automatic lens defects correction (à la DXO). Other areas where Rawstudio needs some love are denoising, exif support and contrast boost (unsharp mask with large values).
At that point, you will mention RawTherapee and you will be right: it does all of that. But the price to pay is too dear for me, in terms of speed and interface complexity. But don’t hesitate to check RawTherapee, hundreds are very happy with it. Or LightZone, now that its (paying) Linux version is back on track. To each its own.
Then there is the image viewing / management / tagging issue. In the proprietary world, this is handled by Lightroom which does file management and RAW conversion. Even if there is a lot of choice of image viewers / managers in Linux it still is hard to find “a good one” mainly because there are so many interpretation of what “a good one is”:
- Photo organizer (Digikam / F-Spot) that do everything for you, including copying your files, image edition, raw development…
- Photo viewer (Gthumb, Gwenview) that are “just” showing you the images in a current folder and have basic editing capabilities
As far as I am concerned, what I need is:
- display quickly any file type (including RAW)
- thumbnails / image / metadata / folder browsing panes that can be moved around and hidden
- full exif and XMP tags management / search support
- slideshow / fullscreen
- create contact sheets (I know, this looks like a gadget, but it comes in very handy)
- right-click on an image to open it in the raw converter / image editor
- Color Managed
What I don’t need is:
- Image edition (there are better tools for that)
What I don’t want is:
- a program that copies / moves / saves my files by itself
I am yet to find the perle rare, although GThumb is pretty close (with quite a few extras that I don’t need) and with missing parts being worked on in SVN. Other candidates are Geekie and Gwenview (for KDE users).
Making them work together
And remember that these have to work closely together. A little option like “Export to Gimp” in Rawstudio is the perfect example of something simple that makes life easier (at least that will be the case when Gimp supports higher bit depth).
I don’t think we need a billion apps for photography. In fact, I have argued that it boils down to 3:
- a high bit-depth capable editor
- a well thought RAW converter
- an image viewer / manager / tagger
All of them keeping exif datas, supporting xmp tags and allowing 1 click opening images in each other (open in ImgEditor, open in RawConverter, open in ImgViewer). At the end of the day, it doesn’t look very difficult. But it is always easier to write a blog entry than good code. Plus there is this push for more features that has been a trap in open source projects – and closed source, when you come to think of it.
Xorg dual screen
Once you started using dual screen, it is very hard to go back to single screen; having your image displayed fullscreen on a calibrated monitor while keeping your tools on another monitor is such a productivity and comfort boost. It is not like Xorg doesn’t support dual screen. It is that it is such a pain in the ass neck to set it up. But with the new xrandr 1.3, proper monitor hotplug is being supported and we start to see GUI coming for an easy configuration (grandr, krandr).
As always with Xorg, there is then the question of your particular graphic card’s driver supporting the feature, but with Intel and more recently AMD (ex ATI) opening their specification and the dynamism of Xorg / Freedesktop community, this is an area where there is hope – just think about recent achievements like compiz or xorg.conf (almost) disappearing.
I don’t think that the answer to Linux for photography is “Photoshop & Lightroom on Linux”. Open Source Software has developed some amazing pieces of software and I don’t see why photography would be an exception. My dominant feeling is “work in progress” and I see the “Linux photography ecosystem” maturing and moving forward in the right direction.
But let’s face it: Linux is not a drop-in replacement for Windows or MacOS for photography yet. Far from it. You can use Linux for serious photography, but critical pieces are still missing or are too kludgy for efficient work; you need to be willing to accept sacrifices. I use Linux for photography as an amateur, but I would never recommend Linux to a pro photographer with time / production constraints.
Still, my hope is to see Linux maturing to the point of being a great OS for photography. And this hope is strong enough to keep me blogging about it🙂