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.
Yes, difficult also to to get serviced and repaired
I tend to be a bit lazy and get black and white prints done by laser on the old photographic paper by people like Harmans Labs from digital instead
My chemistry teacher used to say my work was more like cookery and I haven’t really improved as I use a different colour labs ICC profile with Harman Labs combined with one of the open source Ilford Delta simulations for monochrome prints
As you know Harmans now own Ilford film along with Kentmere who were the poor man’s Ilford
helpful stuff on Panasonic: thanks, I guess a lot more to explore on Adobe RGB
Might there be output issues with Adobe RGB
professional print labs I talk to seem to want a JPEG or Tiff with an SRGB ICC profile attached
@ggbutcher @Thanatomanic can you confirm that this is incorrect:
If a camera is not listed in this file the constants from dcraw will be
used. If listed here this information will override the constants in dcraw (if any).
and that this suggested fix is correct:
If a camera is not listed in this file the constants from dcraw will be
used. If listed here the values will be added to or replace those from dcraw, depending on how they are specified, as explained below
(it refers to this explanation: RawTherapee/rtengine/camconst.json at dev · Beep6581/RawTherapee · GitHub )
What happens when dcraw detects or does not detect black levels, but the raw file itself contains black levels in the metadata? What if the raw file is a DNG as opposed to NEF/CR2/ARW/etc?
Bear-of-little-brain here, how does a user know whether to specify a full black level value vs. an offset to dcraw? I don’t currently have RawTherapee up and running, so I can’t go looking for a UI indicator…