out of the box RAW rendering not up to JPEGs

Personally, I’ve created my own custom input/camera profiles for darktable/RawTherapee/Lightroom so that I have the same colour base to start from in the raw converters I use. I use DCamProf to do so. It’s based on Argyll but additionally it offers very nice gamut mapping and tone operator choices. It also has various look options which will help you with out of gamut colours like the ones you’re struggling with.

While the conversation revolves around detail in the LED-lit bridge and LR is held as a high ideal, no one seems bothered by the loss of color detail in the LR and OOC images.

Watch these areas:

OOC, the car light is gone, the roller coaster seems like its evenly lit by a typical orange sodium-vapor lamp:

LR, same:

RT:

The camera has the benefit of having its raw processing engine and settings designed by the same engineers who built the camera, and LR has the benefit of having over 100 full-time employees with the sort of access we can only dream of. Despite this, our open-source projects do perform damn well, and each program (including LR) happens to be better at some things than at others.

5 Likes

In the spirit of my last two samples…

ACR minimal processing:
roller-crop-acr

dt minimal processing + gmic median 2:
roller-crop-dt-med

One additional observation, maybe a hint for the devs. If you move the bridge into focus and then take a look at the region close to the borders there are a bunch of arteficial pixels. If you pan the image, they always stay near the border like a sort of inbound frame. Also, if you move your focus to a darker region of the image, they dissapear completely. Switching on gamut detection highlights them .

dt, 200%, gamut detection off

dt, 200%, gamut detection on

Hope that helps!

Jürgen

1 Like

For what it’s worth, I ended up turning a slight variation of this pic into a play-raw thread, if anyone is curious to play more with a large image.

Thanks again everyone for your contributions here, I learned a lot and it was amazing. Special thanks to @houz and other Darktable developers for their amazing work. It’s great to see you participate in the “user-land” discussions here and I really appreciate the time you take to actually do this.

Wow, so this is an old thread now… but after using darktable for some time and having just recently read darktable 3.0 for dummies: hardcore edition, I was inspired by @anon41087856’s handling of LEDs and decided to revisit this photo using darktable 3.0.


DSCF1110_06.RAF.xmp (11.9 KB)

I didn’t attempt to match colors to Fujifilm’s JPEG rendering, but I did warm up the midtones after first correcting color a bit (based on a building I thought might be approximately “neutral”).

I did also mask the bridge in the color balance module I used for the warming effect, as I also boosted saturation in the same module. I thought the bridge already has a lot of character in the photo, so it didn’t need any more help. :wink:

In addition, I did push local contrast up a bit more than usual, but it’s a city scene and darktable could handle it (and can handle even more than what I went with), thanks to sticking with the modules @anon41087856 worked on and suggests.

2 Likes

You seem to think jpeg should be the starting point. In fact, it is a dead-end :slight_smile: Darktable gives you the opportunity to back up and choose a better path in the first place.

Agreed.

The difference between the JPEG from the original poster at the top (from two years ago!) and all the various permutations on this thread demonstrate how raw files are better than out-of-camera JPEGs.

Also, darktable keeps getting better — 3.0 is leaps and bounds better than 2.x. (And there are other raw conversion tools other than darktable too, naturally, and many of those are quite good as well.)

I just thought it would be interesting to re-visit a notable tricky raw with a revised toolset. :wink:

1 Like

I was actually reacting to the OP’s remark:

I didn’t notice that the thread was so old, otherwise I wouldn’t have bothered commenting on it.

It is my starting point. It’s what I see in my camera when I shoot. It matters.

I agree that Darktable keeps getting better, and I’m incredibly grateful for it. I wonder what the new noise reduction stuff would do with the bridge smudges I detailed here and earlier:

To be fair, this is an extremely hard scene to render. Colors are all out of whack because of the LEDs and there’s a lot going on. But the JPEG from the camera is not a dead end for me - at least in terms of sharpness and noise reduction, I rarely am capable of going back to that level of detail when I start from the raw shots.

And, comparing your rendering to the original JPEG, it still has a lot of fuzziness in that area, so maybe that’s still somewhere the JPEG has an edge. The colors on the Molson tower also seem more realistic in the original…

But thanks for taking a fresh look at this! :slight_smile:

1 Like

We will never be able to beat your manufacturer on its own ground. He knows his sensor, his optics, is ADC,… of course OOC will always be better for less trouble (assuming the firmware did understand what scene it was processing).

That’s one thing I find fascinating with software like Lightroom: their rendering of big brands (Nikon, Canon, specificall) is so close to the OOC version that I suspect there is some IP exchange between the companies to make sure it works that way. In other words, I wouldn’t be surprised if Canon and Nikon would send Adobe some specs (if not some engineers) before they release a new line. In those conditions, of course it’s hard for you folks to compete…

At least they have a lot of developers to reverse engineer stuff. If you profile your sensor as described here: PIXLS.US - Profiling a camera with darktable-chart you‘ll get more ooc like colors. Unfortunately this doesn’t fit to the new recommended linear rgb aproach - the tone curve is required in most cases.

Is there any possibility of adapting the former to the latter?

If you follow the procedure @Elle Stone outlines here:

https://ninedegreesbelow.com/photography/articles.html#profile-digital-camera

you’ll make a linear gamma profile for your camera that’ll work just fine in a linear workflow.

Indeed, you need the color part of this work for any raw processing, as converting to sRGB or other output profile requires an input color profile that represents the camera’s spectral response. In an ICC profile, the tone part can be effectively nullified by making the tone curve a “gamma 1.0”, which is what the -am parameter in @Elle’s colprof command does.

3 Likes

You don’t need the tone curve. darktable-chart has been improved lately and on exporting the style you’re able to select which modules you want included. You can just export the LUT if you want and it should work just fine.

1 Like

It is better to use darktable-chart than producing an ICC profile.

1 Like

You can just use the LUT and go with filmic.

2 Likes

its not exactly the same:
example for “famous canon colors”:
1: just color lookup table created by darktable chart
2: color lookup table with tonecurve created by darktable chart - similar to ooc jpeg
3: filmic adjusted to get a similar greyscale; preserve chrominance = no
4: filmic as 3 but preserve chrominance = rgb power

in case of 3, filmic + preserve chrominance = no, you can tweak the yellow tone by increasing output saturation about 10% in color balance, but then the blue tones are ways too saturated
For different picture styles different fine tunings needs to be done to get a result similar to ooc jpeg - manually instead of just using darktable chart to give you a decent style :wink:

Looking at your chart picture 100% it clearly has glare. The resulting camera profile is pretty much useless and probably the reason why you have issues with your blue tones.