Look at the screenshot:
P1080036.RW2 (18.7 MB)
I’ve never been able to use that feature to my liking. Frankly, I’m not even really sure what it’s supposed to do. The couple of times I’ve clicked it, I’ve had less than desirable results, so I just go back a step and use both of the tone curves.
It calculates a tone curve to approximate what the camera did to produce the embedded JPEG. You need to be happy with your in-camera processing to be happy with it…
In this special case it failed. For that reason I pinged @agriggio who wrote the code. Maybe he has an idea…
Just to clyrify: I simply load the Profile labeled with “Auto matched curve”. It actually uses those profiles by default.
I am most of the time quite happy with the default. There are definitely differences between AMC and OOC, but they are minor and I most of the time like RT better than OOC. It however is just a starting point for me. Usually I have to adjust brightness and contrast, often I also use Highlights/shadows module. More often I have to adjust white balance. I really wish panasonic had a better auto WB as I am Red/green blind and struggle quite a bit finding a setting I like (and OOC is off there, too), and unfortunately more often than I like I simply hit “black&white” and have instant success 
A really working Auto-WB in RT would be a killer feature for me!
When I can specify a camera .dcp to use in Color Management | Custom , the Tone Curve checkbox usually gives results I prefer. How does it differ from the Auto Matched Curve?
That is my preferred way to start processing a picture - use the tone curve in the DCP file.
This way, I still have the two curves in the exposure tab to play with if I want to really fine-tune them.
In most raw files is an embedded JPEG of the image, made with all the in-camera settings. Auto-Matched Tone Curve in RT takes that image and the raw image, and calculates the difference between the two in tone, or more specifically, the tone curve it would take to make the raw image look like the JPEG. It doesn’t mess with other things like saturation.
So, the real test to see if AMTC is working is to compare the result with the embedded JPEG. in my RT 5.5 AppImage, the thumbnails look to be the embedded JPEG, someone correct me if I’m wrong, so that’s what you can use to compare to the AMTC result. So, AMTC benefit is directly reliant on how the OOC JPEG was produced.
If the DCP profile contains a similar curve to what AMTC calculated, then the results will look similar.
Again, all this tone curve stuff is just about tone, doesn’t take into account sharpening, denoise, saturation, or any of the other thing you could inflict upon your image…
Oooh… AMTC is a slick feature, it’s exactly what I’m looking for in order to reverse engineer certain behaviors of one of my cameras. Thanks for the description of what it tries to do.
Most profiling documentation I’ve seen discusses how to profile a camera’s RAW behavior, not necessarily how to reverse engineer the JPEG tone curves - which may be necessary if you’re trying to reverse engineer a tone curve so that it can be undone when processing video recordings.
Not sure how AMTC would help here, as the raw image is needed to produce the cumulative distribution function data that goes into the difference calculation. The wikipedia article on “histogram matching” has a description of the algorithm for consideration.
I guess I wasn’t entirely clear about what I was hoping to do:
The camera can either shoot raw DNG stills (I believe with embedded JPEG, I need to check, from what I recall it can’t do simultaneous DNG+JPEG), or it can shoot video without raw data.
The thought I had would be to use AMTC to determine what tone curve was applied to the stills, and then use that reverse engineered curve to design an appropriate LUT for converting video recordings into a more standardized colorspace.
The camera in question is a Yuneec CGO3 - which has a video/JPEG preset called “RAW” which is not, by any means, what any of us would consider to be raw, but is in fact more like the various logarithmic video tone curves intended to be used with color grading as part of a postprocessing workflow. The problem for me is that unlike most log video transfer curves which are well documented by their manufacturer (hence making it fairly easy to generate appropriate LUTs using the documented transforms), the CGO3 “not really RAW” transfer curve is completely undocumented. The manufacturer states the setting is intended to be used with color grading tools, but doesn’t provide the necessary information required to properly set up color grading tools in a consistent manner…
Should I expect that all AMTCs should be (essentially) the same for a given set of camera settings?
Ah, now I get it…
Right now, I’m messing with a cdf-based tone curve calculator in img, my command line processor. It follows the Wikipedia histogram-matching algorithm, and the objective is to puke out a 256 value 1D LUT describing the curve. Right now, with a simple “walk to equality” to find
the midrange looks approximate but the endpoints are wonky.
I’m studying the RT histmatching.cc code for insight, but I’m pulled among various household and work (part-time, yeah right…) tasks and won’t make much progress until next week, maybe…
I think I have the same bug. It only happens with shots from my Panasonic FZ330 shot at it’s widest angle (4.5mm) but not every shot at that focal length is like this. The Standard Film Curve is fine but the Auto Matched Curve is washed out sometimes. The embedded jpeg looks fine in FastStone Image viewer.
P1110377.RW2 (14.3 MB)
Hmm… That’s a fun challenge. Since automatching relies on the JPEG (which likely has camera vignetting/distortion correction applied), then the input to the algorithm should probably be after lens vignetting/distortion correction is applied to the raw file?
which in this case has cropped away the dark corners…
I’m guessing it is likely not a simple crop on its own - more likely what has happened is that the corners in the JPEG have been stretched out to correct for distortion.
I’m guessing if I attempted the same with my Sony 24-105G I’d get similar results - In that case the JPEG may be slightly cropped, but the corners are definitely expanded moreso than the JPEG is cropped.
I guess the question is - if you use lensfun to correct distortion, do you have the same results as the JPEG, or is it further cropped compared to the distortion-corrected image?
