One of the best things about Photoshop CS3 is the improvements in stitching, and Lightroom’s product manager Tom Hogarty is one of those who is shooting more panoramas. Asked in this interview what he’d most like to see in 2.0, he says:

That’s a good question. Let me think about that for a minute. For my own work, I’d like to see it go beyond the 10,000 pixel limit per side because I have been using Photoshop CS3 quite a bit lately and using the auto align and auto blend features to make ridiculously good panoramic images on the fly. I want to bring those back into Lightroom so I can print them and I think the hundred million pixel limit we have for image files is frustrating for a lot of people. With the new panoramic tools in CS3, that limitation is getting a bit more pressure now.

The follow up question asks about future plans for doing the stitching in Lightroom. That’s fair enough, but as usual the focus is on the image processing – and the management side needs work too.

These comments don’t just apply to Lightroom but to DAM in general. And I’m widening the issue beyond panoramas and embracing other multiple frame techniques (MFT). MFT includes all types of frames that we now shoot for later assembly into a single image – images shot for high dynamic range (HDR) blending, for elimination of moving objects by registration (Photoshop’s smart object stack blending modes), noise reduction, simulated multiple exposure. We are on the verge of an explosion in this type of work, and managing these pictures is going to get painful – if it isn’t so already.

Right now I manage such sequences of images by entering the first frame’s file number in an iView custom field. So the 13 frames of a panorama, or both frames of one of my infrared sandwiches, share this code which is also recorded against the final stitched image. This makes it easy to find the originals or any derivatives, for example if I need to repeat or revise the final composite. It works, partly because I am very thorough with such things. But even then, more than once I have deleted a badly-composed shot, only to realize (not too late) that it was intended to be the middle frame of a panorama.

Stacks are a very promising way to control MFT frames. But Lightroom, like all other programs with this feature, uses a “best of burst” approach, stacking a sequence of frames and showing the best one on top. But a “best of burst” view doesn’t represent the variety of MFT – panorama stitching, HDR blending, noise reduction, smart object stacking in Photoshop CS3. You can obviously put the frames into a conventional stack, but which is the best image in a panorama or the correctly exposed frame for HDR? Obviously once you’ve done the stitching or blending you might use the PSD/TIF, but that’s no use when you’re doing your initial evaluation / organisation, or when you have filtered the library to show only the originals.

Conventional “best of burst” stacks simply don’t give any visual clues for these types of multi frame photography, and there is a huge risk of the user discarding individual frames. So we need 2 things – a meaningful way to visually represent different reasons for stacking,and protection for the individual members of stacks.

Thinking of Lightroom, the first part of the solution leaves the underlying mechanism as it is now, but users would have to choose a “stacking type”. One might be “best of burst”, so exactly as now, but choose “panorama” and the thumbnail would be shown as a strip of tiny thumbnails, and “blend” would give the thumbnail a more 3d stacked appearance. Now the user can see exactly what type of images are present in the stack.

Secondly, once an image is marked as part of a stack, it should be protected. I’d even like to see it made read only, but as a minimum the the user should be prompted if he/she tries to do anything dangerous to an image that belongs to a stack. The next time you plan to stitch that panorama and discover that the middle frame is missing – and you may have emptied the trash – you’ll appreciate these features.