Cascade from this Version to the Version Set

Post Reply
gcorbin
Posts: 80
Joined: 21 Aug 06 12:31
Location: Brisbane

Cascade from this Version to the Version Set

Post by gcorbin » 29 Mar 21 2:49

For my JPG & Raw version sets, I catalogue the JPGs of the version set and then I cascade the cataloguing to the Raws. (Some cataloguing is automatically cascaded from JPG to RAW but some such as rating is not and I wish cataloging to be the same for Raw and JPG.)

For Casade to Version Set, I tick all for possible options (Cascade Image Details (XMP), Cascade Ratings, Cascade Colour Labels, Cascade GEO Coordinates) and OK to cascade the cataloguing. This works well except when I do a Verify Folder All, most of the photos are out of sync and require syncing. (They were in sync prior to the cascade.) Syncing fixes the issue, but just takes additional time, a long time for a lot of images. Cascading has made the images out of sync in version 5 as well as in version 6 so is not a bug but maybe a feature. I am currently using 6.0.0.3625.

Should cascading make my photos out of sync or am I doing something wrong?

Hert
Posts: 6831
Joined: 13 Sep 03 7:24

Re: Cascade from this Version to the Version Set

Post by Hert » 29 Mar 21 8:18

What would probably benefit you is the Cascade Metadata tweak as listed here:
https://michaelweidner.com/psu/
This is a user-to-user forum. If you need product support then please send a message

gcorbin
Posts: 80
Joined: 21 Aug 06 12:31
Location: Brisbane

Re: Cascade from this Version to the Version Set

Post by gcorbin » 29 Mar 21 20:19

Thanks Hert. This solves cascading the rating, but does not solve copying the XMP. (dwc:Taxon.dwc:scientificName and dwc:Taxon.dwc:vernacularName for example).

Resynchronising in V6 is significantly faster than V5 but I was just hoping to avoid this step altogether. I would have expected that Cascade would keep things in sync.

Mke
Posts: 589
Joined: 15 Jun 14 15:39

Re: Cascade from this Version to the Version Set

Post by Mke » 25 Apr 21 22:40

FWIW, I fully catalog my RAW files before creating JPGs, so that they end up with all the metadata included...

fbungarz
Posts: 1686
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: Cascade from this Version to the Version Set

Post by fbungarz » 27 Apr 21 1:17

Michael Weidner's "cascade metadata" registry tweak is very useful, but like you I would love if it worked across all metadata and not just color labels and star ratings. It would be such a time-saver trying to keep all metadata automatically in-sync across all the different versions. It's been on my wishlist forever, but I don't think it likely will ever get implemented...

One thing that does help and might be a somewhat useful workaround:
If you assign a mapped label top a version set, that label and its mapped XMP gets written to all files of a version set.

So, for XMP entries that you regularly write to different files, perhaps consider assigning those entries via mapped labels instead of manually entering those into their XMP fields? In my experience that works very well and it has the added advantage that one can search the tree easily for these labels as well.

Bongo
Posts: 55
Joined: 22 Mar 10 19:11
Location: Ingolstadt, Germany
Contact:

Re: Cascade from this Version to the Version Set

Post by Bongo » 29 Apr 21 8:51

Hi Frank, gcorbin.

Hm, with me all metadata in the versions are synchronized. All versions look identical.
Or I do not understand what you mean.
Regards, Bongo
Photo Supreme V6 Single User Edition, Windows 10.

gcorbin
Posts: 80
Joined: 21 Aug 06 12:31
Location: Brisbane

Re: Cascade from this Version to the Version Set

Post by gcorbin » 30 Apr 21 13:00

The Cascade Metadata tweak synchronises some metadata but not all. It does not synchronise the Darwin core fields of dwc:Taxon.dwc:scientificName and dwc:Taxon.dwc:vernacularName for example which I use extensively.

The Cascade to Version Set which Hert has implemented should do exactly what I require and copy the cataloguing to all members of the version set. Unfortunately, it is only half implemented and you have to understand that after using the “Cascade to Version Set” command, you then have to do a “Verify Folder”, “Verify Folder All” command to resynchronise the photo files updated by the cascade command as the “Cascade to Version Set” command does not keep the database and photo files synchronised. Using the command “Verify Folder”, “Verify Folder Quick” is not good enough to resynchronise the database and files and only the “Verify Folder”, “Verify Folder All” command resynchronises the photo files & database. This is a design fault in Photo Supreme as the database and photo files should always remain synchronised if you are not modifying the photo files external to Photo Supreme. I find it very strange that Hert considers this design fault acceptable.

Bottom line is I can use the “Cascade to Version Set” command to synchronise the metadata in my version sets. I just need to work around the design fault in this command by running the “Verify Folder”, “Verify Folder All” command on the folder containing all the version files to get the photo files and database back in synchronisation.

fbungarz
Posts: 1686
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: Cascade from this Version to the Version Set

Post by fbungarz » 30 Apr 21 17:26

Hi gcorbin and Bongo,
I think I can shed a bit light on this. It is a discussion I had with Hert for quite some time.

