workflow « Red Skies at Night

September 18, 2011

County Fair

Filed under: life, photography, photos, process, workflow — Tags: B&W — Eric Jeschke @ 4:42 pm

Key: R20110918-114010-bw

I like the hand pointing out of the lower left.

Recently there was an interesting commentary on Chris Klug’s blog about the workflow for a B&W conversion from digital color. Since I have a B&W conversion for you today I thought I’d comment on my process a little bit.

Although B&W photography is rather common with me, B&W conversions are not. They are not rare for me, but as a percentage of my total selects there are not that many. I usually know ahead of time that I want to shoot B&W. If I am shooting JPEG and I want to shoot B&W I will put the camera in one of the B&W modes, because I even want to see the scene in the viewfinder in B&W–I am visualizing everything in tones. For example, if the light is not great for color anyway–harsh midday sunlight washes out subtle color hues (it’s often ok for landscapes, if there is a lot of sea, sky, foliage), I’ll just switch to shooting B&W. Or if I am “feeling B&W” I’ll immediately switch to shooting in B&W. But it doesn’t always work out that way.

Today we were at the fair and the light was mostly high, bright overcast–fine for color work. I was shooting in color because I thought that the fair, with a lot of garish colorful booths and objects would be best served by color. But when I examined the afternoon’s take, I found that I wasn’t particularly happy with the color on most, although there were some compositions I liked. Somehow the color was too much and too all over the place. I decided to try some B&W conversions, and this was the one I liked the best.

When I do a B&W conversion, I usually end up using the channel mixer. First, I do a decomposition to the RGB layers to see what is in each channel, and what each would have to offer to the resulting mix. Usually I end up using mostly green channel, with some amount of red or blue dialed in. But sometimes a channel offers nothing of value: yesterday’s shot was a good example. It ended up being 65% green and 35% red channel and I threw away the blue channel–it was nothing but mud. Today it was mostly green with, some red and some blue. I applied a tone curve to bring up the midtones a little without touching the shadows or highlights. Even though the food booth signs were very colorful, the monochrome treatment still conveys the feeling of expensive, low-class greasy food sold out of garish shops standing shoulder to shoulder. In other words, the fair ambiance. I went to the fair with three happy, bubbly girls, but came back with three miserable, sick-to-their-stomach girls. Who says the fair is a good time? Not me. But I did enjoy getting a few photos in.

February 26, 2011

A Linux-Based Photography Workflow (Part 6: Printing)

Filed under: floss, linux, photography, printing, process, products, tools, workflow — Tags: gimp, gutenprint, hp9180, photoprint, turboprint — Eric Jeschke @ 10:01 pm

This is part of a series of posts on Linux-based software tools for a photography workflow. Please read that first if you are coming to this series fresh–it will provide the necessary background information to explain the purpose of this series. In this particular post I’ll talk about image printing.

If all you wanted to do was put your photographs online, there would be less doubt about Linux as a platform for doing serious photography. But most photographers, sooner or later, will want to make prints. Of course, this can be outsourced to an online or local printing service, which is a very interesting and reasonable proposition for some folks, especially if you do not print frequently. Running even a small photo quality printer adds a level of complexity and cost to the workflow that is usually disproportionate to it’s contribution to the whole. For some photographers, however, just being able to produce a print instantly and to have the ultimate control over the printing, justifies the expense and trouble.

Although digital photo printing has come a long way, it is still a bit of a black art on any OS. There are just so many variables to control, including paper types, printer drivers, color management, profiles, application settings, etc. For many years I did all my workflow on Linux except for printing: when it came time to print I would copy the finished files over to my Mac, fire up Photoshop, open the image and invoke a special plug in to handle the printing. I can remember how much work it was just to get that working (on a Mac no less, where color management is built into everything) and how many test prints I made and different profiles downloaded and tried. In 2011, as I write this, it is still the case that you cannot really get away from putting in the time making a bunch of test prints to really figure out the process, no matter what the platform.

It always bugged me a bit to have to go through the final step with the Mac, and Photoshop was just so big and bloated that I often wished I could just print somehow directly from Linux. Unfortunately, in those days color management was not as solid in the different apps on Linux and printer drivers also were not always up to the quality of the manufacturer supplied ones for Mac or Windows. But these last barriers have been falling like dominoes, and I’m pleased to report that recently my workflow went all Linux–printing being the final piece to fall in to place. And I’m going to tell you how I did it.

