darktable
darktable copied to clipboard
darktable-org
Introduce as-shot to later D65 workflow (improved highlights)
Replaces #15461 and #15505
Please note that temperature module version is increased in the PR so keep backups while testing
The current modern chroma correction workflow assumes "camera reference point" (nomally D65) has the best available data for temperature coeffs as preliminary for all modules in the pixelpipe before colorin. There we change to working profile and continue work for best visual quality until the "color calibration" module.
There is one drawback with this approach. Some modules in the pipe would like to have "perfect white balance" correction - the rgb channels all have the same value for any greytone.
Examples:
- Some hightlights reconstruction algos take the other channels or surrounding data into account and modify data "towards white".
- raw chromatic aberration correction also iterates from channel differences. Good "white is white" coeffs help significantly here.
- Some demosaicers also have slightly improved output on pixelpeeping level.
- denoise profiled
In short - how does it work?
was: data(rgb) -> temperature(*D65) -> ModA -> ModB ... ->colorin
now: data(rgb) -> temperature(*as_shot) -> ModA -> ModB ... -> *(D65/as_shot) ->colorin
This version has more anti-chroma-casting implemented for opposed and segmentation based, generally better than we had before.
- @rawfiner certainly worth more testing if you find the time
- @wpferguson for you too
- @garagecoder and @IainMF it might be interesting for you too and i would appreciate your testing on highlights. I did a lot of tests and i couldn't yet find an image that's worse with this code than what we had before. (Almost all images make blown outs more towards white than before ...)
I'll let other test too... but on my side I see no difference using D65 or late-D65 mode, using snapshot and comparing on multiple images (zoom 100%, 200% & 400%) it seems that every pixel is identical on the two modes.
Take the image you suggested, reduce exposure so that you don't have anything bright any more and maybe even disable filimc/sigmoid.
Look or possibly zoom in to the bright all-blown area at the top left.
Now toggle between the mode 4 / 5 (the new one) and either a) observe the vectorscope/histo b) use a picker there or c) use the snapshot !
There will be differences only if modules work not in a strictly linear way like highlights (the others are not always as "easy" to spot as here), @rawfiner gave another example with denoising, i also could provide images with CA where you will have slightly better reconstruction).
@TurboGit not sure if we would want the new mode to be the new default...
- @rawfiner certainly worth more testing if you find the time
- @wpferguson for you too
- @garagecoder and @IainMF it might be interesting for you too and i would appreciate your testing on highlights. I did a lot of tests and i couldn't yet find an image that's worse with this code than what we had before. (Almost all images make blown outs more towards white than before ...)
This sounds interesting. Unfortunately, I'd need someone to do a windows build for me.
One thing I thought of was, what happens when the 'as shot' white balance is wrong. For example, if you used the 'daylight' setting on your camera when the lighting was 'tungsten'.
One thing I thought of was, what happens when the 'as shot' white balance is wrong.
Yes - that's the major problem not making this the 'default' :-)
@jenshannoschwalm : Indeed lowering the exposure I see now that the late D65 gives a slightly better result (less reddish).
About the question for making the new mode the default, my proposal would be:
- Make the new mode the default
- For the new edit, have a single button for the new mode
- For old edits, keep both buttons
- When new mode is selected for an old edit, keep only the new button when entering darkroom again.
Of course this is only if new mode is always better. What do you think about this?
But... Then I'd like to do that at a safe time and not now, so I'm proposing to wait for after the 4.6 release.
What about this plan?
Checking by eye, there's a general improvement for modules such as highlight recovery when in the new mode. The idea seems sound, but perhaps difficult to test output for correctness.
@wpferguson IIRC you build on windows too. Could you provide a windows version including this for @IainMF ?
If I understand correctly, the main disadvantage of this mode is when the "as shot" white balance is wrong. Actually, would it be possible to synchronise the white balance module with color calibration settings instead of using the "as shot" white balance? That way, it would garantee good results in all cases as the user will be able to fix wrong white balance settings.
Actually, would it be possible to synchronise the white balance module with color calibration settings instead of using the "as shot" white balance?
What do you mean here "exactly" ? Some sort of feedback?
Another idea i was thinking about:
- don't add the 5-ths button (take as-shot and later correct)
- have a tooglebox - use what is defined by the temperature module as set by the user and do the late change based on that?
Yes, some sort of feedback. Color calibration would decide the correct white balance, the white balance module would apply a similar one, that would be transformed to D65 before colorin, as in your PR. Note that I have no idea how doable this is though...
@IainMF here's a link to a windows version with the PR, https://drive.google.com/file/d/1fNRfxbjaN351ZrvjDJPf66EbHARjehZ0/view?usp=sharing
@IainMF here's a link to a windows version with the PR, https://drive.google.com/file/d/1fNRfxbjaN351ZrvjDJPf66EbHARjehZ0/view?usp=sharing
Thanks!
For those of you not knowing this thread https://discuss.pixls.us/t/diagonal-interpolation-correction-artifacts-with-amaze-demosaicing/3338 - it's pretty long and you may well cross-read the first ~60 items but it becomes very interesting as the implementation details of the rcd demosaicer are discussed with reference to others (AmaZE ..) and how a not-perfect white balance affects the demosaicer output quality. Very subtle but clearly there. Also hints about raw CA correction. It's all about RT and mainly RT devs speaking but the problems are pretty much the same for dt.
If you read through all of it it may become more clear why the current "chromatic-pipeline" is suboptimal.
@jenshannoschwalm : This needs a rebase an conflict resolution.
I've a bit lost track of the work here, what about having this new mode the default as usually better (I have proposed this here https://github.com/darktable-org/darktable/pull/15602#issuecomment-1804235407).
Or do you prefer having this in now and rework the default later (or not if not actually a good idea)?
@TurboGit i will certainly rebase pretty soon and will do a lot more testing. About being the default, maybe i will be sure after that testing, otherwise we can decide later after more people - using other cameras and camera settings - had their say on this.
Sounds like a plan!
:-) Also there is more urgent bugfix work to do for 4.6.1, besides the RGBE loader i also spotted problems with some exr and tiff files :-( EDIT: false alarm. What i see are problems with the scaling algorithms.
@TurboGit @rawfiner @wpferguson
Would appreciate your re-review after a lot of testing and more fixes.
- The new mode has been set as default now, a) couldn't find any issues b) subtly better in almost all cases c) coudn't yet find a single image where it's worse EDIT: except those with a very wrong as-shot WB.
- BTW the latest commit is something we might also want for 4.6.1 - or a working variant of it - as it seems to be a genuine bug
Gentlemen, many things here are above my head. I have tested a bit, as it is merged now.
One thing drew my attention. Pictures which have an empty/discarded history, the color calibration now is set to adaptation = none (bypass) by default.
I donno this is a "has to be", just as a user I am medium happy about this, as most of the new pictuers I open, I first have to click the reset button on color cal....
Does this work take into account using the "Unity" white balance method for expose-to-the-right shooting? That is, you have your camera white balance set to (1,1,1). So selecting "as shot" in DT gives a green image. I'm thinking this will throw those modules which are supposed to like As Shot coefficients.
Sincerely, i dont understand. Some modules like demosaic, Highlights, denoise and RAW cacorrect simply need good color coeffs for White Balance.
It's about judging clipping in the camera, typically for ETTR, it's not precise because the camera shows clipping in relation to the jpeg, not the Raw. So someone had this idea to remove the white balance from the equation by using a custom white balance which happens to be (1,1,1), got by shooting a white-ish sheet of paper and totally overexposing. So in DT, the as shot coeffs are (1,1,1). But you don't use those obviously, you choose Camera Reference, or maybe set the temp that looks best. The new white balance option is using As Shot, so I thought this might cause problems for those of us doing Uni White Balance.
Thinking about it more generally, for the majority not doing Uni W.B, if you're shooting Raw, do you care much about white balance? I'd imagine many don't set it shot by shot, knowing it will be dealt with in DT. The new option seems to be the default, so people will be using a "random" white balance for some of the modules. That doesn't seem right. It would be using a piece of data for the processing which the user never intended to be used, surely?
There are a number of articles about Uni WB, here's one http://www.guillermoluijk.com/tutorial/uniwb/index_en.htm The bit about overexposing a white sheet is at the end.
I know the dt code for all modules handling raw data quite well, most of them expect white balance to be as good as possible already. So if your preset is good, that's fine. (this means any Grey area should have equal rgb data after the temperature module.) if not, all those modules will work but with inferior quality. That was the rationale behind the pr, we make the best guess from available data.
Otherwise we use data found in exif, the new mode is slightly better than what we had if camera did correct wb, after colorin module the data are exactly as before this pr by default.
Hanno, I'm struggling to see how your reply answers my points, in particular that the new option will use As Shot coefficients which may be at least imperfect and possibly way out compared with the scene when the photo was taken. Of course I don't know how many DT users don't worry about the camera WB, but do you have a feel for this? It might be lots.
You say "most of them [the DT modules] expect white balance to be as good as possible already" and if not there will be "inferior quality". So As Shot is not a guarantee of best quality, which is surely what we want DT to be capable of. It seems to me that users need to set the best temp and tint in the WB module from the start, if they want best quality. How about this as a different solution -
- communicate clearly to users the issue about needing best WB for certain modules for optimum quality
- continue to default WB according to Preferences settings
- no new option in WB dropdown!
- if user doesn't want to set temp and tint for rather small improvements in image quality (I understand it is marginal?) then user continues as previously, e.g. with Camera Reference
- if user wants best quality, user adjusts temp and tint
- there is a new tickbox in the module saying "use Camera Reference/D65 later in the processing" which is ticked by default.
I've tried a couple of raws and am a bit confused. Both have As Shot as (1,1,1) i.e. Uni White Balance method. I can see no difference between "camera reference" and "as shot to reference".
Also when I choose "as shot to reference", I get a "white balance missing" red message in WB and color calibration.