There is a reason, why PSu (and previously IDI) per default treats different versions in a version set differently when it comes to metadata.
Say you use your version set to keep multiple derivatives of your original data set together in one version and you want to use color labels to distinguish the different versions. With PSu's default setting you can do just that, assign a different color label to each different version in a set.
Or you develop the different versions from the main version and decide, although the original is not that great, one derivative (say a crop from the original image) is truly outstanding. So you might want to assign different star ratings to the different versions. Again, this is possible with PSU's default settings.
Michael Weidner's registry tweak gets rid of that. All versions in a version set will have the same ratings and color labels assigned. It no longer is possible to assign a four star rating to one version and a one star rating to another.

Now comes the metadata. Say you have group photo with multiple persons in that photo and you do a crop of just one person. The description: "group photo of dad's birthday party" is no longer accurate, because in the crop of dad's most favorite daughter shows just her and not the entire group anymore.
Thus, per default PSu allows you to write different metadata into the different versions. You can use the description field of version #1 to enter "group photo of dad's birthday party", but enter "dad's most favorite daughter" into version #2.

Even with Michael Weidner's registry tweak this is still possible. Although with the tweak the star ratings and color labels are synchronized, the metadata are not.

This is why gcrobin has such a hard time. You manually enter a species name into the Darwin Core scientific name field for one version, but that name is not assigned to all other images in the version set. Only cascading the metadata from that version to all other images in the version set will assure that the metadata across all images is synchronized (= the same in all versions of the same set). There is no registry tweak that achieves that.

While I understand Hert's reasoning that allows assigning different star ratings/color labels/xmp entries to different versions in a set, I believe it is still highly problematic. In my opinion this amount of flexibility is simply confusing and I wonder if anyone who extensively uses versions (like I do) makes use of that kind of flexibility. I can't imagine anyone who could keep track of which version would have which particular color label or star rating, or which one would have this headline or that headline.
To me this kind of flexibility simply sounds like a database nightmare. Why?
Because images in a version set are per default typically presented as a pile of images and throughout most of the catalog only the main version is displayed. How does it help to be able to assign different star ratings to different images in a version set, if you mostly will be seeing the rating of the main version and typically not even notice that the other versions in a set have a different rating?

Where this default setting becomes even more confusing is this:
You assign a catalog label to the version set. ALL images in the version set will automatically be assigned that same catalog label. Unlike with star ratings or color labels it is not possible to assign different labels to different images within a set. Now, while you can have the group photo labeled "group photo", you cannot label the daughter photo as "portrait" - they are either all "group photo" or "portrait" or both. I guess that is not too problematic, because a group photo is also a portrait, just of a whole group, right? But you also cannot label the main image individually as "dad's birthday party" and the subversion as "dad's daughter". Again the whole stack either is assigned one of the two labels or both.

Thus, the logic that applies to ratings and color labels, which is by design, isn't followed through, when it comes to labeling. I simply find that confusing and it took me a while to grasp it.
But I am VERY happy that this is how this works. I can use Michael Weidner's tweak to turn off the annoying "different ratings and color labels for different versions" and have those two "labels" work just as any other catalog labels:
I assign a rating to a version set, all versions are rated the same.
I assign a color label to a version set, all versions are rated the same.
I assign a catalog label to a version set, all versions are rated the same.

Makes sense to me.
Now, what does not make sense (in my workflow): I enter some metadata to a version in a version set and I need to manually cascade that entry from the one version in the set to all others.

My workaround:
Whenever possible avoid entering metadata manually. I instead extensively use mapped labels. So, instead of writing "Buellia spuria (Schaer.) Anzi" into the scientific name field of one version and then cascade it down into the others, I create a catalog label of that name, map it to the XMP field and assign that label to the whole set - and voilá, all images in the version not only have the label assigned, but each one also has the metadata written into the XMP field.

Ironically, I still often find myself cascading metadata. It is not always possible to create mapped keywords for all XMP fields. Thus, in the description field I often use macro codes to compile data from various other xmp fields to thus generate the description. I do that on the main version and then cascade that description to all versions in a set. But I sometimes forget and then find it moderately annoying that I have to cascade again and again...

It would be so much easier, if PSu was supporting a registry tweak that would always keep all metadata synchronized across all versions in a set. Some sort of a "always automatically cascade" mode.
Incidentally, I am not sure why one needs to find and apply Michael Weidner's registry tweak to change the default behavior for star ratings and color labels. Why that isn't simply an option in Preferences - I don't know. It seems a lot of people might want to use that version and not necessarily having to tweak the registry (which always sounds a bit scary).

Cheers,
Frank

gcorbin
Posts: 80
Joined: 21 Aug 06 12:31
Location: Brisbane

Re: Cascade from this Version to the Version Set

Post by gcorbin » 01 May 21 5:02

Thanks Frank for the detailed explanation. I am aware of the background of version stacks supporting different cataloguing. While I do not currently use the version stacks this way, I do understand the design choice Hert has made and have no issue with this decision.