If you own one of the more popular Epson or Canon photo printers out there, you should likely look to gutenprint for your photo printing needs. This is a solid driver with great community support and a good integration with the gimp as well as various other applications. Unfortunately, my printer, the HP 9180, is not supported by gutenprint or even by HP with open-source Linux drivers (even though they are pretty good at supporting most of their other printers under Linux), so I was forced to go looking elsewhere for a solution.

The solution that I found was turboprint. Turboprint is a commercial product for Linux-based systems that provides printer drivers for hundreds of printers, GUI based dialogs for configuration, monitoring and maintenance, and a GIMP plug in for printing. The package can be downloaded and tried out for 30 days with full functionality to see if it works for your system. I found that it installed quickly and painlessly on Ubuntu 10.04. Once installed, a GUI configuration walks you through setting up the printer, and after that it just appears as a printer like any other on your system. You can then print to it from any application that supports printing. The install also includes a plug-in for the GIMP that provides some convenient features for tweaking print settings directly from inside the plug-in GUI. Although I still had to make a handful of test prints to figure out the proper settings, it was pretty easy for me this time around, perhaps because I’ve been down that road before on the Mac and worked out the strategy there. That is too long a story to go into here, but might be the topic of another post sometime. For now, I’ll just say that the main thing is to get the correct ICC profiles in the right places and then experiment with the settings between the application and the printer driver, changing only one variable at a time. Once I was satisfied that I was getting prints that matched what I saw onscreen in the GIMP and geeqie, I felt that the price of around $82 USD (studio version) was not too bad for being able to work comfortably under Linux. Not only that, but the quality of the prints seems every bit as good as I was getting from the Photoshop plugin on the Mac.

I want to mention one more application that I use for printing, but to do so I have to digress just a bit to talk about printing in the way old days. Back before I did printing on the Mac, I did printing under Windows, using a program called Qimage Pro. This was a splendid little program that excelled at one thing: printing multiple photographs on a sheet of inkjet paper. When I switched to the Mac for printing I sorely missed this little gem of a program. The good news is that I’ve found the near equivalent now that I’m printing under Linux: it’s called photoprint, and it’s classic GPL open source goodness! The author’s web site has lots of really useful information and it’s clear he has some good experience doing high quality imaging under Linux. photoprint has many really useful features, including full support for color management, various layout options, drag and drop and high quality downsampling. You can set up custom presets, which makes it a breeze to change print sizes. By default photoprint seems set up to print via gutenprint. To use it with turboprint I simply made a preset to turn off any color correction, set a correct monitor profile and NO printer profile (turboprint applies the profile in the driver). This is really a splendid little app and the main way I now print under Linux. Highly recommended.

Comments (1)

A Linux-Based Photography Workflow (Part 5: Scanning)

Filed under: articles, floss, linux, process, products, scanners, scanning, tools, workflow — Tags: epson, v700, vuescan, xsane — Eric Jeschke @ 3:38 pm

In this part I move on to the topic of scanning. If you are a new digital-based photographer you might not have any need for this information, but if you shoot and scan film, or like me, are old enough to have old stocks of slides and negatives from the pre-digital days, you may want to scan these so that you can integrate them into a digital archive or print workflow. I’m on my second film scanner. The model I’m currently using is the Epson Perfection 700, a flatbed scanner that has some inserts for batch scanning a number of slides or negative strips at once. The resolution is high enough on this scanner that it is more than sufficient for the lenses and technique that I used back in the film days. Here is a picture of the scanner all loaded up with a set of 12 slides.

I’m going to cheat a little bit again and point to some older posts that I wrote about my scanning workflow almost exactly two years ago. The posts are still highly relevant, since I haven’t changed my scanning workflow one iota since then and I constantly refer back to those posts as reminders when I fire up my scanning workflow. Without further ado, part 1, part 2 and addendum.

