Alright, time for a follow-up and the 500th post in this mega thread!
I noticed that Signature Edits recently added a lot of new portraits to their Free Raws collection. There is also a fairly good mixture of ethnicity among these images which is something I have been unable to test against with my own pictures so far! (Note that the gender equality of the collection is rather poor though and that will be visible in my final selection of images here…)
Anyway, without further delay here are a bunch of good portraits with no other editing than white balance (color calibration) and display transform (same order as in the above post).
Hue twists problems range from ok to terrible. It’s interesting how much easier it is to spot in faces compared to other objects. The proposed hue preservation method seems to manage these situations well!
I use skew only in special cases but it does give that little bit of extra control needed for those images where it’s needed!
Using rgb ratio for display transform for preserving stimulus colors still looks kinda weird to my eyes. Overall desaturated look and with an odd behavior in the highlights.
Filmic has a tendency to “crush” shadows more than I like, effectively removing dark details in for example black hair! Adjusting the black level only partially remedies this and is also coupled with other effects in the module.
I use the same exposure setting for all examples here so the sigmoid and filmic modules are very easily interchangeable as both pivots around middle grey!
And remember:
The sigmoid module with its log-logistic curve is defined for infinite pixel intensities and is thus robustly defined for scene-referred work.
rgb ratio as a display transform method (preserve color in filmic rgb) preserves the spectrum of the emitted light from the pixel on the display. It does not preserve how we see/perceive the pixel’s color in the context of its neighborhood. So yes, rgb ratio does not change the physical chroma/saturation of the pixel but it does however change the perceptual chroma/saturation.
It’s really interesting to see these lineups. The last two consistently look pretty terrible. Faces are indeed a very good test subject. You immediately feel when somethings off.
It’s interesting how huge the differences are in how tones are distributed. Mindboggling that such difference could be considered ok starting points.
Haha yes indeed, too bad that those imaginary faces most likely are generated in a display referred space and thus utterly useless for raw editing testing
This is the preview from the website…is that considered an edit or the jpg preview…if so the last two might actually be closer and could be enhanced and if you us no preservation in filmic its not far off this as well…I guess it just depends on what you compare to what…
I find too that there’s an inherent crushing problem. It seems the roll-off to black seems somewhat crude and prone to suddenly hitting a wall. I try to keep the filmic output very low contrast to remedy this.
I really don’t understand what these side-by-side comparisons provide. Are they an objective comparison between the capabilities of modules or a comparison of a person’s ability to edit images with different modules? If I showed you a nice photograph and a badly-rendered rough sketch of the same subject would you conclude that drawing is inherently inferior to photography or just that I was bad at drawing? Filmic is a pretty flexible module, especially when combined with others in the pipeline, so just providing a single image and labelling it “filmic” isn’t necessarily a true reflection of its capabilities.
I suspect the crushed blacks might be the result of people expecting filmic to be a one-stop-shop for image editing. In my experience, increasing the exposure and/or some minor edits with the tone equalizer usually resolves these “issues”.
I agree that the first picture in particular generally looks most vibrant and engaging. No idea however whether that is “correct” or not, or whether it might be achievable with the others via a tug in the saturation slider.
I understood from @jandren 's last series of posts (and the thread in its 500post glory in general) that the way colors are being mapped to display values has general differences between the filmic method and others. He showed that by synthetic pictures and plots quite recently for the 2D and 3D colorspace cases.
Can you tweak filmic to look more ‘finished’? yes absolutely! But I think he is talking about the way colors are being handled regardless of the actual tweaks within filmic, for as much as one can disregard this.
The ‘filmic’ labeled pics are not the definitive final filmic edit, they are indicative of how filmic handles ‘colors out of the box’ AND how saturated-colors, bright-colors and saturated-bright-colors will end up on your screen, even if you tweak it a bit different.
personal opinion regarding the 4up-skintones-comparison:
‘100%-hue preserve’ and ‘rgb ratio’ seem to be two extremes of ‘visually pleasing’ and ‘looks technically correct but bland without having seen the original’.
‘0%-hue preserve’ with skintones looks consistently wrong for a lack of a better word.
‘filmic’ is a departure from rgb ratio where I sometimes like, sometimes dislike the rendering.
Maybe I’ve said it before? Unless going for a full blown CAM-for-display-rendering approach like RT has implemented (with all the questionsmarks regarding which CAM and UI/UX problems) I see Jakobs work as a clever approach to the problem of display rendering transforms. Is it perfect? No, and I don’t think he claims it is. Are the residual problems ‘in your face gigantic’? No, infact I would have a hard time pointing at them.
I would love to see some comparisons to OpenDRT and/or ZCAM at some point, as well as RTs CAM16 implementation…just out of curiosity.
I suspect better results could be obtained by filmic with more tweaking rather than out of the box defaults, nonetheless Preserve Hue consistently does a brilliant job, and I can’t wait to see this added to darktable. Are you aiming to have in the next release, dt 4?
Only adjusted the white and black level, the rest are the defaults.
RGB Power Norm, it does however not really matter that much in this case. The main contributor to that look is the use of rgb ratio as the color-preserving method for the display transform.
I do not know, but my guess is that those previews simply are the camera jpegs.
“no preservation” in Filmic is equivalent to per-channel with hue preservation = 0% in the proposed sigmoid module. So choosing that option will absolutely get you closer to the jpeg look. But you would get the hue twists as filmic currently doesn’t have a hue preservation option.
Thank you! I’m interested in how would you describe the difference
That is problematic because you, as one of the devs, are one of the more important recipients of these tests. My reasons for posting these tests are simply me trying to show that the sigmoid module has improved to a point where it’s merged and additional functionality can be added as follow-up PRs.
My idea was to show two things, it is possible, and I have implemented a way, to correct for hue in a per-channel display transform. The second part is to show that the rgb ratio option in sigmoid is equivalent to the filmic preserve color method. The point wasn’t to prove one better than the other but rather to show that the sigmoid module is, I believe, now good enough for a merge!
@PhotoPhysicsGuy read it the right way My goal was to show the general difference between the two “schools” of display transform and that both a present in the sigmoid module. I guess CAM stuff with OpenDRT or ZCAM potentially could be categorized as a third school here. Those are out of scope for me though, but figuring out how to merge the sigmoid module could pave the way for a structure of merging a CAM based display transform as well!
I would love to get it in but it isn’t up to me when it happens in the end. The only thing I can do is to try to show that its a worthy candidate for display transforms. I guess it might still be labeled “controversial” if I make a new git PR…
@RawConvert do you get a sigmoid module when you build that? The branch is called sigmoid_tone_mapping and it should only be four commits behind the darktable org master. I have also updated the tags. You might need to do: git fetch --all --tags
Well, adjusted to what ? I’m sorry but this is clearly insufficient, or there is something I don’t understand … a filmic user like me doesn’t just adjust black and whit point … what about parameters of the look panel ?
My goal was to show the general difference between the two “schools” of display transform and that both a present in the sigmoid module. I guess CAM stuff with OpenDRT or ZCAM potentially could be categorized as a third school here. Those are out of scope for me though, but figuring out how to merge the sigmoid module could pave the way for a structure of merging a CAM based display transform as well!