Hi Mica, I almost never disable the Base Curve but I have found that the RAW overexposure warnings show that you can pull back some blown highlights on occasion, and this was one of them.
I would usually bracket a shot like this and then use Hugin to create a tif to bring back into DT but on this occasion, I hadn’t bracketed.
Thanks,
Euan.
Thanks Thomas, I’ll take a look at your xmp now. Much appreciated!
Thanks Alberto and Sebastian.
I’m not very familiar with RawTherapee although I do have it installed. I usually use Darktable.
The setup you have with your X-T2 sounds very interesting Sebastian, I’ll have to look into that and see if something similar can be done in DT. I got some film simulation presets from a post on here a few months ago, they’re very good.
Thanks, Euan.
The redness of that part might be because of your custom base curve. It works in RGB color space that means it can cause hue shift (more information here and here). If you share your sidecard (the XMP file) for your edit, it would help to investigate the reason more precisely.
Euan, I showed what I get in RT because you mentioned RT in the thread’s title. I’m not trying to convince you to use RT, I know that it’s difficult to switch to another software.
What’s happening here is color channel clipping.
When you have a very intense red-orange, the colors might be in a ratio of 4:1:0 red:green:blue.
However, when it’s very bright, the red channel alone gets clipped and the resulting color ratios can become 4:2:0, much more orange, or 4:4:0, which is fully yellow.
This is objectively incorrect; sunsets are far more red in real life than commonly depicted in photographs.
So in this case, the Fuji and Capture One results are unrealistic, and darktable is much more faithful to the original scene.
Thanks for the further info everyone. Very interesting point @CarVac!
I’ve attached my sidecar files for both RT and DT.
I really appreciate all the feedback folks, much appreciated!
RT: Just imported, no changes.
XT2S5663.RAF.xmp (6.0 KB)
DT:
XT2S5663.RAF.pp3 (10.1 KB)
There are many reasons why a JPEG image produced by a camera (or by manufacturer software) may differ from that produced by other software. Remember that a raw file is like a kitchen full of raw ingredients, while a JPEG is baked by a specific chef.
Start by reading this:
http://rawpedia.rawtherapee.com/Getting_Started
RawTherapee 5.4 uses a color matrix derived from dcraw for converting sensor values into the XYZ color space for the FUJIFILM X-T2. The JPEG image embedded in the raw file might use a different matrix (I haven’t checked).
RawTherapee 5.4 does not have a DCP input profile for the X-T2. The colors differ when using the dcraw matrix as compared to when using a DCP from Adobe:
A camera performs various adjustments to the image when creating the JPEG. These adjustments are aesthetic in nature - accuracy is not of primary concern. These adjustments can also contribute to differences between the out-of-camera/embedded JPEG and what you see in other software.
The camera may be working in a different color space than other software.
In addition to the rigid requirements imposed by various standards concerning developing a raw photo there are various gray areas where there is no one correct way of handling things. Such areas may be handled in one program (your camera’s firmware) in one way and in another program (RT/dt) in another way, and neither is incorrect. For example, how are ultra-saturated colors to be handled - clip, desaturate, or shift hue? How is the input profile’s LUT to behave when the required adjustments are too acute - is it to literally reproduce known points at the risk of sharp transitions, or should it be relaxed to ensure smooth transitions at the cost of altering the values of known points, and if so, how should those value be altered? Different solutions will lead to different results.
Indeed. I totally forgot that I’m actually using the X-T20 dco profile bundled in RT, which I renamed to X-T2. Both caleras use the same sensor and processor and should behave similarly with regards to colors.
oh, right! I’m using one that I built myself from dpreview’s studio shots, as I usually do when there’s no better one in RT… it takes 5 minutes and the results are typically quite reasonable
I already thought about doing that too, but since there’s a good for basically the same camera as mine, I didn’t bother.
This is the closest I can get to your Capture One version with my custom darktable dev version:
I use 2 modules I have developed myself (specifically to close the gap between Capture One) that are not in the main branch.
The problem you have comes probably from the global tonemap.
Thanks again for all the further insights into this, much appreciated. I’ll do a bit more reading tonight @Morgan_Hardwood, thanks for the links.
@anon41087856, very interesting… Where can I read more about the modules you are working on?
Just for fun, I tried to emulate the C1 rendering in RT. Here’s the closest I could get:
You’re right that the discrepancy is due to the jpeg compression, but human color vision is a super complex thing, and the memetic function of a photographic image production system also implicitly compresses the range of brightnesses in the scene to something that “looks right” for screen or paper. There’s nothing “objective” about photography.
It’s not about JPEG compression, it’s about highlight clipping.
I assure you that if you held these photos up next to the actual scene, the tonemapped darktable version would reflect the real world color better, simply because it retains the correct hue, which is roughly the same as the darker surroundings, instead of hue shifting to yellow.
It’s me again. I have developed yet another module for darktable. Here is the basic result:
Stay tuned to see if it will get merged like the 2 previous.
Very impressive, particularly with the shadow recovery. The accuracy of the colours in the recovered shadows is spot on!
What is this latest module you’re working on?
I think the dynamic range compression in Rawtherapee could works in a similar way of the log+curves workflow.
It’s necessary to add only exposure compensation before the dynamic range compression(like the middle gray slider in the darktable log module).
In this image I have increased the exposure in darktable about 2.22 EV and exported as linear floating point, then in RT the dynamic range compression tool with strenght=35, details=75 and anchor=9
Add a single s-curve