For those who don’t wish to follow up all that information in one go, here is a basic summary:
In my early days of scanning, I quickly settled on a commercial program called VueScan, by Ed Hamrick. He sells a version of the program for Linux, Mac and Windows. It looks and behaves more or less identically across all the platforms. Although the price has gone up a bit since those days, this is still a very good product at a reasonable price. I looked at the open source alternatives such as xsane, etc., but they just didn’t match up with the feature set and workflow potential of vuescan. As you can see from the posts, there are many, many settings–this is not a program for novice users. It has a steep learning curve, but once you have mastered it the reward is an efficient, powerful and flexible scanning workflow that is almost unrivaled by any other scanning program period. The posts above describe a two step workflow that results in the RAW scans being saved, and then subsequently “developed”. The key thing here is that if you perform the first pass correctly you never have to go through the tedious scanning process again–like camera RAW files, you can reprocess the scanner RAWs as many times as you like from the hard drive. My second pass is usually to process the RAWs into TIFFs (again using vuescan), and after that I can edit them using GIMP or Raw Therapee for further processing, or run a batch operation using ImageMagick to sharpen, possibly downsample and convert to JPEG for the web.

Excellent product, highly recommended. According to his web site, there is now a decent book describing a workflow using vuescan, and I only wish that had been around when I was learning it. As it was I remember scouring quite a few web pages and a suffered a few false starts before I finally figured out the subtleties of the program and how to make the most of it. Nothing like having to scan the same batch of slides again and again to encourage you to figure out how to avoid those mistakes.

February 21, 2011

A Linux-Based Photography Workflow (Part 4: Producing Books and Folios)

Filed under: books, floss, linux, photography, photos, POD, process, tools, workflow — Tags: ebook, evince, folio, LaTeX, pdflatex, scribus, xelatex — Eric Jeschke @ 4:52 pm

Key: R20110210-201845

My next post in this series was supposed to be on making panoramas. I’ve run into a bit of a snag on that one and I’m going to push it to the end of the series. So we’ll move on to talking about Linux based software that I use to create books and folios.

This is actually an easy post to write because I’m going to point you at a fair bit of writing that I did in the last year or so on these subjects. So without further ado, let me point you at my categorized posts on books and another set of tagged posts on folios. Finally a pointer to my set of templates for books and folios.

A summary for those who may not wish to dwell deeper:
After some brief and successful forays into desktop publishing books using Scribus (a graphical tool), I ultimately settled on a method using the venerable La(TeX) markup language to create works that can be targeted as web PDFs (so called “E-books”), books from PDFs using Blurb.com or some other Publish On Demand service, and web and print-based folios. The method gives up some control of manually laying out the work by automating the layout using a markup language (LaTeX) coupled with TeX’s tried-and-true hyphenation and page layout algorithms. I realize that this method is probably too technical for the average photographer. However, if you have any kind of technical bent (and you well might, if you are considering a Linux-based photography workflow), you may find that the trade off is well worth it. Manual layout of books is a slow and somewhat tedious process, especially with a GUI program. A mark-up language based approach is not only faster, but inherently tweakable when your output needs change.

From the LaTeX source, xelatex or pdflatex will produce a PDF file. I use evince (a very good PDF viewer, part of the standard Ubuntu desktop) to review the PDFs for correctness. Once satisfied with the PDF I can either upload it to Blurb.com if I am ordering a book, or to a a web site (e.g. Issuu.com) if I am just creating an e-book. Folios are uploaded to a web site, or printed on inkjet paper using a method that will discussed in the upcoming post on printing. After using these methods I cannot imagine going back to manual layout approaches for most books and folios. However, if you enjoy (or need or prefer) the manual control of a GUI layout program, I can heartily recommend Scribus. You could spend a lot of money on Adobe InDesign or some other DTP program and never use more than the feature set that Scribus offers for free.

Addendum: I use the aforementioned Image Magick convert program scripted from Python to downsample my photographs from a master folder for the book or folio. In true geek fashion, a Makefile is used to ensure that all the images are downsampled to the appropriate size for the web or print, depending on the target output.

February 12, 2011

A Linux-Based Photography Workflow (Part 3: Image Editing and Conversion)

Filed under: linux, workflow, tools, floss, products, photography — Tags: gimp, open source, raw therapee, imagemagick, cinepaint — Eric Jeschke @ 5:17 pm

