R5 Mark II RAW support - Almost a year later

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? :man_shrugging:

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.

5 Likes

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

3 Likes

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

1 Like

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.

:grimacing::grimacing::grimacing::upside_down_face::dizzy_face:

(I’ve never looked at the LibRaw source before)

3 Likes

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

2 Likes

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…?

1 Like

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 :wink:

1 Like

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.

2 Likes

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.

2 Likes

Leica, Ricoh(Pentax) and Pixii?

It’s a bit unfortunate that Ricoh didn’t enter the mirrorless market with anything besides the GR series.