out of the box RAW rendering not up to JPEGs

[anarcat]

Okay, here’s another example of the issues I found with this rendering. I’m probably nitpicking like crazy here, but here we go.

Here’s a crop of the bridge of the original:

And here’s a similar crop of the image as beautifully rendered by @garrett:

What strikes me now is not much the difference in colors: that’s pretty close, and anyways, it’s just close enough. What seems to differ wildly now is the level of detail: the original JPEG is so much cleaner, so much sharper… I know that RAWs are less sharp, but I can’t figure out how to make it that clean. I see @garrett did some sharpening in the end to try and resolve that, but try as I might I cannot figure out a way to reproduce this mix of sharpness and softness in the bridge’s superstructure.

What is it about that JPEG that makes that picture so special? Shouldn’t I be able to get more detail out of the RAW than the original JPEG, if anything?

Looking at the “original” RAW rendering from DT, it sure looks like some data is just completely clipped off:

DSCF1110.RAF.xmp (3.8 KB)

Of course that looks much better with the linear Rec709 RGB input profile:

DSCF1110_03.RAF.xmp (5.2 KB)

but even there I can’t quite get the level of surreal precision of the original JPEG…

Thanks again for all the suggestions and comments!

[anarcat]

@anarcat

It does look slightly better, but still completely blue and not magenta. I’m now left to wonder how the camera figured out this was magenta in the first place. That bridge is a (huge!) multimedia installation and I know some of those people that made it (the installation, not the bridge of course), so technically I could try to figure out what color it was supposed to be if that’s useful…

Oh and for what it’s worth, I started asking around for that, just to see what the original color was. Stay tuned!

[Wocket]

[quote=“anarcat, post:17, topic:6669, full:true”]
What seems to differ wildly now is the level of detail: the original JPEG is so much cleaner, so much sharper…[/quote]

The detail is there, IMHO. The shodows in the ooc jpeg are just a little brighter. For example, you can use the shaodws and highlights module to bring up the shadows a bit more.

Also activated the local contrast module and used the equalizer to go for a little more sharpness.

[houz]

@anarcat

That is quite impressive, I got to say. It’s almost exactly what I expected… Your mention of “velvia” reminds me that I did choose a specific “landscape” film emulation (called “Velvia” too! coincidence?) on the camera for that shot.

So you used an Instagram filter in your camera and wonder why darktable’s output looks different?

I see you used the “color look up table” early on in the history stack: what does that do? It seems to be the key change the fixes the color on the bridge to restore the original JPEG… or maybe the history is not ordered the same way here?

The order of the entries in the history list if just reflecting in what order the user has used the modules. The processing order is always the same and can be seen on the right side of the screen: All active modules are processed from the bottom (“raw black/white point” for raw files) to the top.

[anarcat]

@houz

The order of the entries in the history list if just reflecting in what order the user has used the modules. The processing order is always the same and can be seen on the right side of the screen: All active modules are processed from the bottom (“raw black/white point” for raw files) to the top.

Good to know, thanks!

[anarcat]

@Wocket

The detail is there, IMHO. The shodows in the ooc jpeg are just a little brighter. For example, you can use the shaodws and highlights module to bring up the shadows a bit more.

I can get similar results, but I can’t fathom why I can’t get the same smoothness from the original JPEG. There seems to be some artifacts in the RAW that I cannot explain. It seems it has something to do with the input profile again: there are burnt pixels that show up differently depending on the profile, which don’t seem to show up in the original JPEG… Here’s a 200% zoom on the bridge in the OOC JPEG:

Here’s the same crop with the standard input profile, with the rough deep blues:

Notice how the blues are burnt off chart, but also how the truss edges of the bridge are pixelized… The linear Rec709 RGB profile restore the scene, but burnt pixels actually remain on the truss edges, if you look closely:

Now, I’ve kept messing around with input profiles and I notice this phenomenon doesn’t occur with all input profiles. The linear XYZ profile, for example, doesn’t seem to have burnt pixels on the edges the same way the other two have:

Now obviously the colors are off to the red and the green and look weird. But notice how we don’t get those burnt pixels anymore? I guess this is what @garrett was referring to regarding colors out of gamut?

I think this is one of the problems I can’t grasp here: is it common to have to mess around with the input profile in order to remove burnt pixels? In this case, I can see with the gamut check tool (thanks for that!) that the rec709 profile gives the best results, but it still breaks down on the bridge trusses, just less so than all the other profiles:

The Linear XYZ profile, even though it looks faithful there, is just completely off the chart for the whole bridge in terms of gamut, so I guess that’s a lost cause for rendering…?

