Messed up colors by the number - darktable's new unbreak and filmic modules

[afre (Alan)]

Like this?

Top image: RGB→XYZ
Bottom image: RGB→XYZ
Result: RGB*Y/Y

[ggbutcher (Glenn Butcher)]

@Elle

Also that "Principles of Steam Locomotive Valve Systems " article looks pretty interesting!

Reading it now, I’ll do all that color stuff later…

The vectoring of energy in useful directions is an interesting historical study. It is truly amazing that the complexity of Walschaerts valve gear was scaled to the likes of locomotives fielded in the mid '50s. Watching Union Pacific’s 844 round a curve at 70mph with valve gear flying this way and that is rather awe-inspiring. Well, to me anyway…

[ggbutcher (Glenn Butcher)]

Walschaerts on a locomotive at the Tennessee Valley Railroad Museum:

Now, here’s messed up color, no?

[ggbutcher (Glenn Butcher)]

@Elle

Of course in the LL forum they were talking about PhotoShop’s HSL blend mode (did I get the initials right? Is it HSL?) which isn’t the same blend mode as what is normally meant by HSL. I can’t find the calculations for PhotoShop HSL(?) online, though I’ve looked - anyone know/have a link to the actual calculations?

Almost forgot to post this: Some time ago, I ran across this blog post about Photoshop’s HS(L?), with code to capture what he thought it looked like:
http://alienryderflex.com/hsp.html
He has a very simple saturation algorithm based on it in a separate post, which I use in rawproc. Yes, it’s probably dorking up my colors, but in small amounts it does the job. Recently though, I find less need to use it if I start with my “whitebalance-aware” camera profile…

[Elle (Elle Stone)]

FWIW, the values “.299, .587, and .114” quoted in the article are the Y components of the old NTSC color space. For some unknown reason PhotoShop chose to keep those values as the “default” values for a conversion to black and white. But unless you’ve actually converted your image to NTSC, results will be wrong by the amount your working RGB color space differs in the Y values from the NTSC color space Y values. See the table at the top of this page, and also sidenote #1:

http://brucelindbloom.com/index.html?WorkingSpaceInfo.html

And then look down at Lindbloom’s table of Y values for ICC profile color spaces, and you’ll see that even if you converted your image to the NTSC ICC profile, the values used by PhotoShop aren’t the correct D50-adapted values but instead the unadapted D65 values.

Possibly PS has change d their code in the meantime, but at least as late as CS6 PS was still providing wrong results for conversions to black and white. This came up in a discussion with a person comparing a Luminance conversion to black and white using GIMP-2.9 with results from PhotoShop - GIMP’s results are correct. It’s possible to get correct results from PS, but it requires obtaining the Y values for your RGB working color space and also converting to a linear gamma version of your RGB working space, and then feeding the Y values into the channel mixer - going from memory here! it’s been years since I used PhotoShop for editing.

Edit: Oh, the thing I was curious about for PS was that I thought they used actual “Y” values for the “L” of HSL, but somehow managed to avoid generating out of gamut RGB channel values when doing HSL color blend modes. But maybe there aren’t any such oog channel values generated by their blend modes that need tweaking from additional code. In LCh blend modes and also Luminance blend modes, it’s possible (depending on the two layers in question) to generate some spectacularly oog colors.

[Elle (Elle Stone)]

I did some more digging into the hows and whats of the unbreak-profile code, and it seems it operates in the camera input profile color space, which is not a good space for editing, except for very limited purposes such as resetting the white balance or retrieving channel data “as captured by the camera” for whatever purpose (useful for black and white, imho).

So I did an experiment, exporting a scene-referred image from darktable in the sRGB color space and reopening it, and applying unbreak-profile plus tone curve, and the hue values are very close to the original hue values - the colors aren’t messed up at all.

Maybe camera space could be replaced by a user-chosen space? Or by Rec.2020, or some such?

[anon41087856]

@Elle

I’m assuming that the colors in a scene-referred interpolated raw file (no “make it pretty” algorithms) are as close to the actual scene colors as most of us can get given that when we take pictures we don’t also measure scene colors using specialized equipment.

darktable doesn’t do scene-referred, so unless you applied an identity profile at the output and at the input, your measurements are void.

@Elle

