best practise to organise HDRs and/or panos?

[akirot]

I'm very strict at organising my raws and processed versions and use file relations heavily. Thus I can always find all versions of a processed raw easily and vice versa. It is a one to many relationship, i.e. one raw can have from 0 to many developed versions.
Now as I'm producing more and more HDRs and Panos I wonder how to organise this. Many raws are merged to a HDR or Pano which itself is a new raw and processed as before.  I use stacking to organise the HDR or Pano sources - this is done manually and I think I can't automate this (due to the selection of source images in scope). I'm fine with that. As soon as the new HDR or Pano raw is created I think it would be a good idea to mark this as a version of the underlying sources. (Itself it becomes the master of all further developed versions.) One can do this manually again but I don't like this approach since it hinders my workflow.
I wonder how you do that - any tips ideas?

[Carlo Didier]

Hi!
Personally, I also stack the component images of HDRs or panos under the resulting image, but I don't create a version relation.
I do automatically assign the source images to a special category which tells me that they are part of a pano or HDR.

My naming system allows me to immediately identify the source and resulting images. Examples:
Panorama image D2150821112-117_pano is stiched from images D2150821112, D2150821113, ..., D2150821117
HDR image D2151103022-024_HDR  is made from images D2151103022, D2151103023 and D2151103024

[ubacher]

I put the component images for a panorama in a sub-folder named PANO. This I do because I want to
process the RAW's for panoramas all together. And this way I don't see the source images in my top directory.
I mark the images with a category Part_of_Pano and the first image
of a series as First_of_Pano (color coded!). The first one also gets a 1 star rating - this in order to show up in Adobe Camera Raw.

I have a script which takes the selected files and marks them (moves them).
Another script, when on a first image, finds all of the set and passes them to Microsofts ICE for assembly.
ICE by default names the resulting file from the first file and appends _stitch. This suits me fine and I use this naming to find
assembled panos and move them up one level i.e. out of the PANO folder.

This I have since the days of IM3. In the early days of IM5 I spent quite some time trying to use stacking but
I found it so confusing and limited (at the time) that I gave up using stacking. The problem I recall was dealing with RAW and jpg
files (i.e. dependencies) in the stack.
Stacking is the logical way to go - and I assume the logical top of the stack would be the assembled panorama (but what if there are
various versions?)  I am interested in any good/clever/workable solution users come up with.

All this is also applicable to HDR images and to sequences which get assembled into GIF's. I also deal quite a bit with stereo images where
it gets quite a bit more complicated because of the many different "input" images and the many possible "display" images.

[Carlo Didier]

... (but what if there are various versions?)  ...

In my case, I may have a panorama D20151123110-118_pano.TIF and versions of that would be named D20151123110-118_pano_a, D20151123110-118_pano_b, etc (file extensions are irrelevant).
Only the base (master) stitch would be on top of the stack. The versions don't need a stack as they don't refer to the source images directly, but to the master.

[akirot]

Thank you for providing feedback.
Seems you are facing the same challenges as I do.
To complete the description of my current approach: I write the names of the merged sources of the new master/raw file into the "instructions" metadata field - thus I can always trace back. The new raw gets the same filename as the first merged file extended by "-HDR" or "-PANO". I also put the new raw on top of the stack.
I don't like the idea of putting relevant information into filenames for further processing. To me filenames might give a clue but I never build some automated processing on it.
I also used "rating" to identify the files when switching from Imatch to Lightroom. Meanwhile I have abandoned this approach. As soon as you have imported the files into Lightroom (and rated later in Imatch) you have to reread the metadata in Lightroom. I find it easier to remember the filenames when switching from Lightroom to Imatch.
I'm keen on getting further input :-)

[ubacher]

You say:

I don't like the idea of putting relevant information into file names for further processing.

But then you too appended PANO to your file name to distinguish the assembled image from the others.
I assume you mean that you use categories or other metadata to "label" the file as an assembled panorama.
So do I.

[Carlo Didier]

I used my naming scheme so that when I save a stitched pano (or HDR), just by giving it the correct name, everything else is automated. The event script can, based on the name alone, identify the type of composite image (pano, HDR, ...), which one is the master image and which are the component images, assign the categories and create the stack. Apart from giving it the name, I don't have to do anything else. Guess I'm lazy 

[akirot]

