Libraw for this camera provides a black level of 143. The metadata contains this:
[EXIF] BlackLevelRed: 129
[EXIF] BlackLevelGreen: 128
[EXIF] BlackLevelBlue: 129
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…
OK. one pink image
and after R +6 And B +4 in black levels (with a few tiny tweaks)
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
Ok, right thread…
Yep, that first image looks like it was inflicted with the EXIF black point.
With the raw you uploaded, here’s its rendition with the EXIF black point:
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:
The black level for the G90 in camconst.json should be 143.
Black files for G90 and GX9 :
black-G90.zip (9.3 MB)
black-GX9.zip (12.5 MB)
Raw file that should have accompanied earlier post :
PMAX0687.RW2 (23.1 MB)
White files to follow when skies are blue…
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:
and the libraw 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.
I just re-read the camconst.json comments, and I can’t really divine such from it. This is poor semantics…
Without a doubt… I was very surprised. But dcraw’s often works in mysterious ways.
Okay, I guess if you’re going to use dcraw code you’ve gotta find a way to live with the subtraction it’s going to do for you, hard-coded. However, IMHO camconst.json could use better semantics to express the difference between a delta value and a replacement value…
I copied the new camconst.json to sit with my options file and it seems to work! (Bearing in mind the limitations of the equipment I’ve got to hand)
There’s supposed to be sun tomorrow, so you’ll have the white files… anything else required?
This sort of thing is why I definitely want to look into libraw - but apparently libraw doesn’t support float32 DNGs?
I don’t know if @agriggio 's patchset in ART sacrificed that, or left a fallback for that. (I haven’t had time to dig into the patchset in detail)
Of course it does, you just access the pixels form a different member (float_image): Data Structures and Constants | LibRaw
Support HDR DNG images from HDRMerge · Issue #39 · LibRaw/LibRaw · GitHub indicates that this is only available if libraw is compiled against the Adobe DNG SDK
Perhaps for some compressed cases (floating point predictor?), I doubt the uncompressed one requires the DNG SDK… It’s been a while, the answer is in the LibRaw source code of course…
Hmm, so it seems the situation has at least somewhat improved. That’s good to know, most of the references I found were not looking promising initially, and that particular issue discussion had strong WONTFIX undertones to it.
As a side note, it’s kind of disappointing that the state of compression options in DNG without doing something non-standardized has kind of stagnated. Unless you are Bayer-mosaiced you’re basically limited to 8-bit lossy JPEG. I’m curious what feeding the lj92 predictors into a more modern entropy coder (such as the underlying ones used by zstd) would result in performance-wise.
Indeed, I can’t see dependence on DNG SDK any longer for floats, only on zlib of course.
But we digress…
And while you digress, I’m celebrating having my camera back (or at least it seems that way)!
…geeks…
Excellent! A dependency on zlib is no problem, I just dislike the Adobe DNG SDK dependency that used to exist