The particular Base Curve that I used didn’t mess the colors up very much at all. Other Base Curves no doubt can make really messed up colors, or slightly messed up, or etc, depending on the specific Base Curve.

All the camera base curves have a toe at the beginning, so I don’t doubt that with a carefully choosen curve, you get good result, but that’s anecdotal here.

@Elle

Exposure + Unbreak, without adding an “S” curve via the tone curve module and also adding in Chroma using RGB, of course produces really, really, really messed-up colors. The only reason I included this output in my metrics is to show that the colors - the hue and Saturation values - are already “messed up” before using the Lab-based Tone Curve.

Unbreak in log is the first step of a process, taking its output alone doesn’t make sense. Especially if you apply an output profile that has a power 2.2 transfer function in it.

@Elle

Exposure + Unbreak + the Lab Tone Curve and using RGB to add chroma still produces fairly messed up colors. This doesn’t mean the resulting image isn’t useful as a starting point for further editing - that’s surely image-dependent and also a matter of aesthetics. However, personally I wouldn’t use this darktable module/process precisely because of the resulting “messed up colors”, and specifically the large changes in hue. I prefer to mess up my image colors deliberately in post rather than accidentally as a result of an automatic tone-mapping algorithm.

I have repetedly said you should use the tone curve in RGB mode, not in Lab.

@Elle

Exposure + Filmic has minimal LCh hue changes, and for the two “ground” sample points the “Saturation” changes are also minimal. But for the “cloud and sky” sample points, the “Saturation” changes are pretty high.

That’s because filmic does in one step what you should do with unbreak profile and tonecurves (assuming you use them properly), with sweeteners on top.

@Elle

I’m not fond of the flattening of contrast in the clouds but the goal of the module is to produce flattened output for further processing, and other darktable modules can be used to add back in some controlled local contrast.

You can use the highlights/shadows balance then. Also, when you are trying to fit 12-14 EV into a 8 bits file, these are the kind of trade-off you have to make. The goal of the filmic module is to compress the extremes and preserves the mid-tones.

@Elle

For this particular raw file the “filmic” code in the module that keeps the highlights from oversaturating - measured using LCh “Saturation” - produces undersaturation in the darker portions of the clouds. Imho the sky also looks undersaturated. But of course one can add additional saturation to the output from the filmic module using other darktable modules. And maybe there’s a better set of parameters than the ones I used for the filmic modules. Here’s the XMP file (has the unflattened history):

Open the gamut alert/softproofing and you will understand why this desaturation is actually what you want. Maybe shoot some Kodak Portra too, to see what film does with highlights.

@Elle

Now here is a plea for people to please please please stop throwing accusations like “messed up colors” “silly” and “nonsense” around when they are talking about code written by other people.

I have lost 2 months worth of income, learning C, SSE and OpenCL from scratch, working full-time for free to fix a tool that suffered from bad decisions, lead to bad colors control and rendition, and (still) lacks proper support of HDR cameras because of a fixed workflow based on how the developpers edited 8 EV pictures 10 years ago.

It’s not acceptable that almost every luminance edit messes-up that much the colors. It’s not acceptable that we need a zillion of modules that mostly compensate each other’s flaws to achieve a result that other editors achieve flawlessly. It’s not acceptable that darktable is called a photo workflow software when it’s really just a collection of plugins, Gimic style, developped as a pet project instead of a working tool, with no design intent.

It’s nonsense that any module comes after the output color profile : change the display, and now your parameters are voided. Also, why on Earth would I want to edit in output space RGB ? If I save the file in sRGB for the web or in Adobe RGB for print, the same settings produces different effects. Zhere is the reliability in that ?

Also, it’s nonsense that the default working space is Lab. Lab is a reference space to describe colors, not a working space to push pixels. Pushing luminance in RGB desaturates the highlights and saturates the shadows. That’s not color-accuracy optimal, but it still looks good. Do the same in Lab: you get blue-grey washed tones.

So I don’t care whoever feels offended by that. I’m a portrait photographers who cares about having healthy skin tones, not a hobbyist looking for deep blue skies. And I haven’t taken a single photograph in 3 months, too busy fixing a broken software and losing too much time to convince the devs that my changes are actually usefull, if not good.

[Elle (Elle Stone)]

@anon41087856

