Why are there hashlines through the rating for the label on thumbnails?

[Jingo]

Hi all... I did a search here and in the help file but couldn't locate an answer (though I know I have read about this before).... In the screenshot below, you can see all my thumbnails have the diagonal lines through the rating.  I believe this was displaying because Capture One added a "None" label on export to all the files and IMatch did not have "None" defined.  So, I added "None" to the Metadata tab in preferences and defined it with a "No Color" setting... but the thumbnail display didn't change as it does when I choose another label with a color.


So... a) why do the lines appear   and    b) how can I get them to not appear without having to "reset" the label on all images upon import?

Thanks!

[Mario]

These files use an XML label name that is not associated with a color.
You an associate colors with XMP label names under Edit  > Preferences > Metadata.

[Jingo]

Hi Mario - so, I did map the XMP label of "None" to the Color of "No Color"... and expected that to not show the hash lines.. but simply show No Color... is there a way to set this up so "No Color" doesn't show the hash lines but simply.. No color as implied?

[Mario]

The hash means "no color". There is no other way to represent a non-existing color.
Why do you have XMP labels "None" in your files?
If a file has no label (which is different from having the label "None", mind) there is no hashed color displayed.
I suggest you strip the uncommon "None" labels from your files and then, happy days.

[Jingo]

Thx Mario.. it appears Capture One is adding this label when the files are exported... so I will need to not export color tags and ratings to prevent...  much appreciated!

[Mario]

If C1 means that a file has no label, it should add no label. If they instead add the text "None" as the label (Doh!) you can either remove the label in IMatch, or assign a color or keep the hash so you know which files have the label text "None". So many options in IMatch - awesome 

[Jingo]

Yup.. C1 defaults to "None"... don't see a way to change this in C1 except not to export both ratings and labels.... kinda silly they don't offer more advanced export options (like export ratings but not labels)... oh well.  The only reason I was rating in C1 anyway was to signify keepers when viewing a stack of similar images... I can use another method like a star-rating keyword, export that and then filter and swap to a rating in Imatch.

I don't mind the hashes so much in Imatch but they "obscure" the star rating a bit so that gets in the way.  I did map the "None" to a color.. but then changed it to "no color" which I figured would override the hashes with a "clear" color.. but no dice.  Guess it doesn't make sense to have a "clear" color... no point in having a label then but it would solve my problem.   

[Mario]

You can easily select all files with the "None" label and remove it in IMatch. Then write-back.
This way not only IMatch knows that these files are unlabeled, but also all other XMP-compliant applications.

[Jingo]

Yes.. I did that for this batch of photos... but it took about 50 minutes to write back the 1700 images so its not something I'd like to add into my workflow normally.. Thanks again Mario!

[Mario]

That's very slow. Are your files on a remote storage? Or very large?

[Jingo]

Files are on a Cat-5 wired NAS.. but they are just JPG's.. about 4MB a piece... pretty sure its the NAS though... looks like ~20 secs per image... though if I'm reading the log right the files are written back in only 1-2 secs... its seems that the PTETWrapper:ProcessRun is taking many second to complete and then finding a GPS error...

Code Select Expand

11.29 12:24:35+    0 [CA24] 10  M>               < 14 [1609ms] PTETWrapper::Write
11.29 12:24:35+    0 [CA24] 50  I>                  PTMetabase::WriteBack successful for file [53504] '\\JINGOSERVER\photo\2016\2016-11\E-M5MarkII_16-B190165.jpg' in 1 s
11.29 12:24:35+    0 [CA24] 50  M>               > 14 PTMetabase::Propagate  'PTMetabase.cpp(8152)'
11.29 12:24:35+    0 [CA24] 50  M>               < 14 PTMetabase::Propagate
11.29 12:24:35+    0 [CA24] 10  M>               > 14 PTETWrapper::Write  'PTETWrapper.cpp(2661)'
11.29 12:24:35+    0 [CA24] 10  M>                > 15 PTETWrapper::ProcessRun  'PTETWrapper.cpp(3364)'
11.29 12:24:37+ 2016 [CA24] 10  M>                < 15 [2016ms] PTETWrapper::ProcessRun
11.29 12:24:37+    0 [CA24] 01  W>               ETWARN:Warning: Bad GPS directory - \\JINGOSERVER\photo\2016\2016-11\E-M5MarkII_16-B190166.jpg
Warning: Bad GPS directory - \\JINGOSERVER\photo\2016\2016-11\E-M5MarkII_16-B190166.jpg
Warning: Duplicate GPSInfo tag in IFD0 - //JINGOSERVER/photo/2016/2016-11/E-M5MarkII_16-B190166.jpg
  'PTETWrapper.cpp(3217)'
11.29 12:24:37+    0 [CA24] 10  M>               < 14 [2016ms] PTETWrapper::Write
11.29 12:24:37+    0 [CA24] 50  I>                  PTMetabase::WriteBack successful for file [53599] '\\JINGOSERVER\photo\2016\2016-11\E-M5MarkII_16-B190166.jpg' in 2 s
11.29 12:24:37+    0 [CA24] 50  M>               > 14 PTMetabase::Propagate  'PTMetabase.cpp(8152)'
11.29 12:24:37+    0 [CA24] 50  M>               < 14 PTMetabase::Propagate
11.29 12:24:37+    0 [CA24] 10  M>               > 14 PTETWrapper::Write  'PTETWrapper.cpp(2661)'
11.29 12:24:37+    0 [CA24] 10  M>                > 15 PTETWrapper::ProcessRun  'PTETWrapper.cpp(3364)'
11.29 12:24:39+ 2515 [CA24] 10  M>                < 15 [2515ms] PTETWrapper::ProcessRun

That's not encouraging.. I haven't added any GPS info yet to the images..


EDIT: Looking at the files in ExifToolGui - I don't see a duplicate GPSInfo tag in IFD0..




Of course - this is after the writeback so perhaps the tag was cleared and corrected during writeback?  I just tried to add a new keyword to that image and a review of the log does not show that error... the fun of XMP!

[Mario]

ExifTool may have fixed the broken GPS data during the write-back.
Of course such issues may slow down writing further. And updating files over networks is of course 10 to 100 times slower than updating the same file on a local disk or SSD.