I remember writing Canon support about this issue when the DT developers were wrestling with how to incorporate the CR3 format, and they responded that they expect the individual software developers to examine the new format and come up with their own solutions. I would have thought that Canon would be forward leaning in getting their new cameras supported ASAP. But what do I know about these things? ![]()
I wrote Nikon about getting a spec for lens correction for the Z mount and they said âget the SDKâ I asked if the information was in there and they said they didnât know. Their SDK is behind an NDA so thatâs a no-go. I have no idea what secret sauce is inside the raw file, my gut tells me nothing. What do I know though.
If you have the nerve you can follow the steps in my blog post for any canon release. If they donât change the format again it is pretty âstraight forwardâ: Adding new camera support in darktable / LibRaw / ExifTool â Pandas Welt
I agree Canon should support open source projects. They claim Adobe doesnât pay for access. Adobe literally has it ready if not on day one then within a week or two.
By not supporting darktable like projects they are supporting Adobe and other big software houses by default.
Darktable has to work on their own or in collaboration with other open source projects to produce their own RAW file decode group.
How about Adobe cooperating with them? It would not take anything away from them.
Ok, maybe a stupid question. What directory are the files located? You do not mention it. I tried awhile ago to find them without success.
On a somewhat related note - last time I was considering if to go to Canon or Sony systems I learned that Cannon forbade creating third-party lenses for their cameras. It made for me easier to choose Sony.
Which files? Ah I think I understand. Will add the whole path tomorrow
Iâm considering replicating this just to understand what youâve done with the R5II, and then if I decide to go forward with an R7II (if and when itâs released) then Iâll know what to do.
Would it make sense - and is it legal - to make self modified LibRaw files available to others who need R5II or other camera support?
At least in their email to me they claim that Adobe and the others are on their own to adopt the Canon standards. But maybe Adobe has early access and an engineering staff locked and loaded to do the work.
But I said it before, itâs just nuts to me that a camera company with stiff competition isnât doing everything possible to adopt their formats as early as possible. And not just FOSS. It really seems as though that position is against their own self interest.
Yes, LibRaw is LGPL or CDDL.
Interestingly enough, LibRaw uses RawSpeed (the decoder for darktable) and rawspeed uses libraw.
From the LibRaw repo:
Unfortunately, the RawSpeed-v3 source code is constantly changing and this is due not so much to the development of the library (support for new cameras, formats, etc.), but to the fact that the current maintainer is using it as an aid in self-development as a programmer.
They are extremely reluctant to accept 3rd-party patches to this library, therefore, the fixes necessary for correct work with LibRaw have been added to the LibRaw distribution (see below). All our patches, of course, are suitable only for a specific version (commit-id) of RawSpeed-v3, if you want to use a different version, you will have to adjust them.
![]()
![]()
![]()
![]()
![]()
(Iâve never looked at the LibRaw source before)
simply fork GitHub - LibRaw/LibRaw: LibRaw is a library for reading RAW files from digital cameras and then just add the changes in a similar way as itâs done in this commit: add R1 and R5mII support ¡ LibRaw/LibRaw@200936f ¡ GitHub
maybe they just want prevent anybody to be able to see the internal capabilities they doesnât use in their current camera line but will be able to do later⌠thatâs how protection of intellectual property works in reality.
Then⌠Donât write that information into the raw fileâŚ?
I get that, but you canât have it both ways. Itâs no good to have a camera that no software can support, unless Canon expects everyone to use their proprietary DPP. So if Canon expects the software makers to do their own research, then why not provide the release notes to help with the effort? At the end of the day its in Canonâs best interest to have their camera models fully supported.
they just write into the raw file, what they need to do for the current raw files - even the specification might be more capable. There wasnât any reason to write raw burst stuff into the cr3 files of the first M or R cameras that used cr3 âŚ
you canât reverse engineer stuff you donât have a clue about its possibility
itâs not just the developers of raw processors, but also engineers from sony, nikon, etc.pp. who might get inspired ![]()
At any rate, not having open docs for the minimum necessary things to decode a raw file that one already has and paid for is stupid, and we should all certainly let manufacturers know that.
Is it just Canon that does this, or is it a industry wide practice?
All of them do it, except those cameras that produce DNGs natively. Nikon and Fuji for sure both do it, but they havenât changed their format recently, so adding new flavors of their raw files for new cameras generally just requires a sample.
CR2 â CR3 was a whole new thing, needs new reverse engineering.
Leica, Ricoh(Pentax) and Pixii?
Itâs a bit unfortunate that Ricoh didnât enter the mirrorless market with anything besides the GR series.