darktable doesn’t do scene-referred, so unless you applied an identity profile at the output and at the input, your measurements are void.

Well, what do you mean by “scene-referred”? There are a couple of different meanings floating around. There’s "intensities equal to scene intensities with colors as colorimetrically accurate as possble given all the real-world contraints we face when we put a lens on a camera and aim it at a scene. There’s also “proportional to scene intensities”. I usually mean “proportional to scene intensities” because this is the meaning I originally learned. But I think perhaps this meaning isn’t the technical meaning, the technical meaning might actually be “equal” rather than “proportional”. Do you know? Do you have a reference?

Yes, in darktable often I do simply assign the same input and and output profile - doesn’t have to be Identity - to get “raw color” and then assign the camera input profile using other software. Of course when I do this the only operations that I allow darktable to do are the actual interpolation, auto chromatic aberration repair, hot pixel repair, setting the white balance. But these are the only operations I ever allow darktable to do, except when experimenting to see what’s new in darktable. But I also know many photographers do just about all their processing in darktable and they thoroughly like the software. So telling people it’s all junk like you seem to have been doing is just not a good approach. It seems to me.

@anon41087856

I have repetedly said you should use the tone curve in RGB mode, not in Lab.

Hmm, OK, I looked for that RGB mode and used it for saturation. Just now I checked again to see if I could figure out what you are talking about wrt to the actual tone curve. Does the tone curve default to RGB? If so, that’s what I’ve always been using. At any rate thanks! for helping me figure that out, I have always had trouble figuring out the darktable user interface, and I didn’t realize there was a drop-down menu for the actual tone curve, I thought it was only for Lab Lightness.

@anon41087856

Open the gamut alert/softproofing and you will understand why this desaturation is actually what you want. Maybe shoot some Kodak Portra too, to see what film does with highlights.

Maybe for many images, not for my “departing storm” image - the actual highlights - the brightest portions of the clouds - are already neutral. And fwiw I really do not like supersaturated colors or overly tone-mapped output, like yourself I have an interest in printable and film-like colors. I soft proof all my images to a printer profile and learned long ago to control saturation in the highlights and shadows.

@anon41087856

I have lost 2 months worth of income, learning C, SSE and OpenCL from scratch, working full-time for free to fix a tool that suffered from bad decisions, lead to bad colors control and rendition, and (still) lacks proper support of HDR cameras because of a fixed workflow based on how the developpers edited 8 EV pictures 10 years ago.

Hmm, I can see why you might be frustrated.

Now ask me how many hours, days, and many months I spent working to nudge GIMP code away from a totally bad direction, and how much time and energy I’ve spent since then testing the code, making bug reports, writing patches (a very slow process, takes huge amounts of time, I’m just not good at coding), and keeping up with git to test code changes and try to help improve GIMP. Then consider how much time and energy I’ve spent over the years testing and submitting bug reports on ICC profile color management as used in all our free/libre image editing software, only to have repeated insults dumped on my head and on GIMP and ICC profile color management by our friend “anonymous”?

Yes, it’s OK to be frustrated by dealing with accumulated cruft and code that just “grew”. I don’t think any developer out there thinks their code is “good” - code just grows. But that doesn’t give you license to insult. It merely gives you a reason to document the problems, educate people about the problems, and help them learn better ways, and if you have the desire and ability to improve the code, that’s absolutely wonderful.

As it happens, I agree with you that it seems odd that darktable pushes everything through LAB. That doesn’t mean everything about LAB is awful. LAB properly used is a useful tool for editing.

@anon41087856

It’s nonsense that any module comes after the output color profile : change the display, and now your parameters are voided.

I don’t understand. darktable is an ICC profile color managed editing application, like it or not. The display profile does influence what you see on the screen, of course it does, but this is true for any method of color management. But the RGB values in the image file don’t depend on the monitor profile.

@anon41087856

Also, why on Earth would I want to edit in output space RGB ? If I save the file in sRGB for the web or in Adobe RGB for print, the same settings produces different effects.

Well, personally I prefer editing in linear Rec.2020, for reasons you can find scattered here and there on my website. But for many types of edits the actual color space doesn’t matter because many edits are color-space independent.

