Faststone stores Rating in its own database not in the Exif/XMP metadata of the image. Therefore, PL cannot see it.
2 Likes
@Joanna I suspected as much and thank you for clarifying that.
@tmyrick As far as I can tell what is ‘Rated’ in FastStone stays in FastStone as @GaoGao has also stated, which is sad because the product is quick and easy to use. It is also possible to render RAW images but much slower than FRV.
In truth I didn’t even know about ‘Rating’ in spite of using Version 7.7! It was introduced in release 7.6 alongside the improved database, which I did know about and offers useful facilities but FastStone doesn’t appear to have any settings to embed that metadata in the image nor any way to import that metadata from the image!
Sadly the method that FastStone uses to pass images to an external program is to send each image as a single “package” so if I pass 5 images to XnViewMP I get
With PhotoLab only the last is accepted
While I am sure that the writers of FSIV thought it was a good way of passing images, FRV and XnVIewMP pass the images in such a way that they arrive as a “single package”.
123 images passed very quickly from XnViewMP to PL6.5.0 (PL6.6.0 is downloading as I write this, inadequately identified as usual and PL5.11.0 is also available and I do appreciate DxO keeping PL5 “alive”)!
DxPL downloads (I forgot to assign the correct designation before starting the download)
XnViewMP is as bad, FastStone and FastRawViewer contain the version number in the download title!
@Stenis I understand your use of the PM product(s) and may consider it next year, in the meantime I need to give IMatch a bit more attention. It is slower because the author tends to run many processes in the background to keep the foreground program available and to avoid lock conflicts with other programs so when using it for testing it appears ponderous!
I thank you for this input and it made me check the integration between PM, Photolab and XnView again.
So far, I never use rating but I have checked how it works in my flow.
I use just three-color labels and it is red, yellow and green. A completely untouched image is black as the border. Red is checked but untouched except for some real basic metadata (where images are taken - and event), Yellow is a signal for “in progress” and Green, completely processed and metadata in place. I also add “tagged” to them because it´s a handy flag to use when searching.
When the sync flag is set in Photolab the sync between PM and Photolab is instant and very reliable. BUT since I just have used these three colors, I had overlooked how the other labels in PM was handled by Photolab. That I have fixed now.
Since I haven´t found a way to change the color set in Photolab, I had to do it in PM to get it to match in both applications. This is a thing you have to do if you use Lightroom instead of PL too.
This is the way I have set it now in PM to match the colors available in PL. PM is very flexible here and you can pick really any color you like and write the labels of your choise.
As you can see above, I have applied both Rating and all the eight labels available in PM - one label to each selected image.
I then opened “Edit with Photolab” that I have configured in PM and I also have Photolab opened in parallell in the background. In this case it´s just eight images but I tried with 100 images and it´s really fast opening the thumbnails despite som rendering is going on for a short while in the background.
What happens also is that PL creates a record in the “External Searches” - list that can be opened anytime later. I like that feature a lot and use it often. Today you can´t name the searches manually and if I want to, I have to create a “Project instead”. In fact, a search is just an unnamed Project, because they are handled in the same database tables.
In PL the mark up of colors and labels looks exactly as in PM now after configuring this color match in PM it looks like in the screen shot above.
XnView though is a very different story. I have tried to configure it too but it can´t be done. Labels can be edited but I don´t see how the colors can be changed. It ought to work (but it doesn´t) but the only color missing compared to PM and PL is “Pink”.
To wrap it up
The integration works really well between PhotoMechanic and Photolab for both Rating and Labels and the “External Search” in Photolab is a very nice asset when using it together with both PM and XnView. The sync between PM and PL is instant and very stable and reliable. The XnView not so. What I use XNView to though is as a viewer to conduct slide shows and also to spot images I have missed to add metadata to. When working in PM with metadata batching is used frequently and it is easy to forget a few, but since XnView uses small label indicators at the previews for the different metadata it has found (automatically when a folder is opened) it has its place, because in that respect it´s far better than PM. Especially when it comes to giving you a quick overview of the images updated with GPS-coordinates.
The PM interface is very good and effective when applying GPS-coordinates and when it reverse lookup a lot of geo metadata and updates 10 geo data elements but it is far too cumbersome if you just want to have a quick overview.
I really like a lot about XnView, but it for sure has its flaws but if you know them a bit, I think it still has its place in my tool box. The Labels and the Rating-elements values from PM gets stored in XMP but XnView does not read that data. Instead, it reads the “File Properties”, but all the other metadata (IPTC and XMP) - is read, handled and displayed correctly. I have tried to configure both the XMP variables {XMP:Label} and {XMP:Rating} that ought to display that relevant XMP-data under the thumbnails but unlike other similar variables they just don´t seem to work. I guess you can´t expect to get a gate to “heaven” out of a free software like XnView all the time.
@Stenis Thank you for your compatibility testing.
I had to adjust the Colours used in FastRawViewer (FRV) when the feature was added to DxPL, the world obviously revolves around DxPL, and I agree that DxPL should have the same flexibility!
but
there is still some disparity as shown in the snapshot below where the color labels were set by PL6, with XnView (top) versus FastRawViewer (below) versus IMatch (right hand side) versus DxPL at the bottom (all live preview windows, no snapshot editing here)
FRV lacking ‘Orange’ and ‘Pink’, XnViewMP lacking “just” ‘Pink’ (as identified by @Stenis) and IMatch, originally lacking ‘Orange’ and ‘Pink’ but configuration allowed the colours to be added and a display colour to be selected and saving the changed ‘Preferences’ resulted in the colours appearing in the thumbnails a few seconds later, the way that things should be done!
We have to look in the XMP. Some applications confuse us by using both colors and numbers in the interface and drop down-lists where we select the labels - like Photolab. In XnView they use colored stars with a number in them and the numbers might just be used as short cuts when selecting, despite the name of the colors misght be what is actually stored.
There also seem to be some problems in the flow between some applications which I have stressed below. The same data might be forked when sent to one application from another but not when applied in another. The flow between PhotoMechanic and XnView is one of these examples. Label and Rating-data stored in Label and Rating in XMP is for example not read by XnView that reads other fields in the file Properties instead.
Many applicatoons like Photolab seems to stress that they maintain IPTC but reads in fact XMP and others works the other way around.
PhotoMechanic is mixed but have strange limitations too. XMP is by design extensible (Extensible Mark Up Platform) but PM is not at all extensible, because the whole application interface is ITPC (like Photolab with a few exceptions) and of some reason it doesn 't support the possibility to create your own namespaces like most other DAM do.
When I tested the Label-integration I got it to work between PM and PL but I don’t really understood why it worked but I guess it reads the text labels I wrote in PM. Some of the colors i picked out ofca rainbow-box, so they a re just a RGB-code I guess.
“The world obviously revolves around DxPL” 
, that is fun.
What happens if you use “Magenta” instead of “Pink” in the “Text-label”?
I guess you need both pink and orange with all those flowers!!
All these different metadata sync problems really expose how immature this metadata handling business still is after all these years. We are still hanging there between EXIF - IPTC - XMP - and the filsystem metadata like “Properties”. Concerning “Properties” in Windows I think it’s still a mess. Of that reason we have to add metadata in quite a lot of different fields to be sure they won’t be left empty in Windows “Properties”. I think this ought to have been sorted a long time ago and not be left for the users to sort when using software that depends on exchanging metadata. This still is so bad and very depressing. ( Sorry for earlier spelling I´m not not a friend of pad keyboards).
1 Like
@Stenis This is the result of setting ‘Rating’ in XnViewMP and because these are RAWs, DxPL detected the changes automatically, as did IMatch, FRV only ever detects them after a user initiated ‘Reload’ and Zoner detects them in real time and offers a similar colour allocation scheme to IMatch (sadly the current purple configured for Zoner is more like a pink I feel but they can all be altered)
Note that XnViewMP typically uses the tiny field in the top left of the thumbnail but with the following configuration you get what you see above
It certainly doesn’t revolve around the users (an exaggeration but sadly with more than a little truth I feel)!
Those pictures are from the front-garden yesterday and some of the (hardy) geraniums are just getting going!
I was going to say no yellows (or Orange) but we have a potentilla with a small yellow flower out now but that is it for yellow I am afraid until a bit later when we have some yellow roses.
Arguably the “excuse” that can be used when things don’t work as well as they might although the above is not too bad. However, FRV can’t handle keywords, Zoner only handles simple keywords but XnViewMP seems to go for a full house!
Set by
Now that is promising and DxPL sees that as
It is a little disappointing but it is certainly not all bad although remembering which bit of software does things one way and which the other is … confusing!?
1 Like
Very good that they have got the keywords right.
The problem though is that they still haven’t sorted the Label and Rating.
Setting the display of “Rating+Color label” in Settings-Thumnails- Labels doesn´t work for the XMP “Label” and “Rating”. They are totally different variables in a totally different metadata source (or namespace) that doesn´t get read and displayed by XnView at all either over or under the thumbnails.
The metadata I add in PM for Label and Rating can be seen even in XnView under the namespace of XMP under the XMP-tab but I can´t call it by manually build an XMP-variable for example {XMP:xmp:Label} or {XMP:Label} (have tried both) that calls for that data in the Settings. because the variable “Ratings+Color Label” is reading the metadata from “Properties” instead (se “Properties”-tab in XnView).
Here are six images from PM
The same images in XnView
As you can see below there are no XMP-variables in the list, Just EXIF and IPTC. I think that also is a proof that XMP is just not supported.
Back to the second image and the “Properties-Tab”
Here this image (which also has been updated in XnView) has not been rated but has been marked green (se both top and bottom of Thumbnail.
… and if I click the XMP-Tab instead i see that Label is Green and Rating is 5, which it is both in PM and Photolab and also ought to be in XnView when status is displayed with the thumbnails.
So as I earlier wrote: XMP is passed from PM to XnView both for Label and Rating BUT are not used when status is flagged. The metadata you update in XnView for Label and Rating, stays in “Properties” and cannot be seen either in PM or Photolab that instead reads the XMP.
I think XnView ought to be corrected. The data is there and gets there automatically so it shouldn´t be all that difficult, because the rest is working correctly when using XnView as a data consumer
@Stenis It is late so I will try to read you post more fully tomorrow but …
I set up a new directory for XnView to set the ‘Rating’ and ‘Color Label’ and set from 1 * to 5 * in the copied images (only the RAW was copied) and immediately this is what happened
I did nothing except set the ‘Rating’ in XnViewMP and all programs discovered the values as soon as I navigated to the new directory in the various programs!
I then set each color in turn and this happened automatically except for FRV which needed a ‘Reload’
Things seem to be working just fine with XnViewMP in the “driving seat”!?
PS:- I just updated the second snapshot with one that doesn’t cut through the PL6 color labels!
and please note that I changed a color in XnViewMP as follows
but couldn’t find any way to change the colour that XnViewMP displays (as a mentioned in the earlier post) !!
IMatch with the two additional XnViewMP colours (‘Grey’ & ‘Black’) set up
I have tested again and it looks better after changing the Settings i XnView. Here is how I have set it now:
It seems to work fine now with PhotoMechanic but of some reason it doesn´t seem to be fully reliable in Photolab. In Photolab the Label colors get updated in both JPEG and RAW but Rating just seems to work in RAW.
I also can get it to work with “Pink” if I just change the color name on White in XnView. Well I will not update fron XnView so there are no problems now and the Label color is displayed OK below the Thumbnails now too and thats god.
It´s still the case that updates made in PM doesn´t get reflected in the Label Statys banner of the Thumbnails despite the data is there in the XMP, so I don´t get XnView to update the Label and Rating in “Properties” and that is the reason that the Thumbnails symbols is not getting in sync after update.
They still have som work to do I think.
I don’t know the best post to join in from, so let me start a ramble here.
First, there’s the problem of dealing with IPTC metadata.
From what I have researched, IPTC (standalone) was originally based on something called IIM, which, apparently, should be considered “legacy” or “deprecated”. If you look on the IPTC site, you will find a lot of interesting stuff, which talks about it better than I can but, if I have it right, IPTC has been subsumed into XMP and that is the way everybody should be heading. It’s another Adobe standard so, presumably, the world is meant to stand up and take notice.
Unfortunately, like so many Adobe standards, the world seems to take the attitude of “so what?” and continue doing what they’ve always done, regardless of compatibility.
It would appear, however, that DxO has decided to implement IPTC in its new incarnation as part of XMP. Unfortunately, that may be at the cost of backwards compatibility but they, and we, have to ask the question, just how long can they and we support legacy metadata, given that there have been several “standards” over the years. Not forgetting that IPTC metadata can be codepage sensitive, which is not ideal for modern multi-lingual, multi-regional apps.
Then we have the problem that prompted this thread - ratings and colours.
Rating, as in a star rating, normally gets written to the xmp:rating tag but, if a camera is capable of writing it, it goes in the exif:rating tag.
Windows adds another complexity as it adds in the ratingPercent tag, which is also available under both xmp:ratingPercent and exif:ratingPercent tags.
Looking at the ExifTool documentation…
| Tag Name | Values / Notes |
|---|---|
| Rating | (a value from 0 to 5, or -1 for rejected) |
| RatingPercent | (non-standard) |
But then we also have…
| Tag Name | Values / Notes |
|---|---|
| xmp-acdsee:rating | (which appears not to be limited to any particular number range) |
| xmp-dex:rating | (which is a text tag, and thus not limited to numbers) |
| xmp-prism:rating | (which is a text tag, and thus not limited to numbers) |
| makerNotes:rating | (assumed to be a number as it can only be set from within the camera) |
| xmp-iptcExt:rating | (which is a structure, containing the following sub-tags… |
| RatingRegion | |
| RatingRegionCity | |
| RatingRegionCountryCode | |
| RatingRegionCountryName | |
| RatingRegionGPSAltitude | |
| RatingRegionGPSLatitude | |
| RatingRegionGPSLongitude | |
| RatingRegionIdentifier | |
| RatingRegionLocationId | |
| RatingRegionLocationName | |
| RatingRegionProvinceState | |
| RatingRegionSublocation | |
| RatingRegionWorldRegion | |
| RatingScaleMaxValue | |
| RatingScaleMinValue | |
| RatingSourceLink | |
| RatingValue | |
| RatingValueLogoLink |
Is it any wonder that there is confusion? The xmp:RatingPercent tag seems to be mainly used by Windows.
Some cameras can set a rating for an image. Nikon use the standard xmp:rating tag but others use the makernotes:rating tag. Yet another non-standard for any metadata management app to cope with. What is more, although PL can read the rating from the RAW file, any change in PL will write the new rating to the XMP file and leave the rating in the RAW file untouched.
The xmp:label tag is a simple text tag, which has no implicit correlation with any colour. And this is where confusion arises, because an app running on a computer localised to French can write Rouge, Jaune, Vert, Bleu, etc; but the same app running on a computer localised to English can write Red, Yellow, Green, Blue, etc.
And, as can be seen from @Stenis posts, certain apps store a lookup table of “names” that can be related to colours. This causes problems when something like Adobe Bridge, where the labels contain words like Select, Second, Approved, etc, for which only Adobe Bridge knows which colour they refer to.
Because DxO have chosen not to implement a user managed lookup table, all labels get written in English, as their English colour name, in the xmp:label text tag. So, any file with the French colour Rouge shows as not having a colour label.
Perhaps we should add a feature request for a user managed lookup table for colour labels?
2 Likes
Very good summary Joanna!
Have no time right now but will comment it a little later.
I totally agree on they (the software manufacturers) and we have to move to use XMP fully.
That means using IPTC as an embedded namespace in XMP.
1 Like
@Stenis and @Joanna XnViewMP works as expected by me, i.e. XnViewMP needs to be configured to NOT use sidecar files for JPG etc. and then
- ‘Rating’ and ‘Color Label’ are updated automatically as they are changed in XnViewMP.
- Keywords are updated in the XnViewMP database when changed by the user and in the file when forced by the use of
- This works for both JPG and RAW file (via sidecars in the case of RAW files)
BUT
As as I have written so many times @Musashi the change detection code for DxPL is flawed and it is a bug that is not shared by any other automatic detection software I have used. DxPL relies on the ‘Date Modified’ field being changed and if that change does not occur then DxPL considers that nothing of note has happened!!
I detected this in my first tests on PL5 Beta because I used ExifPro for testing and it makes changes to JPGs without changing the ‘Date Modified’ field and now it appears that XnViewMP does exactly the same. Zoner is happy and detects the change regardless, as does Bridge and other software but not DxPL!
Here is a section of the log from a program called ‘Folder Monitor’ which has been set to monitor the JPG and RAW test directories.
When changes are made to the RAW files a short while later there is activity involving the DOP file, indicating thet DxPL has detected the changes and reflected them in the display, in the database and finally in the update of the DOP.
No such activity is detected and actioned when a JPG is changed!
Only when I updated the ‘Date Modified’ timestamp manually does DxPL consider that something noteworthy has occurred!
*
** Changing Rating for RAW via XnViewMP
*
2023-05-20 22:29:52.882: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.xmp modified
2023-05-20 22:29:52.956: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.xmp modified
2023-05-20 22:29:52.956: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.RW2 modified
*
** Detected by DxPL
*
2023-05-20 22:30:10.338: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.RW2.dop created
2023-05-20 22:30:10.371: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.RW2.dop modified
*
** Changing Color Label for RAW via XnViewMP
*
2023-05-20 22:30:44.929: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.xmp modified
2023-05-20 22:30:44.947: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.xmp modified
2023-05-20 22:30:44.947: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.RW2 modified
*
**Detected by DxPL
*
2023-05-20 22:31:17.789: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.RW2.dop deleted
2023-05-20 22:31:17.810: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.RW2.dop created
2023-05-20 22:31:17.810: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\RAW - For XnView setting 02\P1104600.RW2.dop modified
*
** Changing Rating for JPG via XnViewMP
*
2023-05-20 22:42:08.253: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP activated
2023-05-20 22:42:08.264: Saving settings to C:\Users\Bryan Thomas\AppData\Local\NodeSoft\FolderMonitor\FolderMonitor.xml
2023-05-20 22:42:18.228: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG-1684618938.bak created
2023-05-20 22:42:18.257: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG-1684618938.bak modified
2023-05-20 22:42:18.257: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG renamed to N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG.bak
2023-05-20 22:42:18.280: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG-1684618938.bak renamed to N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG
2023-05-20 22:42:18.317: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG.bak deleted
2023-05-20 22:42:18.341: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG modified
*
**Changing Color label for JPG via XnViewMP
*
2023-05-20 22:42:36.388: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG-1684618956.bak created
2023-05-20 22:42:36.419: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG-1684618956.bak modified
2023-05-20 22:42:36.419: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG renamed to N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG.bak
2023-05-20 22:42:36.447: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG-1684618956.bak renamed to N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG
2023-05-20 22:42:36.477: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG.bak deleted
2023-05-20 22:42:36.504: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG modified
*
** Modified date and time changed
*
2023-05-20 22:52:43.357: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG modified
2023-05-20 22:52:43.418: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG modified
*
**DxPL detects the change after the modified date/time is changed programatically
*
2023-05-20 22:53:18.036: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG.dop created
2023-05-20 22:53:18.070: N:\___Beta DXO PL5\Test Photos\06 - Label Testing\JPG - For xnViewMP\P1104600.JPG.dop modified
I don´t know about IPTC being dead - the corpse is still moving and it seems to have been updated later than XMP. It was updated and got a few new elements both 2021 and 2022
IPTC is supposed to have a “header” for example in the JPEG-files and there IPTC originally was stored. Today it´s also stored as a namespace in XMP. Another problem is that either Label or Rating are a part if the IPTC-set of elements. Also, EXIF is a namespace in XMP, so of that reason XMP support these elements.
On top of that we have the problem that people and software sometimes write metadata to the wrong elements/fields. You pointed out localized software that might put localized words in fields that might expect English word or concepts. I don´t know how common that is but it is common that people use some metadata elements intended for a special use to something completely different and if that element happens to be a core element it can cause real workflow problems. It can be good to remember too that if you in the future decides to migrate to another metadata tool that might use a different XMP-schema than you present tool, your metadata might not be visible at all despite it is there in the files.
For example, if your images should happen to end up in WIKI Commons or Europeana, these databases might expect copyright data to be placed in certain elements. If they for example check that you have submitted correct licensing codes from Creative Commons and an URL-reference to the licensing terms some sites might reject them.
Creative Commons — Attribution-ShareAlike 2.0 Generic — CC BY-SA 2.0
Here is a list of applications that IPTC.org says support IPTC - and not all of them are fully compatible just by the fact that some support a larger or more limited set of elements. PM supports far more elements than Photolab.
Software that supports IPTC Photo Metadata - IPTC
Another problem is that some softwares fork data differently and that´s because I use to put text in som redundant elements. I have long been irritated of how Windows handle my metadata,
This is what I wrote in PM Plus
In order to get something in Windows Properties - Information I violated a rule. Title is an element that is not the Headline and use to be used to identify an image. Many put the file name in this s element - I do not.
So, as you see if Windows don´t support Headline or Caption or Comment, it doesn´t really matter what I have written in PM.
Concerning forking, Label and Rating are to be found on several places in XnView and PM updates some but not all and when displayed in XnView they are not always containing the data it got from the XMP.
These are the different metadata tabs that together displays all metadata.
Properties
Rating as in PM
Label is named Color Label data as in PM
EXIF
(Only Camera data)
IPTC
(No Rating and Label data. Not part of the definition)
XMP
Under xmp namespace: Rating and Label data as i PM
plus
EXIF namespace
Rating Color Class OBS! data “3 (superior)”
** EXIFTolls the more complete EXIF set**
Rating
Color Class OBS! data “3 (superior)”
XnView
Rating list
Grey star with 0 - Unrated
Red star with 1 - Poor
Orange star with 2 - Fair
Green star with 3 - Average
Blue star with 4 - Good
Purple star with 5 - Excellent
So, as you can see, nor the metadata elements names or the data itself are consistent in XnViews all metadata sources. So there has to be both a lot of forking going on from PM and a lot of mapping and converting going on both to and from XnView in particular. Both in PM and XnView it is an active action to tell the application to store the metadata in both IPTC-headers and XMP-headers or XMP-sidecars for RAW.
It is really a mess and I wonder if they are continuing to support the backward compatibility forever.
From what I know XMP is both an ISO and W3C-standard now so I guess all is there to pull the plug but many of the applications are not and PM is certainly one of them since they don´t support the possibility to build your own namespaces in the XMP-schemas despite it´s part of the specification.
So XMP was initiated by Adobe but is supported by ISO and W3C today and I don´t really agree that nobody cares about the standards they have DeFacto set. XMP is one, TIFF, DNG and not the least the PDF-standard for document interchange. For me Adobe has been far more important when it comes to IT-standardisation than most other companies.
I have configured my XnView not to use sidecars for JPEG-files.
If I update rating and Label in XnView PM gets updated correct and the RAW in PL.
If I Update the same elements in PM the XMP data gets propagated to XnView but since “Properties” Rating and Color Label doesn´t get updated the change will not be visible as a change in Color Label in the interface and the rating isn´t updated either in the interface.
The only combo working as it should is PM and PL.
I don´t think I will get any further as is with the softwares I have.
Yes and no.
Biggest problem of us human is change of heart during time.
Headers and sub headers in your money flow application for house hold purposes has the same issue’s when the present keyword doesn’t fit the load any more you might think of changing this word in something else.
Only forward or also backwards? Keep the old and add the new side by side?
Scrap the old? Most private users don’t act the same as compagnies.
We just think yeah this works better! Proceed.
Compagnies are thinking this much further through about implications of the change before changing.
And my other “problem” is time.
Rebuilding a library because of new options like GEO and such means often go back 20 years of files in your archive and change methodisch al metadata according to the new Standard you brought up in your enthousiasme. After a week you think cra. This is A Lot Of Work!
After two weeks you stop because other things are more important. And yes you forgot to mark the stopping spot… Or forgot which things needed to be changed and in what exactly…
I am exacly in this spot now. 
So this winter when i am not drawn to netflix as a moth to a flame i hope i can revive my idea to update my meta system…
1 Like
I upgraded XnView after having a flash when opening it. In that lift of improvements I read a few things that caught my eye in the correction list.
I installed the last version 1.4.5 and suddenly the problem with getting color replicated correctly from PM seems fixed. Maybe some other interested in not just Labels but also Ratings can confirm.
Now every image has both a green dot and a green banner.
1 Like