Yes, definitely. In rawproc, I just set the whitepoint at the minimum of the channel maximums and pray a contrition to @aurelienpierre…
I’ve now compiled both RT and dt current, and in the new year will mess with the respective reconstruction capabilities, particularly RT so I can understand how to use the librtprocess recovery function. Thing is, some scenes are just challenging this way, and for most cameras putting those highlights in definition will make dealing with the shadows even more challenging, no matter the software.
Looking forward to our visit to the same cabin next year, so I can set up an equivalent scene, expose it ETTR, and see how the shadows fare from the Z6 sensor…
@agriggio I updated the french translation file, which include all the improvements you bring recently (new lines 821, 1983, 1984)Francais.txt (150.8 KB)
They should not be that different as I only use amaze demosaicoing, white balance with same parameters, color management with same parameters, all exposure parameters set to 0 (no clip out of gamut for RT).
So there should be some hidden processing or a bug in one SW to explain the difference: ART mid and high luminance pixels are more exposed than in RT.
You are right. if in RT I click on clipped highlight indication and clipped shadow indication, I can see clipped highlght and clipped shadow zones. Nevertheless there is no indication in the histogram.
I do see the raw clipped highlights. but for clipped shadow I can hardly see them. I only see some colored pixels in the shadow zone.
clipped shadows indication zone : when I hover on the clipped shadows zone, the RGB values seem always greater than 0. I imagine there are only a few clipped pixels in the zone.
I tried in ART to get the same non clipped histogram as in RT. That was indeed a complete failure.
Just curious is there an explanation of how the pipeline for ART differs from RT and why the changes were made? (Just a brief overview if it’s not to complicated to explain?)
It is indeed a bit complicated to explain. There are different reasons:
to have a clear separation between tools operating in “scene referred” space and tools operating in “display referred” space, similarly to what is happening e.g. with darktable
to have a more modular organisation of the code
to fix (what I perceived to be) some inconsistencies in the way some tools were applied
finally, it is likely that some changes were purely accidental
Just to be clear, though, I think there’s nothing wrong in the way things are done in RT. I just had a different opinion about some things and wanted to try some alternatives. Not being constrained by backwards compatibility (which is very important for RT) made experimenting quite easy.
@agriggio
I updated the line 1124 (sharpening tool). Do not hesitate to ask me for a verification of the french language file before you decided to release the 1.0 version of ART.
Serge MoreauFrancais.txt (150.8 KB)
thanks a lot @srgmro for your help! I am finalising a couple more things and then I plan to publish a first release candidate. I don’t expect changes in the language files but I’m not sure yet…
@agriggio
A New french translation file, according to the modification introduce by @sguyader in the default language file. I had only to actualize the line 862 others were already OK.Francais.txt (150.5 KB)
I just want to mention this, so it may help someone who has similar issue:
I noticed that after upgrading from 0.2 to 0.3 via builds provided here for windows, the exported image when opened in other sw than ART was very midle grey-ish, low contrast. Same image exported with linux version self compiled using same sidecar file was ok after opening in same sw.
Removig local app data on windows fixed the issue and now both exports looks identical.
Does anyone prepare Linux builds (Ubuntu bionic here)? I tried building myself but make fails - and it is a long time ago since I looked at a Makefile.
Ciao Alberto,
thanks for the quick response … I thought when you click on the toner response curve button you can customize the gamma from the point the default was… OK then we have linear gamma of the working profile in RT too…
Excuse me but can you explain me the statement into Rawpedia
During this conversion, an internal gamma is set by RawTherapee that always is “gamma sRGB” i.e. “gamma=2.4 and slope=12.92”