Here is, for reference, the gamut check with the standard color matrix:

A bit better than the XYZ profile, but still way off…

I see that the Fujifilm cameras don’t have a custom matrix in the camera support page, could this explain the problems with input profiles here? Is this the same as the DCP profiles RawTherapee uses? They don’t have one for the X-T2, but they do have one for the X-Pro2, which has a similar sensor… Could this be imported into DT?

Otherwise, I’d be happy to help creating such a profile if it could help…

Thanks again for all the great answers!

[anarcat]

Ah, and I have some results done with other software… Lightroom fares a little better:

My Lightroom-using friend also did some edits over the base image to hide those clouds and highlight shadows:

One thing to note is that Lightroom agrees with Darktable that the bridge is blue, which is an interesting outcome. The level of detail is also comparable with Darktable, although a little better, but not better than the OOC JPEG…

Rawtherapee also burns out the blues on the bridge, for what it’s worth:

Since I’m not very familiar with RT, I couldn’t figure out how to fix that at all to get a better image… But I guess this resolves the question of whether DCP profiles can fix this (although maybe RT couldn’t load the right profile in this case…)

[heckflosse (Ingo Weyrich)]

My try using RawTherapee (without sharpening)

[Nor_man]

For this picture its important to set input color profile to linear rec709.
I also used the colour checker lut module with a parametric mask on the C-Channel to exclude strong saturated colors.

For a good starting point I used my Basic DT Style which I created for my olympus EM10 with the IT8 target by wolf faust.
But I always use linear rec709 also with darktable-chart when creating styles for matching the in camera jpeg processing of the camera. this worked much better then standard colour matrix.
Oly_PM_Natural.dtstyle (3.5 KB)

DSCF1110.RAF.xmp (13.5 KB)

[krist]

To retain the original color of the jpeg, I often use Fuji’s free raw converter to a tif file, and then finish the final touch with darktable. The color comes really close using this method.

[Morgan_Hardwood]

If you care at all about color accuracy you should always use an input profile which matches your camera model.

The problem you’re experiencing is that the artificial light which illuminates the bridge is out of gamut, it’s not handled properly. All you need to do is to use an input profile which compresses the blues in some way. Which way? It’s a matter of taste. Your camera seems to shift the hues towards red, causing purple highlights to appear. A different solution could be to not shift the hues but to instead desaturate and increase the luminance of the deepest blues.

Using a simple matrix the blues go whack, but using the Fujifilm X-T1’s DCP (I don’t have an X-T2 DCP, though there is one in Adobe DNG Converter) resolves the problem:

I really like @Nor_man’s version, not in spite of but due to being creative with the colors. However this thread is more about the difficulty of preserving colors and matching them to what your camera shows without getting out-of-gamut blue artifacts, so that is what the following images achieve.

Using a proper input profile you can get good results (compare it to your out-of-camera JPEG from the first post):
DSCF1110 plain.jpg.out.pp3 (11.3 KB)

And to add some industrial light and magic:
DSCF1110 fattal.jpg.out.pp3 (11.4 KB)

[Morgan_Hardwood]

I did that using RawTherapee but I’m sure you can completely reproduce it in darktable. All I did was to use a proper DCP to prevent blue issues (well, not that proper, since it was for an X-T1 not an X-T2), a tone curve to match the image to the embedded JPEG’s tones, and some noise reduction and edge sharpening.

[anarcat]

@Morgan_Hardwood

However this thread is more about the difficulty of preserving colors and matching them to what your camera shows without getting out-of-gamut blue artifacts, so that is what the following images achieve.

I see two main things in this thread:

1. colors are radically different on the bridge (and only on the bridge) between the OOC JPEG and RAW rendering engines, regardless which one (e.g. LR, DT, RT all put the bridge blue unless some extra color mapping is applied)
2. up close, there are significant artifacts on the bridge trusses when rendering from RAW (with DT and RT, LR seems to fare better here) when compared with the OOC JPEG.

As I understand it (after reading up on samples clipping), this might be due to out-of-gamut but also possible channel-specific overexposure on the bridge. Indeed, messing with highlights reconstruction does improve the detail on those trusses on the bridge significantly, but it never quite matches the results from Lightroom or the OOC JPEG.

Now, I understand much better the issue of gamut: it’s not something I considered for this at first, and it totally makes sense that the camera would shift pixels one way while rendering engines would shift them another way, especially if there was film emulation enabled on the camera (or, as @houz suggested, “instagram filters” :). I understand this and it makes sense: this is special changes made to the color mapping and we can’t expect rendering engines to reproduce that exactly, especially out of the box. So my immediate surprise at the difference of rendering at the color level is passed now and, well, I accept that the bridge may actually be blue (still an open question, btw - I haven’t found someone who could answer this definitely).

