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…
1 Like
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
2 Likes
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
1 Like
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…
1 Like
And while you digress, I’m celebrating having my camera back (or at least it seems that way)!
…geeks…
3 Likes
Excellent! A dependency on zlib is no problem, I just dislike the Adobe DNG SDK dependency that used to exist
1 Like
I’ve got one of the original poor man’s cameras the canonet ql17 which was the poor man’s Leica, using Olympus om analogue lenses on a Panasonic gives a camera with similar functionality and I guess the original Olympus OM1 is now the poor man’s Olympus OM1
Hey @ggbutcher yes, the camconst comment gets tweaked over time but its still bloaty and unclear. Could you point to or quote the part in question, or even better open a PR with a fix?
This line is misleading:
36: used. If listed here this information will override the constants in dcraw (if any).
https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/camconst.json#L36
I have this camera as well and used to love making photos with it. I thought recently I should run a roll through it, but film prices are horrific.