Canon CR3 raw support - your move

That’s a possibility but another is that Canon simply expects that developers will study their CR3 format and develop their own solutions. In which case, asking for an NDA from Canon is a unique request they’d be unlikely to grant. Do other camera manufacturers do this? I really don’t know. And how do the other FOSS groups implement CR3 without legal issues?

Not casting any blame here, just trying to understand

From what I understand there is no NDA spec. Every company has to develop their own solutions. I don’t see how there is any issue at all implementing CR3 from a legal standpoint and more so then every raw file format out there. There is open source software that can already convert CR3 the biggest hitch I have seen is metadata. Exiv2 does not want to implement it because patents if I follow correctly. There should be no issue here either because Robin said he could read all the metadata by just implementing the open spec of the container format.

I just don’t see any Camera company causing legal issues for people Reading Raw Files/ Metadata. It is within our rights as customers to be able to read that data. Now I would think it would be a different story if we were developing a camera and writing such files in a competing product.

1 Like

You’ve become far more skilled at it than I ever was!

I still get razzed to this day by my parents who had the misfortune of listening to me practice when I was in high school over 20 years ago.

2 Likes

I think that you might have the relationship between Canon and Adobe inverted.

I suspect Canon pay Adobe to support their formats in PhotoShop. It keeps several R&D people busy full-time at Canon to deal with Adobe, Microsoft, Google and Corel (and a few others). The cost is real and the business case to support Adobe is solid. Canon don’t want to expand that activity to cover open source projects which haven’t been historically important drivers of their business.

However the times are changing. Microsoft and others have embraced FOSS. Canon may in future open-source their code for everybody.

In the meanwhile, thanks to Laurent Clevey and the ISOBMFF/JP2000 Specification w15177, I don’t think we need help from Canon (or Apple) to read the metadata in CR3, HEIC, AVIF and JP2 files.

5 Likes

@clanmills, and to that point I have to wonder how it would serve Canon’s interest to battle FOSS developers in utilizing their new format. After all, the files are available to their camera customers and they ought to know that an impediment to software developers could mean lost sales. I for one, have a legacy Canon and my decision to upgrade would hinge on its compatibility with my editing software. Not just mirrorless, but any of Canon’s next gen cameras that use the DIGIC 8 processor. That’s a several lines of cameras cut off to users.

And good luck with your retirement. I’m too new to see all your efforts but I do appreciate your experience and contributions.

1 Like

Canon have shown no hostility. Quite the opposite. They have replied with courtesy to every email about this.

Let me define “hostility”. In the early 80s I worked for a CAD company. A user made an engineering drawing of the Star Ship Enterprise and sent to the Studio in Hollywood. The Studio showed their appreciation by getting their legal people to write to the user concerning their copyright.

It’s reasonable to ask the question “are you sure this is legal?”, I have received numerous private emails offering the opinion that this is legal. @paperdigits has invited the objectors on GitHub/exiv2 to explain their position. The person who objected most strongly has yet to reply.

6 Likes

To my knowledge, there is also nothing in the files themselves that hints that Canon wants to impede interoperability.

It’s nothing like the Nikon NEF metadata encryption fiasco which had no legitimate reason for being implemented other than Nikon wanting to reserve the right to be able to sue people who provided alternative unlicensed software (this was right around when open source demosaicing approaches like dcraw were routinely outperforming vendor implementations). Nikon never did actually sue anyone, but in that case there was actually a clear DMCA issue and it is why I didn’t consider them at all back when I bought my first DSLR so many years ago. To my knowledge there has not been any breaking of encryption involved with CR3, so there isn’t a DMCA issue here.

So I read through that issue/pull request in exiv2:

Can any of those objectors point to a specific patent on metadata handling that is applicable?

Yes, parts of the MPEG standards are patented - but MOST of those patents are on the video codecs themselves. People do mention AOM - and I believe AOM is NOT pushing an alternative container format to escape patents, only an alternative codec. In fact, everything I can see is that AVIF uses the ISO container format, indicating pretty clearly that there are no patent concerns on the container.

Heck it’s pretty clear that the current issues surrounding CR3 support have nothing whatosever to do with Canon themselves, but fears of MPEG-LA?

Edit: Please add support for ISO/IEC 23008-12:2017 HEIF file format · Issue #318 · Exiv2/exiv2 · GitHub is pretty disappointing behavior given that he just dismisses the previous discussion as “bikeshedding” without indicating what exactly his concern is, such as pointing to a specific patent that he considers problematic.

2 Likes

Hasn’t happened yet, that’s why it is frustrating.