What concerns me more at this point is the difference in detail. There is precious data from the sensor, and it seems we (free software RAW rendering tools) are losing some of it, while our proprietary equivalent fare better. Is there something we’re missing in the algorithms to render this? Why can LR render those trusses without clipping?

Again, to compare, the OOC JPEG:

Darktable, linear Rec709:

Lightroom, out of the box:

And, for completeness, @heckflosse’s try with RawTherapee:

Now of course the colors are completely different in the four images: I understand better why, that makes sense. What I can’t wrap my head around is why the details are so different on the bridge truss. In the OOC JPEG and the LR rendering, I feel I could keep going and zoom another crop and still keep detail. In DT and RT, I feel I’ve already lost and we see a lot of grain on the trusses. I have tried to mess around with highlight reconstruction, but I couldn’t quite get the same result: I mostly end up with a washed out, blurry picture. Nothing as sharp as the original.

Now, I am very grateful for all the answers. The level of technical and artistic knowledge here is impressive and humbling, and I can only thank you again and again for all your efforts. I did feel it would be useful to reframe the question, since we have pretty much cleared the field of the color (blue/magenta) problem, I think.

So if people want to pursue the conversation here little further, I’d be very curious to hear what people think of the detail problem next.

PS: is this something that should be in “play raw” next time I have a trick question like that?

[anarcat]

@Morgan_Hardwood

If you care at all about color accuracy you should always use an input profile which matches your camera model.

Well sure, but how do I figure that out? Is that data embedded in the RAW? Could/should DT/RT figure that stuff out automatically?

[houz]

About the broken blue colors, all those default color matrice are fit to give nice results for typical colors in an image. At the border of the gamut those quickly go bonkers. The only real way around that is using a LUT profile for your camera. You can make one yourself if you have a color target and are careful, otherwise you will introduce other problems into your images. Or you can try to check if the DCP @Morgan_Hardwood linked is using a LUT and then try to convert it to an ICC profile (is that possible?).

About the lack of sharpness, it might be that Lr applies more default sharpening to the images than darktable does. You should also make sure to look at images at 100% zoom. Otherwise you are just comparing the fast display scaling and not the image processing.

[afre (Alan)]

This is from ACR (basically LR) using Adobe’s standard matrix profile but with everything turned off as possible. Compare that with RT neutral and dt’s equivalent. Cropped, 100% zoom:

[ggbutcher (Glenn Butcher)]

+1 for a calibrated camera profile. Once I made one for my D7000, my input images looked a lot better. The only expenditure needed was for a color chart; most will recommend a IT8, but I got decent results using a 24-patch ColorChecker.

With regard to ‘sharp’, I think the degradation being seen here is also due to the color gamut mismatch; the things that are running together are shades of blue, and they’re being clipped to the max blue of the profile, thus destroying those shades as detail… ??

[paperdigits (Mica)]

We have a few Wolf Faust targets for the community to use!

[nosle]

It does look to me as the ooc jpeg is more likely to be wrong colour wise. There’s some quite odd toning from blue to purple going on with those trusses. To make that happen you would need a very complex lighting setup.

It looks more like the highlights (areas that recive a lot of light) are the ones turning purple. Whereas further away , or in shadow from the coloured lights, the trusses are blue. So my guess is that the in camera processing is going out of gamut (or just blue channel clipping) and not coping very well.

I also not so sure about the detail you find lacking. Perhaps an ever more narrow crop to show it? What I can see is that there is more apparent sharpness in the ooc jpeg. This sharpness is as far as I can make out due to more contrast not actual pixel detail. The ooc jpeg also look better because it appears more as smooth planes of colour that meet. This I think has a lot to do with Fuji processing. I’ve looked a fair bit at fuji files and always find they look almost vector based at 200%. This to me suggests some rather heavy processing in camera. The images look great zoomed out a bit so it’s not a criticism of the files but it’s a rather specific look zoomed in.

So what i’m saying is your camera is wrong Joking aside I’ve also hunted for better in camera approximations of my Pentax files as they really are a great starting point. You do however throw away a fair bit of data with those ooc settings. In my case I loose lots of highlights.

[ggbutcher (Glenn Butcher)]

Oh!

The only reason I didn’t order one from coloraid.de was that I hate PayPal. May have to take you up on that…