I’ve been using RT regularly for about 8 months - so a newbie. I’m using the latest stable dev version - on linux Suse with an Argyll calibrated monitor.
I have a Panasonic G90 and a GX9. The poor man’s Olympus - in the days when photographs were real, printed on paper from negatives, I had an Olympus and figured if they use micro 4/3 then it can’t be all bad. The GX9 is for travelling and wandering the streets - with a 20mm lens it’s invisible under a coat.
In terms of sensor, processing, they are the same beast. The difference is in access to controls and handling.
Here’s the problem - and the must read solution for Panasonic users at the end.
For all that time I’ve been battling with nearly every image (from what I’ve said above - from both cameras) having a distinct magenta cast. Reading Rawpedia I was told that I shouldn’t need to touch the white balance and should use colour toning to rectify it, which I obediently tried to do.
I also set about making my own double illuminant profile using Dcamprof. This had a slight mitigating effect. But by no means enough.
I then started looking at EXIF data and discovered that RT was systematically around 250°K out - so I did start playing with white balance - including playing with the red (magenta - I do wish people were specific about colour names)-green axis.
Finally confronted with a particularly egregious set of magenta images and looking at one of the new histograms in the dev version, I resorted to manipulating the black levels. I found I got mostly good results from setting R to +6 and B to +4 - didn’t always work but playing with it seems to have solved the problem. I now have just to work through 1500 images applying the solution…
However there is an easier solution (tried in desperation) : in the options in-camera there is a choice of colour space : either SRGB or AdobeRGB. SRGB is the default but I switched it to Adobe. In EXIF it changes from SRGB to uncalibrated. And suddenly RT works as it should… no more colour cast - just the colour temperature wrong.
So for Panasonic users using the AdobeRGB (uncalibrated) colour space is essential to work with RT
My questions are (1) What causes the different behaviour with the change in in-camera colour space?
and (2) Does this mean I have to redo my colour profile - which was done using in-camera SRGB?
It would be helpful if you posted a RT rendition that illustrates the problem, and the associated raw file.
In my experience, an overall “magenta” cast is indicative of a wrong black level. That’s usually given in the metadata, but sometimes RT will use their own depending on if the metadata value is deficient. Looking at RT’s camconst.json, for the G90 there is no black level specified:
No - It is as if someone had emptied a magenta wash over the image - but playing with black levels is my final solution - one of the histograms shows where each channel is “sitting” (like 3 ghosts side by side) and I found by messing around that bringing red and blue approximately in line with the green I have a solution.
But, as I said, switching the in-camera colour space to AdobeRBG is a much simpler way of solving the problem. What intrigues me is why it happens and is the raw file different in some way. If it is, that means redoing my .dcp (it seems to work correctly as long as the EXIF temperature is respected).
Also, I read camconst.json (without understanding most of it, but it’s where I got the idea of looking at black levels)) and there is mention of the G90 but it’s commented out. As I’ve said, from a processing point of view, the G90 and GX9 are identical twins (and possible the same as the G9)
Okay, post a discrepant rendition. And, post the raw file from which it was made.
Setting the camera to compel it to make it’s JPEGs AdobeRGB is not getting at the root cause, it just happens to do something that mitigates the problem. Knowing what the AdobeRGB profile is, I cannot imagine what that mitigation might be.
In the EXIF they call it “uncalibrated” rather than Adobe… All I know is than when I load a raw file now my three ghosts are lined up like the three monkeys - as they should be.
I’ll find an example and post it as is and how it should be plus the raw file - where do I post them to?
It may take some time, I’m on the move for a couple of days.
It could also help if you make a fully black shot (with the lenscap on) and a fully overexposed shot (set to f/5.6 or f/8.0, shutter speed around 1/10 s, point at clear blue sky or brightly, but uniformly lit wall). Such raw files can often be zipped quite well to much lower file sizes.
Thing is I get the problem with the GX9 as well - possibly less so.
As I’ve said the sensor and processing is the same for both cameras (and the sensor is the same as the G9, so the processing algorithm is likely the same for it as well). The difference between them all is the various bells and whistles in each package. It’s a good working hypothesis that what works for one will work for all.
Do they have the same CFA arrangement… There was an issue something like this a couple of years ago and the same model (not this model) of panasonic camera seemed to has 2 versions out there using a different color filter setup and it would yield this sort of magenta… I would have to go back and do some digging… Also there was a wb bump used to a weird number like 43 or something… I will search but this was with DT and how this data matched up with what it was using so maybe it would apply
The bad news is the camera won’t let me take a picture if it’s egregiously overexposed… I did get a setting where it said it was going to make a dark frame but haven’t yet found where it put it…
I don’t think I made this clear, let me do that now: the in-camera selected colorspace only affects the embedded JPEGs, it does not affect the raw data.
The camera value is definitely deficient, I get a light magenta cast in the final rendition to display profile with it. Libraw’s value works much better…
and the accompanying .RW2 file… and contemplating eternity as it uploads… And the bloody thing has failed to upload properly - “please try again” - not this evening
Hitherto I’ve been using RT 5.8 and only recently moved to the stable dev version. Clearly someting has been done about configuring RT for the GX9 as it seems to work better. I can’t be sure but I think there now is an orange cast to some of the images. I’m not on a calibrated screen now - here, RT is installed on chrome linux and I’m not sure if I dare try and make it play nicely with Argyll… But looking at the histogram blue is way down below red and green when I would expect it to hover in about the same place as the other two.
I may have tricked the camera into giving me a black and an overexposed image will report back
In the bottom-left pane is the subtract tool, subtracting the value 0.001953125, which is 128 converted to rawproc’s internal 0.0-1.0 floating point. Now, here’s the rendition with the libraw supplied black value of 143:
I downloaded black-GX9 and opened it in rawproc, same deal as for the G90. EXIF black level is 128 for all three channels, libraw black level is 144. Here’s a screenshot of the exif black level:
No, it shouldn’t. Weirdly enough, RT (dcraw) extracts the exif black levels first. The value of 15 in camconst.json is needed as an additive correction to that.
