Thanks again, @pehar and @rvietor, for your comments and suggestions. As mentioned earlier, I am totally new to darktable (DT): in fact, I’m in the process of evaluating whether this software tool will meet my needs, so I may not be the best person (yet) to start writing DT’s definitive documentation. However, I did have a look at the GitHub call for help (A plea for help writing the docs)…
-
Regarding the 13 DT flags, I note that
- flag 0 duplicates the information already provided by the stars at the bottom of each thumbnail in the “lighttable” view of DT.
- flag 1 appears to be unused.
- flag 2 (“thumbnail is deprecated”) could be implemented as a separate item in the “image information” panel, or perhaps as a warning, if there is a centralized mechanism for reporting potential and actual issues.
- flags 3 and 5 could be combined as a single item in the “image information” panel to indicate whether the picture is LDR or HDR (assuming these are exclusive of each other).
- flag 4 duplicates the information provided by the extension of the file containing the image, itself appearing in the “filename” and the “full path” items in the “image information” panel (e.g., r = raw = “NEF” extension in the case of Nikon hardware).
- flag 6 (image flagged for removal) could also be implemented as a filter option and/or a warning before deletion.
- flag 7 appears to duplicate the information in the “history stack”, if I understand correctly the comment of @rvietor.
- flag 8 is not entirely clear to me: does it indicate that the information provided concerns a “local copy” of an image whose master copy is located elsewhere than the address shown in “full path”? This could also be implemented as a warning, or a more explicit annotation in one of the “darkroom” panels.
- flags 9 (“image contains text”), 10 (“image has an associated WAV record”) and 11 (“image is monochrome”) could appear as separate items in the “image information” panel, instead of as a flags (would that also make it easier to search for images with those characteristics?).
- flag 12 probably duplicates the information contained in the extension of the file: it would be useful to know why this flag was setup in the first place.
So, I second the comment of @rvietor: from a user point of view, most of these flags do not appear to provide essential information, and those who do could/should be implemented individually rather than as cryptic flags, and be clearly documented (as recommended by @pehar). However, I do not know whether those flags are used elsewhere in the code or fulfill another purpose.
-
On the more general question of the number of items shown in the “image information” panel, I don’t quite understand why only a small selection of the metadata items generated by Phil Harvey’s excellent “exiftool” software are made available to DT users. I doubt that the developers can anticipate any and all requirements of any and all existing and prospective users, nor is it their mandate to limit such information to what they like. Since it is already possible to select or deselect displayed items from the list of available items, the obvious solution is to offer the entire set of metadata (EXIF, IPTC and XMP) as an option and to set the initial default selection to something close to what most users would expect. This is similar in approach to providing a wide range of processing modules and letting the user decide which ones to use in a particular context.
-
Lastly, and as an aside, why is there not a “Documentation” category as a primary locus for discussion of that important topic on the PIXLS.US web site (next to “Processing”, “Software”, “Hardware”, etc.)? Documentation is often attributed a low priority in the software development process, even though it really conditions the usability of the software. And better documentation in general would reduce the burden on the community to answer questions from users.
Thanks again for your support.