I’d surmise that as long as a raw format continues to use the same file organization with respect to the image data, that can be extracted with current logic. It seems to be the metadata that is tripping things up, and that becomes more important as other information is needed to process current raws, such as lens distortion data…
The thing is that CR3 has a (standard but documented) container format that was not in use when dcraw was last updated - ISOBMFF should be alien to any implementation of dcraw unless it’s a very hacked-up fork or libraw’s dcraw-emu
The biggest challenge of CR3 initially was that it had a (nonstandard and undocumented) codec used to store image data. In theory, once this hurdle was crossed, support for the rest should have been easy, but certain exiv2 developers have been highly unreasonable (citing fears of unspecified patents, even though the patent issues with MPEG-4 lie with the codecs and not the container formats, with AOM selecting ISOBMFF as the container format for AVIF being clear evidence there are no known patent concerns, even to organizations with piles of IP lawyers, for exiv2’s use case.)
1 Like
The current official dcraw is version 1.478 dated 2018.06.01
However, the package on my system (Arch Linux) is called version 9.28.0, last updated 2020-05-19. It claims to get dcraw from the official origin: Decoding raw digital photos in Linux
I do not understand the discrepancy.
1.478 is the “Revision”
9.28 is the DCRAW_VERSION
Revision is a RCS keyword, incremented by RCS as changes are committed. I’m guessing DCRAW_VERSION is what David Coffin wanted the rest of us to use…
1 Like
I am on Ubuntu 20.04.1. dcraw is v9.28
@Tim I believe that is a mirror.
Official development ended a long time ago. Dave may have added patches in the latter years but the more recent versions circulating have been modified and built by others. You may have 9.28s that are different from one another.
1 Like
Ok, maybe. All I know is what I can see. The revision info is from Dave’s site, and the Arch repository says it is pulled from that same site. If someone else is handling it now, I don’t know.
There is an infinite number of useful color axes. Well, nearly infinite. For example, think of Lab, with one lightness channel and two colour channels, and the choice of colour channels is fairly arbitrary. From an image encoded in Lab, we could convert to LCH, then rotate the hue, and convert back to Lab, so the axes would be different. We could have chosen to make one axis significant: a colour we want to desaturate or whatever. After tweaking, we have to convert to LCH, rotate the hue in the opposite direction, and convert to whatever colorspace we need for viewing.
I show an different example at Photo post / audio analogy - de-yellow night shot - #22 by snibgo, using simple 3x3 matrices to convert to/from sRGB, and one colour axis is from the hue of the cat’s fur.
1 Like