Hert has also understood that some users, such as myself, wish to synchronise some or all the cataloguing across all versions of a version set, so he has provided a relatively simple solution for this, the “Cascade from this Version to Version Set” menu item. While this is not fully automatic, it is a simple and flexible solution which still keeps it simple to keep the cataloguing the same across all members of a version set. I have no problem with version sets and cascading across the version set. This is a reasonable and flexible solution Hert has provided.

What I have an issue with is the “Cascade from this Version to Version Set” is not implemented correctly. While it does work, it does not keep the Photo Supreme database and version set files in sync. This is a fault and needs fixing. This command should cascade the metadata while keeping the database and photo files synchronised. I should not be forced to run a “Verify Folder”, “Verify Folder All” command after the “Cascade from this Version to Version Set” command to get the database and photo files back in synchronisation.

To reproduce this bug, do a “Verify Folder”, “Verify Folder All” on a folder/folder tree containing a version set to verify all files are in sync with the database. Now, execute on a version set the “Cascade from this Version to Version Set” with all options selected to cascade. Lastly, rerun the “Verify Folder”, “Verify Folder All” on the folder/folder tree containing the version set and you will find all the versioned photo files are out of sync with the database. This is the issue. These files should not be out of sync. This is a bug in the “Cascade to Version Set” command and should be fixed. It is certainly not a drop dead fault which needs fixing immediately as there is a work around, but the bug should be fixed. Hert, can you please reconsider fixing this bug so the files and database stay in sync.

As for your suggestion on using mapped labels to apply the XMP, I have looked at doing this in the past and it is indeed an excellent solution. For each species, I can map all the required XMP so the photo files are fully and consistently completed with all the required XMP. What has stopped me is that I started with photographing orchids and am now expanding into birds and insects. Orchids alone is about 25,000 species, so would require 25,000 labels. Obviously, I haven’t photographed all 25,000 orchid species in the world, but I have photographed many thousands of species. Add another thousand or so species of birds and insect photos and creating that many labels is extremely daunting.

Now that species lists are freely available on the internet, we might be able to create all the required labels programmatically to fill out all the required Darwin core XMP. I might have a think about this and start a separate workflow topic to discuss this idea to see if there is any interest in pursuing this idea.

fbungarz
Posts: 1686
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: Cascade from this Version to the Version Set

Post by fbungarz » 01 May 21 6:20

Dear gcorbin,
that is indeed an odd bug that I never noticed before. It would explain why the "verify folders for files", which I use to add additional versions added via Affinity or PhotoLab, regularly suggests that I should read the metadata also from other files because they are not up-to-date, even though those files are not marked as out-of-sync. Good sleuthing. That IS indeed a bug that really should be fixed.
As for your suggestion on using mapped labels to apply the XMP, I have looked at doing this in the past and it is indeed an excellent solution. For each species, I can map all the required XMP so the photo files are fully and consistently completed with all the required XMP. What has stopped me is that I started with photographing orchids and am now expanding into birds and insects. Orchids alone is about 25,000 species, so would require 25,000 labels. Obviously, I haven’t photographed all 25,000 orchid species in the world, but I have photographed many thousands of species. Add another thousand or so species of birds and insect photos and creating that many labels is extremely daunting.
Very impressive. I am trying to do something similar with lichens, but "thousands of species"...
Now that species lists are freely available on the internet, we might be able to create all the required labels programmatically to fill out all the required Darwin core XMP. I might have a think about this and start a separate workflow topic to discuss this idea to see if there is any interest in pursuing this idea.
Yes, I know it is daunting. Bongo has recently got in touch because he was interested in setting this up for vascular plants from Germany.
Importing names as a formatted controlled vocabulary is the easy part, setting up the correct mapping schemes for thousands of names is the really daunting bi.
One challenge is to also include the higher taxonomy (family, class, order, etc.). And for some species groups taxonomy keeps changing. Lichens are notorious. Their higher taxonomy keeps shifting around with new molecular phylogenies regularly being published. But even new genera are described all the time and new species. A bit of a challenge keeping this up-to-date. But if you work with organisms and are an avid photographer, I find managing that data in PhotoSupreme extremely useful.

Cheers,
Frank

Bongo
Posts: 55
Joined: 22 Mar 10 19:11
Location: Ingolstadt, Germany
Contact:

Re: Cascade from this Version to the Version Set

Post by Bongo » 01 May 21 10:57

Aha. Verify Folder I only sometimes use files to import files.

I also use Registry Tweak. For me all versions should be the same.
gcorbin wrote:
01 May 21 5:02
Now that species lists are freely available on the internet, we might be able to create all the required labels programmatically to fill out all the required Darwin core XMP. I might have a think about this and start a separate workflow topic to discuss this idea to see if there is any interest in pursuing this idea.
I'm interested too.
Regards, Bongo
Photo Supreme V6 Single User Edition, Windows 10.

gcorbin
Posts: 80
Joined: 21 Aug 06 12:31
Location: Brisbane

Re: Cascade from this Version to the Version Set

Post by gcorbin » 03 May 21 1:04

I have started a new topic about using Darwin core in the Workflows forum.
viewtopic.php?f=81&t=28977
My hope is we can programatically create all the required labels to correctly fill out the Darwin core XMP fields.

Post Reply