I just upgraded darktable from 4.0 to 4.2.0 after it was released a few days ago, using the Fedora 37 RPM package from the default repository (the darktable-4.2.0-56.3.x86_64 package). I then tried to import my first batch of images since the upgrade, which are all Canon CR3 RAW files, and discovered that none of them appear in the dialog box. This the case for both “add to library” and “copy & import”. I can import DNG files, but not CR3. I’ve been using copy & import on CR3 files since darktable 3.8, so this is a new development. Interestingly, CR3 files do appear in all my existing collections, i.e. everything before two days ago, so apparently darktable can still process them. But I can’t import them. Trying a different approach, I can open up the new CR3 files in geeqie, but when I try to send a file from geeqie to darktable using the darktable plugin, it fails with “error loading file” from darktable. Am I missing something? Do I need add support for CR3 files to this package?
it is likely that fedora doesn’t buid exiv2 with ISOBMFF support turned on. You can try the flatpak or the OBS package, both of which have that enabled.
You should raise this issue to the fedora packages of darktable and exiv2.
Thanks! I tried the OBS package, which has the same issue: no CR3 import. But the flatpak package does work, although at the cost of losing all my saved styles and tags. Is there a trick to getting those into the new package?
Look in ~/.var/app/ for the flatpak settings. You can copy stuff from ~/.config/darktable
Thanks again. I’m back up and running.
seems we will have to restore the exiv2 package for fedora then. one would have hoped that fedora turned on isobmff support by now. @asn any idea why this didnt happen yet? the bug has been there for ages.
the problem should be fixed when switching to the exiv2 from the darktable obs projects. same applies to all deb based distributions.
The exiv2 should remove that warning. That’s the issue …
Respectfully, I don’t think a warning is the issue. Taking the warning down doesn’t make the issue go away, does it?
You have a big fat warning that there might be patents. With it you tell others, we know more than you.
I fully understand that a legel team argues that they can’t take that risk.
I suggest to e.g. watch legal talks from Andrew Tridgell (tridge).
Not “we”. The ISO/IEC 14496-12 specification itself does:
The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) draw attention to the fact that it is claimed that compliance with this document may involve the use of patents.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights
The holders of these patent rights have assured ISO and IEC that they are willing to negotiate licences under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statements of the holders of these patent rights are registered with ISO and IEC. Information may be obtained from the patent database available at www.iso.org/patents.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those in the patent database. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
So yes, the risk is passed on as there are no resources to actually check those and potentially indemnify users. Under those circumstances, not passing on that warning would actually be unfair and misleading, and most certainly wouldn’t make the issue “go away”.
Instead of just “not wanting to take that risk”, the Fedora Legal team could actually invest their resources into checking the applicability of those claims and help the community out.
Is the legal risk perceived to be there for jpegxl too?
What aspect of JPEG XL exactly?
As some JPEG XL files can be stored in an ISO BMFF container, they’re unfortunately in the same boat currently as CR3/HEIF/AVIF w.r.t. parsing by Exiv2 and the issues described above.
The IP situation of the actual JPEG XL codec is an entirely different matter and out of scope for Exiv2. I have not looked into it as I have not yet seen any formal warnings like above, just forum posts saying there might be some related patents out there, and contrary claims by the JPEG XL interest group claiming there is no encumbrance.
But, IANAL, and would really prefer that some legal expert eventually sorts this out for the community.
Jpegxl can use isobmff, so if that’s an issue for exiv2 then it must be an issue for jpegxl as well. I’ve never heard of an issue with jpegxl, so…
So ask them.
Again, the JPEG XL interest group has some resourceful backing. Exiv2 has none.
Can confirm I’m experiencing this on Debian 11.
I don’t need to. I don’t see in any way how there is a patent issue here. I never understood how any of the arguments of the exiv2 dev were valid. But you can see how it has effected things.
OP here. Since my original post I’ve achieved a better workaround by recompiling exiv2 with BMFF/CR3 support using the simple option in the first post in the link that darix shared:
https://bugzilla.redhat.com/show_bug.cgi?id=1979565
With the recompiled exiv2, the OBS package of darktable works fine.
That technique is specifically for RPM-based Linux distros, but I assume there must be something analogous for DEB-based distros too.
But I agree that the whole legal rigamarole around this is silly and annoying.
Of course it is. But when the only way to prove the invalidity of a patent is in court, and when that’s prohibitively expensive for many of the parties concerned, who wants to take the risk?
That is the problem, yes.
In Fedora, we try to build and ship only packages which we know (as far as we can know) not to create any legal challenges, at least in the US jurisdiction. That can be frustrating for users and packagers at times. But it is part of our definition of “free”, and it is why Fedora can be a baseline distro in certain areas.
That big warning that exiv2 put up can hardly be ignored. In particular, now that it is there: If we continued building exiv2 with ISOBMFF support we would do so being fully aware of these patent claims. That is riskier than it used to be.
For similar reasons, RedHat’s legal team will never say “yes it is patent encumbered” - that would be an invitation for the patent holder to go after prior uses of the code.
All we currently know is that we will not get an “OK” from RedHat’s legal team in the current state of affairs. We would need exiv2 to become part of a legal entity (KDE was under discussion) which takes on liabilities in case of patent issues.
Alternatively, if exiv2 could load format support as modules, we could easily have the missing module at rpmfusion so that it enhances the Fedora exiv2 for those users accepting the risk individually. I don’t think exiv2 supports this right now.