Dear darktable devs:
I recognize that darktable's primary intended purpose is for the import
and manipulation of digital camera images. However, because of its
non-destructive editing workflow, darktable became my choice for doing
initial color corrections for images scanned from old photographs. I've
found that the automatic color correction in other software tools works
OK, but some images need further correction, and in such cases, I'd
prefer that the automatic correction not be "baked in" before further
editing starts.
I found that the `iop/rgblevels` module will mostly do the right thing
if I set it to independent color channels, set "preserve colors" to
none, and then autolevel each RGB channel to contrast-stretch each
individually. I can then manually adjust each channel if necessary.
I'm scanning over 40K old family photos, and this color correction
procedure per image is just too time-consuming. I started making my own
adjustments to the rgblevels module, but then decided this module may be
too fundamental in other workflows to change its current behavior to
suit my needs. I have copied the `rgblevels` module into a new module
that I'm calling 'agecorrect', and I have made modifications to the new
module that do the initial corrections automatically when enabled on a
photo. I am pleased with the direction and progress that I'm making.
I'd now like to ask for some technical and philosophical guidance. This
may be too much to digest in a single post, and since I'm brand new to
darktable and this community, I haven't acclimated to your environment
yet. Please forgive and advise if I overstep in some way.
1. Because I'm not yet sure how things interact, I have also duplicated
the data/kernels/rgblevels.cl to agelevels.cl, and created a new kernel
program number for it. So far I have not needed to make any
modifications to agelevels.cl. Is it possible/preferred to just re-use
the original rgblevels.cl kernel in the agelevels.c module? If so, are
the same kernel loading/initialization steps required in agelevels.c? or
would this conflict in some way with the rgblevels.c initialization of
its CL kernel? If re-using rgblevels.cl is preferred, is there some
shortcut initialization to be done in the agecorrect.c module instead?
(OpenCL is brand new to me, so I haven't a clue.)
2. I understand that adding yet another module to an already dizzying
array of modules is probably not ideal, and I believe it may be possible
eventually to fold my changes in agecorrect back into rgblevels with a
little extra tooling. I wouldn't want to do this until I have finished
experimenting with agecorrect, since updating the
DT_MODULE_INTROSPECTION level is something that shouldn't be undertaken
lightly. The philosophical question would be: should 'agecorrect' remain
a separate module instead, given its intended use? (My thinking is that
if my changes are folded back into rgblevels, a single GUI toggle would
adjust all the settings appropriately for old photo correction, so that
if the rgblevel settings in module history were applied as a style to a
photo, it should automatically correct the photo when enabled.)
3. I have some additional thoughts on the old photo color correction
problem that would use the CMY(K?) colorspace. Photos are prints using
CMY(K) processes, and these dyes fade at different rates. The RGB
colorspace shares a simple inverse linear relation to the CMY colorspace
(ignoring black for now), so mathematically, there isn't much difference
in making any adjustments to RGB or CMY colors. However, the
relationships between color conversions can become more complicated if
one wants to make non-linear edits in the CMY colorspace, e.g.,
introducing a logarithmic/power correction to CYAN or YELLOW due to
different fade rates of these two dyes. I haven't found any reference to
CMY(K) colors in the darktable source yet, which is understandable,
since darktable doesn't seem to be designed for working with print
colors. Also, to photographers making adjustments to old prints, they
might be more used to making adjustments in CMY-space, e.g., "this photo
is too magenta: it needs more cyan". Philosophically, is this too much
of a stretch for darktable?
4. One of the adjustments I've made to processing in agecorrect is that
I use information in the histogram rather than the image itself for
determining the auto-adjustment levels. While I abhor the thought of
throwing away data, for older scanned photos, it is often more reliable
to throw away some percentage of the pixels at the low and high ends,
forcing them to 0.0 and 1.0 below/above certain thresholds. By using the
histogram data, I can determine which level setting exceeds the
threshold number of pixels. It has been working fine with histograms in
8-bit space, but are histograms always 8-bit quantities? Is there a way
to test whether a histogram is 8-bit or something else? Am I going to
get into trouble in some other unforeseen way?
5. And finally, in the grand scheme of things, is something like the
'agecorrect' module of benefit to other users? Or should it remain a
personal adaptation of darktable for my own use? (in which case, the
previous questions probably won't matter.)
With respect and appreciation for all that you've accomplished with
darktable, many thanks!
Bret
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
