Versioning controlled by labels

Mike Buckley
Posts: 1194
Joined: 10 Jul 08 14:18

Re: Versioning controlled by labels

Post by Mike Buckley » 16 Dec 12 14:34

David,

I understand your situation. I don't use a parallel folder structure, so I don't face the problem that you have.

If I remember correctly, you have IDimager Version 5. If I'm right about that, it seems to me that your best bet is to either not migrate to Supreme or to get all of your versioning done in IDimager before migrating to Supreme. Once you complete that process in IDimager and migrate to Supreme, it would be easy to temporarily store all of your newly captured images in the same folder or a nested folder structure. Once you have versioned them in Supreme, you could then easily move them into their permanent resting place in the parallel folder structure.

I have always stored newly captured images in a temporary folder structure and then moved them later once a particular photo shoot or series of shoots has been post-processed and cataloged. So, for me that could continue to be a reasonable solution to Supreme's relatively limited versioning capability.
lippe wrote: The truth is that there is no support in PSu for using different folders to store the Originals, Main versions and Derivates separately as proposed by thedambook.com and dpbestflow.org.
To clarify that, Lippe, Supreme supports two of the three practices proposed by dPBestflow -- storing the versions in nested folders and storing them all in the same folder. I don't know what The Dam Book recommends.

lippe
Posts: 296
Joined: 12 Aug 06 12:26
Location: Wondelgem (Belgium)

Re: Versioning controlled by labels

Post by lippe » 16 Dec 12 15:24

Mike,
I don't agree. I can import the images with nested folders automatically. No way PSu will create derivates in the nested folder. There should been some automatic way of handling nested folders with images.
Ex. When i want to open an image in Photoshop from the CV, PSu should ask me if i want to open an original image, or it should create a new derivate in an nested folder.
Lippe,
Photo Supreme V3, LR6, FPV, PSE14 - vaio i5 @ 2.5GHz + 8GB , 850 EVO 500GB - WD 1TB - Windows 10 Pro 64 bits- DS216play - EOS 600D

Mike Buckley
Posts: 1194
Joined: 10 Jul 08 14:18

Re: Versioning controlled by labels

Post by Mike Buckley » 16 Dec 12 15:46

Lippe,

If I understand you correctly, you're now referring to capabilities other than "versioning," such as creating derivatives. I was referring only to versioning, which is the thread topic.

David Grundy
Posts: 241
Joined: 13 May 07 16:40
Location: Hong Kong

Re: Versioning controlled by labels

Post by David Grundy » 16 Dec 12 17:10

Mike, I agree that logically I should finish the task in IDI5 before migrating. And at this stage it would be easy to go back. Except that ... I can't quite face going back to things like having to close and reopen IDI after most operations to ensure that the next selection of files via labels will actually be complete (as often it is incomplete if IDI has been open for a while; and the slow performance compared to PSu.
Now I'm halfway through the PSu trial and feeling spoilt ... PSu comes quite close to what I want, and is much more pleasant to use. Even though it's apparenty not the right tool for me (if I want to do versioning of my existing files) it's hard to go back to IDI5. ;-)
... David

David Grundy
Posts: 241
Joined: 13 May 07 16:40
Location: Hong Kong

Re: Versioning controlled by labels

Post by David Grundy » 16 Dec 12 17:25