But editing in a camera input profile color space is just asking for bad results, not nearly as bad as editing in for example the Identity RGB color space, but not good, and again of course depending on the specific edits. Raising to a power is one such “chromaticities matter” algorithm, as is white balancing. I was going to suggest that maybe it would be good to switch your filmic module and also the unbreak-profile code to ACEScc or Rec.2020 by default - both are better than ProPhotoRGB and much better than camera input profiles for general editing.

@anon41087856

So I don’t care whoever feels offended by that. I’m a portrait photographers who cares about having healthy skin tones, not a hobbyist looking for deep blue skies. And I haven’t taken a single photograph in 3 months, too busy fixing a broken software and losing too much time to convince the devs that my changes are actually usefull, if not good.

Again, your code is not in question. The insults are in question, along with blanket claims.

For example, the provided base curve presets do all have toes as you say. Personally I’d never use any of those base curve presets for any reason at all - the whole reason I switched to a DSLR was to avoid the “camera styles” baked into camera jpegs producing crushed shadows. But the base curve module doesn’t require using the little presets. It’s a useful module apart from the presets.

Explaining to people why the base curve presets can lead to problems down the pipeline is one thing. Calling the base curve module “silly” is quite another.

FWIW, the time I’ve spent recently in darktable was precisely to see what your new code does. I noticed your post on a possible new deconvolution algorithm and thought, oh, that person has some good stuff going. I made a suggestion that your saturation module might benefit fom a chroma mask of some sort, but you seemed to have passed right over that as not interesting, which is OK! But seriously a chroma mask is a good thing.

I was surprised at the oddness of the unbreak-profile code output, and spent time looking through your code trying to figure out what the problem was. I asked you about it over in your “linear” thread, twice actually, but you didn’t answer.

FWIW, I like your code and I think it might be really nice to add similar modules to GIMP. I haven’t yet found (and might not ever find) the energy to try to port the code over, and it’s also not code that personally I would likely ever use. But I think many GIMP users might like it quite a lot. FWIW, my own style of editing is rather different - I work on linear RGB as long as possible and the idea of switching to log-encoded RGB is not all that appealing. But I can see why you’ve taken that route.

[ggbutcher (Glenn Butcher)]

@anon41087856

It’s not acceptable that darktable is called a photo workflow software when it’s really just a collection of plugins, Gimic style, developped as a pet project instead of a working tool, with no design intent.

It’s perfectly acceptable. That’s how FOSS goes, individuals’ ‘good’ ideas captured in code, usually external to the trappings of an organization set up to compensate individuals for such. You chose darktable to do your work. You could choose to do your work on any of a variety of projects, and probably run into different frustrations. You could even choose to start from scratch.

I’ve been following your discourse with great interest, and I don’t think your toilings will go for naught. The folk who post here are reasoned, considerate individuals, folks who have worked hard to shift their thinking to a scene reference. Keep engaging constructively, and I know your perspective will gain traction. The world of still photography has a significant legacy in an architecture based on old assumptions, it won’t change on a dime. And, if you want to affect real change in the ways you describe, I believe here, with the tools represented, presents your best chance…

Standard caveat: For What It’s Worth…

[martin.scharnke]

I, too, have been following this with interest. @anon41087856 , I admire the time and effort and sacrifice of you have made. Thank you for your generosity. I have had some success in using your filmic module.

I can only chime in with @ggbutcher: keep engaging constructively.

[chris]

@anon41087856

I have lost 2 months worth of income, learning C, SSE and OpenCL from scratch

@anon41087856

I’m a portrait photographers

IMO this part would make a really great story for the next pixls.us interview . Maybe after the release, when a broader range of people can test the outcome of your hard work.

(I am really impressed that one can learn all this programming stuff in comparatively short time, and have many questions about this topic, but I think I will save these for after the release. But I cannot move on without opposing on how I observe what you are saying about darktable and its original devs. Even if there are some wrong decisions, darktable is already a very capable tool and I was able to get good results for years. Of course there are some flaws, and each and every improvement is highly appreciated, but I appreciate as well the work that was already spent on the tool because I am using it on an almost daily basis and therefore benefit a lot from that work. And because I am impressed by the project every day. Even if some decisions were wrong, I personally think one should not call the decisions or those that did these decisions silly, because this sounds to me aggressive and inappropriate. YMMV.)