Based on the popularity of iPhoto, Picasa and Lightroom in the commercial, closed software sector, most open source photo management programs from recent years are all-in-one organization/viewing/editing tools. Targeted at the novice to intermediate level, you have F-spot, digikam, etc. At the advanced end we have a few tools that started out as RAW converters and have accumulated features for organization. These include Raw Therapee, Raw Studio, etc. There are also some commercial options for Linux in this category that I have tried, including LightZone and Bibble Pro. On the organization/viewing side, I find most of these to disappoint on the user interface or features, the requirement for an image database, or speed. Consequently I prefer an approach that separates the organizer/viewer from the editing tools. As I mentioned previously, I have settled on geeqie as my general organizer/viewer. From geeqie I can handle almost all tasks associated with image ingest prior to more general editing. Here then, is what I use when I get down to actually editing.

GIMP

For general image editing I continue to rely on an old standby in the Linux-based stable: the Gnu Image Manipulation Program (GIMP). This has always been the “Photoshop for Linux”, offering a similar way of working with images as the well known commercial alternative. The general selection and adjustment tools are stable and continue to improve incrementally with each version and a variety of useful brushes, filters and plugins are available, including a very useful technique for toning. Fortunately the GIMP acquired color management a couple years back, and by loading my monitor and printing profiles I am able to achieve very good on-screen matches to prints, especially with a decent high-gamut monitor. RAW conversion is pretty decent using the “ufraw” plugin.

Although the GIMP lacks many of the features of Photoshop, most of them I wouldn’t use anyway. There are a few things, however, that are still lacking for my needs:

lack of adjustment layers
lack of high bit-depth editing
lack of more intuitive white balancing tools
the continuing rearrangment of editing menus

The lack of adjustment layers can be worked around rather primitively by duplicating layers, entire images and in some cases saving multiple versions of the file, but it remains a frustrating limitation. The lack of high bit-depth editing may ultimately be a “make it or break it” issue like color management, and I can only hope that the GIMP developers can get this included before too long. The reason is dynamic range: many of the new sensors can produce 14-bit RAW files, and it would be nice to convert to TIFF and take the editing into the GIMP from there. There was a fork of the GIMP a while back that the movie folks in Hollywood did called “cinepaint” where they added high bit-depth editing, so it can’t be too onerous. As a matter of fact I used that program for a little while before GIMP acquired support for ICC profiles and it was very nice; unfortunately it does not look like it has been actively maintained for quite a while. As far as white balancing tools, the GIMP has the usual black/grey/white droppers and the ability to adjust individual curves for R/G/B, but what I am referring to is a more visually intuitive tool that allows you to adjust the apparent color temperature the way some other programs do. Finally, I don’t know why the developers find it necessary to rearrange the menus with every release. This is a continual frustration to documentation and tutorial writers, and virtually insures that the documentation and tutorials for the GIMP are never accurate.

Based on this last rant you might think I’m down on the GIMP, but I’m not really. It remains a very stable, useful program that is my main workhorse for image editing. I love its flexibility and plug in architecture that lets me write my own extensions and download others. Recently I’ve been playing with the Film Simulation plug in, which allows you to mimic the look of a couple dozen classic B&W films.

Raw Therapee

If GIMP is to Photoshop, then Raw Therapee is to Lightroom. Recently open-sourced, RT is a very capable RAW converter that has evolved a lot of really useful tools for denoising, shadow/highlight recovery, basic adjustments, etc. The RAW conversion algorithms are said to be very good, and I have no reason to doubt it, as it has worked very well for me on the occasions when I shoot RAW. I find myself using it more and more even to edit JPEGs because it has such intuitive tools for things like white balancing, exposure adjustment and noise reduction. The program also features a non-destructive workflow that lets you very easily go back to any point in the editing history. You can also make snapshots of the editing history, which is a really cool feature. RT has full support for ICC color profiles as well, meaning no nasty surprises if you’ve got decent profiles installed.

RT has an “organizer” pane which is painfully slow to scan directories and is in general not very pleasant to use. I already mentioned that I prefer my organizer/viewer as a separate program, and I have yet to find a convenient way to load images into RT via geeqie, so I usually end up loading photos directly from the RT user interface, which is a bit of a drag. Otherwise this is a great tool that is becoming an increasingly important part of my workflow.

Image Magick