Just to add one more thing (in case someone is busy thinking up solutions to the wrong problem) - my folder structures are not actually parallel. The originals are in folders by date of capture (with quite a lot of tweaking to the structure for various reasons; whereas derivatives are in a separate folder structure organised by date of image editing. So any solution which relied on the two folder structures being the same won't work well, and anything which relies on moving all the originals into the same folder, and then sorting them back into their date folders afterwards, also won't work unless I decide to give up the tweaks to the strucutre (since they can't be recreated automatically). I do prefer to keep these strictly separate so that it's very clear which are the original never-to-be-damaged-or-deleted files.
I would consider making the two structures parallel, although it would be a bit complicated to get there because of dealing with cases where there is more than one derivative (on different dates and hence in different folders but with the same filename) from the same original.
... David

lippe
Posts: 296
Joined: 12 Aug 06 12:26
Location: Wondelgem (Belgium)

Re: Versioning controlled by labels

Post by lippe » 16 Dec 12 18:08

David, if the "date of capture" is not the same as the derivatives "date of image editing". How do you find a derivate by just using the file system? Are the filenames identical?
Photo Supreme V3, LR6, FPV, PSE14 - vaio i5 @ 2.5GHz + 8GB , 850 EVO 500GB - WD 1TB - Windows 10 Pro 64 bits- DS216play - EOS 600D

David Grundy
Posts: 241
Joined: 13 May 07 16:40
Location: Hong Kong

Re: Versioning controlled by labels

Post by David Grundy » 17 Dec 12 16:04

*ahem* I admit to having been inconsistent over the years. Every system seemed like a good idea at the time ...

Usually, there is a root to the filename which is the same across all versions. Usually, it's yyyymmdd hhmmss, unless it's yyyymmdd ##### or yyyymmdd ### or something else ...
Usually the original file has just the root. But not always.

In pre-database days, selects were tagged by adding the string hh or hhh or hhhh in the filename. (That way if you search the file tree for, say, "hhh" you get all the files with "hhhh" as well.) This would carry across to derivatives, which would also have additional suffix to indicate whether they were edited.There may be multiple copies in various collections, and the idea is to transform those collections into sets of images labelled with File Management | Display Set | [whatever] instead of having a separate folder for each [whatever]. However, in some cases the "hh..." tags were altered in some versions but not others, so the original may have say "hhh" while some derivatives do not.

To make things worse, some files were renamed from yyyymmdd hhmmss to yyyymmdd nnnnn or similar, but the derivatives weren't always renamed at the same time. This was not intentional but I didn't notice for a while. Too late to go back!

Then, the oldest files don't have originals, they just have the edited verisons. Then there's a bunch with original jpegs and edited jpegs. Then there's newer stuff which is mostly DNGs, with occasional jpg derivatives when the effect I wan't can't be done in ACR. Or sometimes there are several derivatives because I like more than one interpretation.

A bit of a mess really. If I could just make some time to fix it all ... but the reality is when I have that time I don't want to use it for manually sorting photos! Thus the mess continues.

The one thing that has remained constant is that derivatives are not stored in the same directories as the originals. I'm just too careless for that sort of system to be sensible for me.

... David

David Grundy
Posts: 241
Joined: 13 May 07 16:40
Location: Hong Kong

Re: Versioning controlled by labels

Post by David Grundy » 30 Dec 12 13:05

Here I said,
David Grundy wrote:Suppose I have a whole set of images. I decide to create a black and white version of each of them for a project, using an automated process in Photoshop, and I want to associate each of the new B&W files with the original images as versions. How can I get all of these Black and White versions to end up in a custom-created "Black and White" placeholder? I don't see how this can be done except by reassigning the placeholder for each image individually.

Whereas with the facility to apply a version placeholder change to a whole set of images, this could be done in a single operation.
Hence Concern #1: How to reassign image placeholders for batches?

At the moment it feels to me as though the versioning implementation is unfinished. You can get files associated with each other, but I don't see a sensible way to manage the versions and placeholders for sets of images. As far as I can see at the moment, if you make a mistake as to which is the main version when importing a bunch of files, the only way to fix it is to remove all the accidental main versions from the database, and reimport them is subsidary versions. And as mentioned above I don't see any way to make sure that newly imported versions end up with the correct placeholder.

Hence Concern #2: It will be hard to fix versioning mistakes.

Additionally ...

In the example above, I don't see any way to get the B&W images associated as versions of the original images in the first place. Most likely, the files selected for the B&W project are dispersed across many directories - specifically, they will come from different years and months, so they will be in different folders on the disk. The only plausible way to get the B&W images associated with them seems to be to make sure that my automated Photoshop process outputs the B&W files in subfolders of the individual original files. Otherwise the "subfolder" versioning approach currently implemented won't work for these files. But this is not how I work - rather, the new files from the automated Photoshop process are always output to a single specified folder, so that I have the chance to check them over. This prevents some sorts of accidents where Photoshop actions don't work as expected, and specifically it ensure that my master image folders don't get cluttered with mistakes or unfinished work. I do not want to change this part of my workflow. I would rather abandon versioning.

Hence Concern #3: the subfolder versioning approach seems to require me to change the way I organise my files, in a way that reduces my protection from processing mistakes.

I am hoping Hert is just waiting for a bit more discussion before implementing a more complete and flexible versioning solution. The current approach is superficially simple but is actually complicated because of the time needed to work out how to do things within the imposed limitations. In fact it's sufficiently limited that I think it would be better for me not to use versioning at all. In which case I wonder why I need PSu ...

At this stage I have two days left of the PSu trial and I haven't yet reached the point of being convinced. It's nearly plausible ... but it just doesn't yet do enough. I don't see the justification for changing my file organisation completely, just to get an inflexible sort of versioning implemented.

Again I would say that I think this is a "false simplicity": important capabilities are not (yet?) available, and this makes the use of PSu more complicated in practice. A well-designed dialogue which makes it clear exactly what will happen is much simpler to use than a minimal dialogue where we have to guess what will happen, and design workarounds to get the behaviour we want. Perhaps the whole versioning thing should be seen as "advanced" and could be disabled until a user decides to deliberately enable it in the preference. Or, as suggested for some labelling features recently, have the ability to click on an icon somewhere (in a basic dialogue box, or elsewhere) that brings up a full-featured versioning dialogue.

... David

Post Reply