The new Digikam 7.1 release contains an implementation for reading CR3 metadata based on Libraw. See below, emphasis added by me. They also make it unabashedly clear that Exiv2 is lacking in some regards :thinking:

The CR3 file format is a complex proprietary container based on ISO/IEC base media file format. In digiKam, historically we have used the Exiv2 library to deal with file metadata, but this library is not yet able to extract information from CR3 images. So we needed to use an alternative, and by chance, libraw provides mechanisms to handle property tags from a client application.

For digiKam 7.1.0, we have written a metadata interface based on libraw for the CR3, and the application is now able to read a large portion of Exif tags, including GPS information, color profile, and, of course. standard IPTC and XMP containers. CR3 Metadata changes are only supported through XMP sidecar, as no write support is possible with this format.

Although the new libraw based interface is less powerful than Exiv2 (which permits a lot of operations on tags), by using libraw. digiKAm can be better compatible today with CR3. Moreever, the interface is not only compatible with CR3 files, but with all RAW files supported by libraw. Other RAW files not yet supported by Exiv2 are de facto supported, sich as Sigma X3F, Panasonix RW2, or Leica RWL for example.

2 Likes

Just calling it bikeshedding wasn’t very tactful indeed, however I think I agree on the sentiment behind it:
Whether right or wrong (from a laymans person looking at the presented arguments: wrong), some relevant people/organisations have reservations using this. Thus it has been proposed to add a build flag to disable those parts, and nobody disagreed with that. So basically there’s a way forward to add this functionality to which as far as I see no one has objected. So any further discussion on whether or not patents are a factor seem like wasted time. The implementation is supposedly there, so a productive next step would be to PR that functionality including such a build flag.

1 Like

I haven’t seen the term bikeshedding much, so I took a look at the definition.

1 Futile investment of time and energy in discussion of marginal technical issues.
2 Procrastination.

See also
1 yak shaving
2 when you’re up to your neck in alligators, it’s hard to remember that your initial objective was to drain the swamp

:joy_cat:

4 Likes

Entire careers are spent doing that, particularly in the engineering community. I now know there’s a term for it.

2 Likes

Ifdefing a major component of the code can sometimes have negative impacts on the architecture and design of the code if the ifdefs affect many files (which sounds like it was the case for at least one attempt at ISOBMFF support).

I remember one case back when I was involved in Android platform development where ifdefing Qualcomm CodeAurora-based support (extra codecs, GPU optimizations that required Qualcomm GPU blobs instead of Google Nexus/Pixel blobs) became such a hassle that we just started maintaining two separate repositories for frameworks/native - one for CAF devices and one for non-CAF devices. It was easier to apply a patch to both repositories than to spend 1-2 months every new Android release trying to ifdef all of the changes Qualcomm made AND track down all the bugs from botched ifdefs.

1 Like

For that in french, we have a much stronger and crude expression that can be translated by “assfuck the flies”. Management meetings are also a good place for this activity.

1 Like

The other maintainer has objected, he has said “patents!” And “that’s not the way patents work” and that’s more or less it. The maintainer who is OK but wants a build flag has stood by this inaction.

Note that Gilles from digiKam already wrote the code for this and made a PR, but it was rejected and that’s why there is a libraw interface for this now in the latest digiKam release.

At this point Exiv2 is blocking probably the largest three apps that are using it; Shotwell, Darktable and Digikam (idk of others but them too). That translates to thousands upon thousands of users.

Someone should make a fork of Exiv2 with ISOBMFF support and pull in the changes from upstream before every Darktable release. That way Dan and Jens can continue blocking this issue and ignoring their users for 20 years (or however long it takes for any patents that they are imagining to expire) if they want to.

1 Like

A fork sounds a bit extreme for something like this. Is it possible to just apply a patch that adds the support at build time? Similar to how other libraries need tweaks due to issues upstream?

That would require vendoring the external dependency (aka including it into the project source) or for maintainers of every distro to patch their version of exiv2. Forking doesn’t sound more extreme than the maintainers blocking the feature.

1 Like

Honestly, anyone that isn’t personally considering maintaining exiv2 should just stop talking about forking right now. This is so widely inappropriate on so many levels. If you don’t know why, you probably never maintained an open source project, which again means stop talking about forking.

Now about “blocking the feature”:
D4N originally brought up the patent issues as far as I can see. At the same time he did do in-depth review on a PR adding optional support. That’s hardly what I call “blocking the feature”. The latest PR didn’t move forward because of differences between Gilles and Robin: New pull request about to integrate HEIF support (read only) using system based libheif by cgilles · Pull Request #1233 · Exiv2/exiv2 · GitHub
I see no indication anywhere that a clean PR with an option to opt-out would be rejected. Please point me to it if I am missing something.