After some unsatisfying times with my RX100 III i got myself an update with the LX100 II to go with me on my fishing trips. First pictures are great and i am really impressed by that small camera.
BUT there is one thing i cant get right so far and that is any red color in my pictures. While Panasonics JPEG engine delivers crisp and colorful images with rich reds i fail to reproduce these out of the raws. Whitebalance sometimes is an issue too and while sooc jpegs are a bit magenta, DT ends up with a greenish tintâŠ
So iÂŽm hoping to get some useful tips by other panasonic users that develop with darktable or just in general other users, that are able to get similar results to the jpeg.
I am foremost interested in the red colors but would be happy to get some guidance to reproduce panasonics jpeg rendition as a raw in general.
I attached the Raw, Panasonics Jpeg an my developed DT Jpeg.
EDIT: Take a specific look on the areas around the gill and the pupil. The sooc jpeg shows a red ring in the pupil that i cant reproduce.
Maybe something like this?
The camera seems to bump up the color a lot. I think it gives a good look in this case, specially in the out of focus pole, it looks very âchrome-yâ.
Great shot!
Factory default of what? darktable? Because there the default behaviour should be reading the white balance from the camera (which you can also request by switching to as shot in camera, and should also be able to trigger by resetting the module). You may want to raise a bug if darktable does not behave that way. D (daylight) does not mean âstandard daylightâ (e.g. at noon, with a cloudless sky), itâs just a type of illuminant. When you set as shot in camera (2nd screenshot), you can see that it displayed invalid (which simply means that the illuminant is not close to D - daylight or Planckian black body:
When the CCT is followed by â(daylight)â, this means that the current illuminant is close to an ideal daylight spectrum ± 0.5 %, and the CCT figure is therefore meaningful. In this case, you are advised to use the âD (daylight)â illuminant.
When the CCT is followed by â(black body)â, this means that the current illuminant is close to an ideal black body (Planckian) spectrum ± 0.5 %, and the CCT figure is therfore meaningful. In this case, you are advised to use the âPlanckian (black body)â illuminant.
When the CCT is followed by â(invalid)â, this means that the CCT figure is meaningless and wrong, because we are too far from either a daylight or a black body light spectrum. In this case, you are advised to use the custom illuminant. The chromatic adaptation will still perform as expected (see the note below), so the â(invalid)â tag only means that the current illuminant color is not accurately tied to the displayed CCT. This tag is nothing to be concerned about â it is merely there to tell you to stay away from the daylight and planckian illuminants because they will not behave as you might expect.
So, if by default it always comes up for you as âdaylightâ, but switching to as shot in camera fixes your colour, you should file a bug report, and attach an image that produces that effect. But before you do that, make sure you donât have a forgotten, auto-applied preset for color calibration that forces the wrong value.
Sometimes, very rarely though, I also get weird colours; resetting the module fixes that.
Thanks for your remarks and correction. I did not consider that the ârealâ default is chromatic adaptation: legacy (I wonder why). I should have written âdefault of CCâ. Iâve just done a little complete reset to see what the actual behavior is.
Its funny though as @kofa says every so often it misfires out of the gate and resetting it is all it needsâŠnot sure if its camera specific or what the reason isâŠjust a misfire on the pipeline but it can happen so it never hurts to check in case it is offâŠ
Sure, reset or reboot is often a solution. In my case I just didnât correctly remember or misinterpreted the default settings since Iâve never used them (or rather some minutes). For me, D (daylight) is still considerably inferior to as shot in camera, albeit not automatically applied to all photos, so I will stick with my custom preset.
As Kofa said there is no daylight setting only illuminants that a considered valid daylight so a range will be called thisâŠIt should read the camera data and really present as shot by âdefaultâ and as long as your reference values for D65 are good it should be a virtual match for legacy as shot âŠ
I think that what happens is that darktable reads the camera white balance values, finds that they are âclose enoughâ to a D (daylight) illuminant, and switches to that to provide a simpler editor interface (with just the colour temperature). Maybe the check is too relaxed. You can switch to as shot in camera, but then you cannot edit it; alternatively, you can switch to custom, which allows you to edit the illuminant in detail.
If that fixes the problem, I think you should share the values with the developers.
@anon41087856, what do you think? There is, indeed, a rather large shift when switching between as shot in camera and resetting to module (which causes it to switch to daylight):
Yes. I prefer adding some warmness to sunny daylight photos, so I had to look for a solution for this. I ended up using color balance rgb, and I think it does an excellent job while giving me even way more control than a simple temperature slider. Iâve never needed any other edit on WB - of course as long as the camera gets its correct WB.
No. Since I got used to the modern stuff and found my workflow as written above, Iâve never felt to need it. Also Iâm experiencing this with different cameras from different manufacturers (sometimes more or less, depending on the photos), so I have not considered a camera profile problem.
I also want to say that there isnât really a problem for me personally. Iâm pretty happy with my âas shotâ stuff and I think the results are great. Iâve never got that authentic colors in any commercial raw processor (Iâve propably tested them all).
if illuminant chromaticity has delta E < 0.005 with blackbody or daylight locus, use the correlated color temperature with the blackbody or daylight model
But there is another problem. The daylight model stops at 4000 K (daylight is not defined below), so we use the black body model below 4000 K no matter what. When you are sitting straight at the boundary between boths models, a small change in CCT can result in a switch between models and therefore in a large visual change.
You can force the use of âcustomâ illuminant anytime, which lets you input direct chromaticity coordinates that will not be further interpreted and donât rely on any intermediate assumption. The âas shot in cameraâ option uses direct chromaticity as well.
Thanks for the explanation. However, the problem mentioned above (with the dog pictures) is that the module does not start in as shot in camera mode; at least, it switches to Daylight for those pictures that are âclose enoughâ. As you can see, sometimes that needs manual intervention (by switching back to as shot in camera or by switching to custom). Wouldnât it make sense to stay in as shot in camera until the user manually switches to some other mode?
The point of defaulting to CCT is to allow quick and easy WB settings when possible. I think there are more cases where it works than edge cases like this one where it does not. In any case, controls are there because defaults are not expected to work all the timeâŠ
