I did, it’s what I am saying … I tried to extracting the dcp files from Adobe DNGConverter_12_2.exe but it doesn’t help … Those profiles has not much to do with Tone/Color Curve from embedded JPG in RAF …
I didn’t want to attach here those files because they are probably proprietary and everybody can download them for themselves … simply they don’t work … I’ve provided RAFs, you can test it for yourself with provided raws …
@floessie - please keep your tone civil … I am 20+ years linux guy who works in IT industry and who contributes his entire life to foss. I’ve created a bugreport here and provided all input as best I could do, I cannot contribute to this with code because I am photography user only … I’ve even provided the code for my Fujifilm curve that I’ve created based on Darktable Fuji-like profile … please see above …
Let’s avoid unnecessary generalization. You claim it is broken, others haven’t. We’re always interested in improving our software, but, for what it’s worth, we don’t care much about public opinion. It’s open source software, if they don’t like it, they can fork it and change it, or avoid it. It’s a free world
As for the way RT works: the auto-matched tone curve option is enabled in the default processing profile, because in many cases it gives you a good starting point for further editing. But that’s precisely the point: it’s never meant as a one-stop tool, YMMV. You can choose an even more barebones starting point by starting with ‘Neutral’, which has all tools disabled. Or you can make your own processing profiles to accommodate your specific needs.
The point @Floessie made is that there are ways to improve the color rendition of RT when things are sub-optimal. Providing shots to create a DCP profile that we can ship with RT is a very good way to do that. Please see the provided link for details.
I assume you have found our GitHub and know that bugs and feature requests are tracked there? This forum is for discussion mostly.
I use a Micro 4/3 camera and I noticed that often the auto-matched tone curve yields a result that does not match the embedded jpeg.
I spent some time thinking about this problem, since I am confident that the auto-matched tone curve should work better, and that it works well for a lot of users.
Micro 4/3 wide angle lenses very often have a huge barrel distortion and I noticed that the embedded jpeg is a significant crop of the image that I see in Raw Therapee.
Is it possible that the distortion + crop combo creates a significant difference between the embedded jpeg and the RT image, so that the auto matching algorithm is fooled?
Maybe this also happens to Fuji lenses and this could explain the problem reported in this thread.
Does anybody know if auto-matching is performed before or after distortion correction? If it is performed before maybe performing it after could yield better results.
Hmm, interesting. The auto-matching algorithm is a cumulative distribution function based on the embedded image and neutral raw histograms, so yes, if the crop was significant it could affect the outcome. it will be image-dependent, as it will depend on how significant the contribution the cropped part of the image makes to the overall topology of the histogram.
Any camera that applies lens distortion correction in-camera will present this case. The Nikon Z lens system is apparently based on such correction.
I dare to guess that this time there ain’t problem with distortion + crop … 35mm has very low distortion … Problem here is I believe with something else … attaching yet another RAF + JPG now with pp3 (unmodified, only opened file) + DT’s xmp
I can provide even more prominent example … see please the fancy shape of RT’s curve … RT really does something weird with reading profile from embedded JPG … I have no idea what more I can provide regarding this issue …
Just a guess: Fuji internally underexposes the raw to preserve highlights and corrects this in the embedded jpeg.
Maybe auto-matched does not work well in this situation… @agriggio
underexposing `ist kain Problem’ but the shape of the Colour Tone curve is because the Auto-Matched Tone Curve seems really completely made up instead of derived from embedded JPEG …
this doesn’t seem an issue with other cameras - I can judge based on Nikon and Canon RAWs so far - I’ve never experienced that the Auto-Matched TC was so far by miles from JPG …
another think is the approach as whole - for example Darktable (correct me if I am wrong) rather apply a per brand/camera presets and at least in case of Fuji the results are much better than deriving that from embedded JPEG
You are right, there are no distortion nor cropping in your image.
I opened it in RawTherapee, selected the “Standard film curve - ISO Low” profile and the image was really underexposed.
Then I clicked the “Auto Levels” button and I instantly got a good starting point.
This is a bit rich. You’re telling the person who built the algorithm in the first place and comes up with a potential solution that he’s not following procedure now?
@agriggio I am compiling your branch atm. In the meanwhile, I found that setting the Tone curve to ‘Luminance’ mode gives an image much more true to the embedded JPEG. Could this simply be due to the fact that the matching itself is done on luminance values?
@Thanatomanic that’s not the curve I’m expecting to see though… I forgot to mention you need a recent version of exiftool to see its intended behaviour. (And maybe also try clearing the cache and arp just to be sure)
@sigsegv111 no worries, I think there was a bit of misunderstanding. My tentative fix is done in ART, not in rawtherapee. While it can be certainly ported over, it can’t be immediately copy/pasted, and so it wouldn’t belong in rawtherapee’s GitHub tracker I think
So there are two curves now, smart idea. I’m inclined to say this performs slightly worse than before unfortunately.
FWIW, I tried some histogram matching outside of RawTherapee by manually doing it in Wolfram Mathematica. I also tried to match on different things: luminosity, mean RGB value and B only (because of the sky). If I plot those curves overlaid on the curve in RawTherapee, I get this. Blue dots = luminosity, orange = mean RGB, green = B channel only.
I would say the algorithm in RT gives very comparable curves. The one matched on the blues gives a slight push in the second half of the histogram, which could be an improvement for the match of this particular image if the tone curve is set to Standard instead of Luminance.
Mathematica actually makes less of a nice curve in the upper regions, but that’s not surprising since the histogram is pretty flat there and I didn’t like optimizing the interpolation process further.