Very briefly I’ll just mention one last tool that I use quite frequently and that is the Image Magick suite of command line tools. I use these primarily in custom scripts that I write to easily automate conversion of images for the web, making books or folios, etc. Extremely flexible and useful for downsampling + sharpening (different sizes), ICC profile conversion and so forth. Highly recommended. Like the GIMP, these can usually be installed straight from your Linux distribution package archive.

Comments (6)

January 3, 2011

A Linux-Based Photography Workflow (Part 2: Image Ingest and Organization)

Filed under: floss, linux, photography, photos, tools, workflow — Tags: geeqie, nautilus, open source, python — Eric Jeschke @ 11:29 pm

Key: Key: R20101207-141738

As I have mentioned before, I do not currently use a database to organize and keyword search my images. The reason is that I do not frequently need to keyword search my images. Sometimes I will tag them when I upload them to Flickr for web use and disaster archiving (more about that topic later)–in that case I can simply search my own photostream for candidate images. And sometimes I will make XML files with some metadata (including keywords) that I can search. But I am not a selling stock imagery, or getting calls from some editor looking for such and such kind of an photograph. No, I typically work on my recent images from the last two years or so, printing, entering contests/exhibitions, uploading to the blog or whatever artistic outlet I might have in mind. For my purposes it is not difficult eyeballing a couple years worth of folders to find what I am looking for. If I was needing to search my collection frequently then I probably would be using a database. All this is a long-winded preface to saying that I use simple Linux filesystems to store my images and nothing more. I typically use the ext3 (and soon, probably ext4) file systems.

I store images in folders in an archive area of my RAID. The folders are named by year, and also after special trips, physical areas and/or projects. In addition to these I have a few special folders that constitute a “staging area”: these are named by camera (e.g. “ep1″, “gh1″, “gx100″, “iphone”, etc.). When I am ready to ingest some new images, I connect the camera by USB cable, or pop the card into a reader, which automounts the flash disk. I use nautilus to open one window of thumbnails to the named camera folder in the staging area and one window to the camera flash drive as a mass storage device. Scrolling down to the bottom of each pane I can quickly see which files I need to drag off the camera and into the staging folder. A quick marquee selection and a drag and I have the images safely copied onto my RAID. I then right-click on the flash drive icon and unmount it, disconnect and turn off the camera.

After copying the images to the staging area, I need to rename them to match the key system that I use (i.e. by time, primarily). For this purpose I have written a Python program that uses an EXIF library to examine the header and find the date of capture for each file whose name matches a certain naming convention (you know the typical ones used by manufacturers: PNNNNNNN.JPG, DSCNXXXX.DNG, etc. It is a very easy and quick task for the program to locate the files and rename them by time. I simply run this program on the staging area camera folder after the initial copy.

Once the files are renamed, I will open an image viewer/sorter/organizer to examine the take. The most important factors for me in an image organizer are speed, color management, speed, the ability to losslessly rotate JPEG images, speed, easy toggling in and out of full screen view, speed, and the ability to quickly launch an image editor or raw converter on a photo. Oh, and did I mention speed? I used to use gthumb for this purpose, but since they have not yet integrated color management into the viewer and generally stopped maintaining it I have now almost wholly switched to geeqie, which has gotten very good in the latest versions. Geeqie also has features for batch RAW conversion (using ufraw), assigning scores to images for your “selects”, and has a decent histogram and EXIF pane. It even has a half decent contact sheet printing function, and multiple version viewing option. Using geeqie I can easily scan the take, compare images and click to open the ones I want to work on in post.

The images tend to live in the staging folders for a while, and after a few months I will move them to a more permanent home in one of the other folders. I will only delete photos that are badly (and unintentionally) blurred; I save all the rest. Since I primarily shoot JPEG, storage is not as huge an issue for me as it is for some photographers. I try not to delete the images from the card until I have backed up from one RAID to my NAS or to an external USB drive. I rotate external drives for this purpose, and occasionally take them to the bank and swap them for ones in my safe-deposit box. For selects, I usually upload them to Flickr as well (pro account–full res), making sure that I have several disaster scenarios covered.

That pretty much covers the first part of the workflow: getting the images in. Next time I’ll discuss raw conversion and image editing.

Comments (3)

Older Posts »

Red Skies at Night