I have ended up using darktable even for the initial culling step. Partially because I have been ending up there to do final editing anyway. Partially because darktable expects XMP files to be named differently than any other program I have tried. This means that if I use another program to go through an rate the images, darktable does not pick up those ratings because it wants the xmp file to be named basename.ext.xmp, instead of basename.xmp. It would be really nice if darktable was compatible, there, with other programs.
I really want to like Rawtherapee, but it is just less intuitive to use.
FastRawViewer is on sale right now: http://www.fastrawviewer.com/ and it is nice enough to justify the reduced price. Unfortunately, they donāt have a Linux version. Also, since it uses the (seems be standard) naming of basename.xmp, darktable does not pick up the ratings made with it.
Thanks again, to everyone for their suggestions and tips.
Iād personally like other programs to use basename.ext.xmp, since often times I will produce a tif file that Iād like to put some notes in the xmp aboutprinting that partulicilar file; in this case, basename.xmp fails miserably, as I do not want my tif and raw file to share a sidecar file.
Geeqie has indicated that basename.xmp is how adobe does it, but I donāt find that to be a valid justification.
The basename.xmp is a really bad idea. I often shot jpeg and raw and then this simply doesnāt work with basename.xmp, for this use-case I need basename.ext.xmp.
Darktable does pickup most of the metadata on the basename.xmp on the initial import, but not afterwards. I have to handle this between XnView and darktable and solved it by creating my own bash scripts based on exiftool to sync metadata to and from darktable xmp files. I have this streamlined in my workflow, so it isnāt a big hassle, but would still love that XnView to handle xmp file names a bit better.
Nevertheless Darktable only writes the color labels to its own schema tags and, please correct me if Iām wrong, thereās no standard way to set the Color labels into xmp tags.
You are correct, there is no standard way to do this. Several sites suggest that applications just write the color into the xmp label tag, then display the color label according to the tag, but this introduces some interesting parsing and presentation problems. Oh, and localization problems too, is it āblueā and not āblauā for the tag?
I think I may opt to introduce a workflow taxonomy for tags in my workflow, as Iām finding there are not enough color labels for me anyway.
As @paperdigits said, there is indeed no standard for color labels, which is strange, given how widely used they are. But there is also no standard how they are used in the programs. Some like darktable can toggle any of them on/off at random while other programs can only have at most one label assigned at a time. So while it might make sense to support using xmp:Label for them it would require a lot of thinking and code under the hood.
Being a programmer myself I understand your worries, coding something into a piece of software that really isnāt standard (so it might not even be so useful as expected) is a huge risk for something thatās community driven. In the end that ālot of thinkingā shouldnāt be needed if there was a well defined convention.
Bringing this a bit more on topic, I rely heavily the color labels, because I use more than one program in my workflow, and have switched my preferred RAW developer a couple of times in the last years, I have felt this lack of portability of color labels more than once. Right now Iām at the point where Iām considering the same that @paperdigits wrote and removing color labels completely from my workflow.
Color labels have another problem in addition to not having a standard representation. You have to carry a cross-reference in your head as to what color has what meaning. Instead of your image having a tag that says āI selected this image for Raw processingā, it has, say, a blue tag, and you need to mentally translate blue to ādo some raw work on this imageā, and remember thatās what it meant if you are away for a while.
Yes, that could be a problem. Therefore, with red, yellow and green, I represent the status of editing, which is easy to remember and did not change over years. But what the other colours meant two years ago, I cannot remember.
For a long time I have a feature in mind to solve this problem, but never posted somewhere: What about adding meaning to the colours, that show up as a tooltip when you hover the colours. Ideally, the meaning would be stored in an invisible file (.colour_meaning or similar) in the root directory of your photo collection and could be overwritten by such files in deeper directories (e.g. the global meaning of purple is ānot a good photo but necessary to tell the storyā, but in a directory with shots to create a panorama, it could mark the shots selected for further processing). It could be further overwritten in pp3/xmp/whatever sidecar, if a special meaning is needed for a single file. In parallel, the last inherited meaning could be carried in the sidecar as well, to ease moving such pictures around. Just an idea ā¦
Exact description of what is exactly an icon!!!
The difference between icon and hieroglyph: not everybody was allowed to create his glyph. An icon makes always sense for its own designer.
