I need some help for processing a RAW image to get a similar result as my camera (Sony Alpha 7 IV) does for JPG. When I open the RAW file to lighten up the bottom, I do not get the orange color of the raising sun - it is pink in the RAW file! Any ideas?
I shoot RAW+JPG simultaneously. The camera’s original JPG looks like this:
Without doing anything or checking or downloading…there can be many things that affect the color. If you have rgb colorbalance used it now uses a perceptual color space which spreads color a bit more… in the module’s mask tab you can switch to JzAzBz and it might appear a bit more contrasted and compressed like your jpg… many other things could affect it…
With DT using scene referred modules and not applying much in the way of adjustments out of the gate you will rarely get something really close to your jpg without some work and experimentation setting up color in DT
If trying to match the sky to the jpg was the goal I tried a couple of quick ones with and without the foreground lightened… I used Tone Eq…the OP used a couple of exposure instances which likely played into the result with filmic… Probably don’t need filmic for this one even…
I think this is the right sidecar. The two edits above are just +/- the tone eq to be the same… If I did more edits and this is not a match you can load the jpg as a sidecar to get the edit from it…
@priort did a better job I think. Porblem was that the part was too exposed or eventually only the yellow wasn’t inside the color-space. Dunno I’m not an expert. I tried it also with filmic “hightlich reconstruction” and a bit of tone equalizer.
I went to v5 and chroma no. I find for these things that v6 is trying to make you do things with color to make the math correct and its good but sometimes with a sky people want the bold orange and yellows often called rat piss…in any case you could get it fiddling around with v6 and some other edits but with v5 and manipulating the latitude and the midtone saturation slider you can bump these skies in a way which is similar to what the jpg is certainly doing…
I think someone should check the white point first. I’m not near my PC to check it, but i think some of the Sony files get the wrong white point assigned in DT. I think there is an issue/PR in rawspeed around it.
If you are asking the OP just load his edited JPG as a sidecar…you will get it… its really just default filmic with some exposure bump and not much more and it starts to go the colors noted… Its at least in part DT’s efforts not to give the rat piss yellow and how the perceputal color space maps things out…Basically open the image and add filmic and bump the exposure a bit… I don’t think he modified the curve or took any other steps…
But where did you (or rather dt) get that value for the white level?
16383 == 2^14 - 1, so the largest integer value that can be stored in 14 bits. As it is an integer field, in principle all values are valid. It looks to me when dt cannot read a value from the image metadata, it silently uses the maximum possible value for the bit depth of the raw…
And yes, if it happens, it happens for all images from that camera body. I use a Sony, and it has the same issue (solution: auto-applied preset…).
Like I said, in the particular image from this thread, it doesn’t matter, as all pixels are below the lower of the two values. If it does happen (in other images) an indication is a magenta zone that’s not recognised as clipped (and doesn’t react to the highlight reconstruction module)
@priort i think someone else has posted about this issue already. I think Sony decided to claim the white point to be the full range of 14bits, even if the camera is not using it. The makernotes seems to be the accurate value to use. The issue needs to be fixed in rawspeed for it to look at makernotes for these cameras.
Thanks for the explanation and update on rawspeed… The first time I checked the white level using xnview to review the meta data I had not scrolled far enough down so I only saw the initial value ie the one DT is using until updated and I hadn’t reached the data in the maker notes…I think with this issue noticed by the OP its just a byproduct of the channel values and not really a highlights thing… Looking at the histogram… things will be exaggerated when you start to mess with color and exposure… I think when you open this image in DT with default v6 filmic and bump the exposure a bit you get what the OP was commenting on… Its easy enough to adjust if you know the tools but for a new user I guess they could initially be taken aback by the sudden magenta appearance…
EDIT…
Is this just a visual thing on the histogram or am I too asleep this morning to figure this out?? I have disabled basically everything here and just raising exposure seems like it boosts the channels in a way that is not proportional and they seem to have different clipping points on the graph?? As I said likely just some artifact of the graph or my slow brain this morning…
If you note above it the screen shot I posted that is teh meta data for that file …just in the exif section of the data and DT used that… The values you provided come from the maker notes section and as you point out seem to make more sense… I think there is some sort of fix in the dev branch of rawspeed so it should filter soon to DT…
@Thomas_Do I’m also running darktable 4.0.1 on linux. Your clouds are not as pink as mine, but the natural yellow-orange color of the sunrise, as also seen in the JPG, is no longer present.
I think @priort gets the best results with natural yellow-orange clouds. The clouds in @wapitifass , @dqpcoxeas and @kakashy versions are still a little pink and miss the yellow-orange color.
Colors seems to be good if I disable filmic rgb module! For what should I use this module or is it doing some things wrong with highlights?
I also can confirm the white level from exiftool is different to that shown in darktable with 16383.