Yes, the files also are categorized as HDR- or Pano-Masters - I forgot to mention.
Technically the filename I assign can be any combination of valid characters - thus why not appending HDR or Pano. To me is important no further processing depends on it.
At the same time I fully understand why someone does it differently.
This is why I started the discussion - learning the various approaches.

[sinus]

Apart from giving it the name, I don't have to do anything else. Guess I'm lazy 

No, clever, to do so. 

[Carlo Didier]

Apart from giving it the name, I don't have to do anything else. Guess I'm lazy 

No, clever, to do so. 

Some say you must be clever to afford being lazy ...

[ubacher]

Carlo says

.... just by giving it the correct name, everything else is automated.

I take the opposite approach: I mark the constituent images and have everything after automatic
(via scripts).

[Aubrey]

I like the term "constructive laziness"

[mastodon]

I used my naming scheme so that when I save a stitched pano (or HDR), just by giving it the correct name, everything else is automated. The event script can, based on the name alone, identify the type of composite image (pano, HDR, ...), which one is the master image and which are the component images, assign the categories and create the stack.

Would you please share that script?

[Carlo Didier]

Sorry, I had completely forgotten about this topic as I was still working on the script and many other things. Attached is my database script file and some screenshots. It's always a work in progress, but I hope it might be useful to you.
The main things I want to achieve are:

- rename new files with the name ending in "_PANO" (default for images stitched by ACR) to "_stitched". I could do this during the saving, but this way it is automatic and I won't risk forgetting it 

- for new files:
    check if the new file is a version of an existing file and if yes, propagate certain categories from the master to this new version (why can't iMatch do that automatically?)
    if the file is a composite of several source files (like an HDR or stitched image), assign corresponding categories to the source files and the combined file (HowCategories.jpg)

- upon file updates:
    automatically assign format categories of my own definition (vertical, horizontal, panoramic, square, ...)
    automatically assign events by evaluating the file name (containing the creation date) with descriptions of event categories (EventCategory.jpg). This makes the assignment to events totally independent from potentially wrong time stamps in metadata and also correctly assigns derived images (like HDR or panos) as their names contain the correct date, even if the metadata shows other dates

This is all very specific to my workflow and if Mario drops the Basic scripting support without providing new tools to do the same things, I might stick to the last version where this works and not upgrade anymore, because these functionalities are at the core of my workflow and I would either have to do it all manually or completely change my workflow and category organisation ... not a thing I want to do with a 60000+ images database ...

[Erik]

Sort of off topic and back to the original post, I don't do anything too special when making composite images other than make sure that the derived images fall in line with my overall naming scheme.

Like others, source images for a Panorama or HDR are manually stacked together.  This allows for the occasional mistakes where an image was potentially taken out of order or sequence (i.e. I suspect a gap in a panorama or I notice that the shutter speed got to slow on an HDR bracketing sequence).  The source files (RAW) are just named as all my original files are.

All the images in the resulting stack are keyworded and categorized the same (besides perhaps Exif related categories).

When a composite is created, it is named using the root file name of the first image in the stack (chronologically).  This essentially moves it to the front in terms of file naming (or right near the front).  The file name for the composite is usually like this:

Root-Pxxx10 or Root-Hxxx5

P indicates panorama and H indicates an HDR.  The number indicates the number of original images that were combined to make the image.  The xxx allows me to identify the software used and is optional.

I use the Version relations to take care of propagation to the composite from what ends up being one master.  I use a special version relation for these (based on the P and H in the file name) so that the Exif is not propagated.  And, for all my versions I utilize the file name for some data driven categories that identify type of image and software used to create it.

I will likely check out this script or the idea behind it.  It might prove useful, but I've been happy to avoid a script with my workflow.

[suttonbg]

I wanted to avoid scripting to solve this problem, so settled on a simple colour coding system (yellow labels for HDR, blue for panos, purple for stereo etc) that can be applied in Adobe Bridge and migrates  directly to ACR and IM5. All originals (RAW, derived dng's and tif's) are labelled, but the final image is not.

When cataloguing images in IM5, which I only do for the final image, I simply select via filter for the yellow and blue labels and invert the result, and then filter for dngs or tifs to have only the final images visible in the file window. Too easy and this way, Mario has done all the work.

Bruce

[Carlo Didier]

A perfectly valid workflow, Bruce. But you have to manually label ...
I avoid manual stuff as much as possible if I can automate it, because then there's less errors and I don't risk forgetting a step. It's all about laziness and reliability