I’m quite sure that the xmp:rating=-1 is within the standard because Hert with his Photo Supreme is wicked ridged to follow every standard there is.
And I also would love to see PL supporting it.
I’m quite sure that the xmp:rating=-1 is within the standard because Hert with his Photo Supreme is wicked ridged to follow every standard there is.
And I also would love to see PL supporting it.
Tha same is with Mario with his IMatch.
By the way - feature request is made
OK. It took me all of 8 hours to implement marking images for rejection or reading previously marked images in my app for Mac.
The red dot indicates rejected, the pale grey dot indicates 0, but if no rating has been applied, this dot appears darker, just like the unassigned stars. Then follows the star ratings as normal.
Why do you give a image some marker if they do not have any stars?
Some apps use a “zero” dot, some don’t. Mine does. Simple personal preference.
And you need an “inactive” dot to click on to hide any active stars. Although PL insists you click on the same, active, star to “cancel” it. I’m not sure I like that.
Would someone be so good as to send me a file that has been marked as rejected (-1) by software other than PL?
Why don’t you do it yourself?
exiftool "-Rating=-1" -overwrite_original file.xmp
Because I have ExifTool command line tool, and it is that that my app uses. But I wanted to see what happened with what other “proper” software writes, perhaps using other metadata engines.
I am beginning to understand nothing in this forum.
It doesn’t matter which program writes the entry “rating=-1”. Either it is there or it is not. If it is not there, then the program does not adhere to standard. If it is there, it doesn’t matter what software wrote it.
Of all the photo software I have, only DPL doesn’t use exiftool.
This may be a very stupid question, but why keep the photo if it’s rejected?
but why keep the photo if it’s rejected?
We can reject an image for s specific use case and still keep it for other cases.
@Required and I are working on a possible bug with the handling of the xmp:rating
tag in PL6. We’ll come back to you shortly with a definitive test case.
Addenda.
FastRawViewer also doesn’t like out of range ratings. See what you get if you set it to 65535…
FastRawViewer also doesn’t like out of range ratings
What kind of range do you mean? FRV works great with -1 and 0…5
Yes, but we stumbled across something that translated -1 (signed integer) to 65535 (unsigned integer) in the file. You never can guarantee that files are sent with valid values, so the first rule of testing is never assume - anything.
Some folks do batch updating using ExifTool on the command line, which allows you to assign whatever your heart desires.
You never can guarantee that files are sent with valid values
Interesting theory, but I’m using exiftool, Imatch and Photo Supreme (only the tree programs is allow to write my metadata) many, many years and have had never a problem with something like this.
Only for rating I’m using sometimes FRV without any issues.
Which software caused it?