RawTherapee 5.9 - CR3 Exif support

Hello, I’m trying v5.9 and I see there is still no exif data from CR3 files (R5 in my case).
I installed 5.9 over 5.8 to keep settings and color profiles.
Could this be the cause of the issue or CR3 Exif support is just not supported?

What OS are you using?

Win7 64

@bluc Yes, this is still an outstanding issue: CR3 metadata decoding support · Issue #6248 · Beep6581/RawTherapee · GitHub

1 Like

@cezio_ceziarelli that is quite rude. If you’d like to report actually issues, please do, otherwise keep your complaints to yourself or find a piece of software that works for you and use that.

Thank you, Roel.
I read your link, for what I can understand.

I guess, the problem is on your side. The software has been tested by a lot of users and behaves very stable for all of them.
Pls report what system you are using and whats the problem, how to make it occur, error messages a.s.o.

Martin,
Win7 64. Everything is working fine except for exif data that are not recognized at all.
RAWs from 5D4, 7D and even 300D’s CRWs have their exif data. R5 not.

I will try on a Win11 laptop, to see if the issue is related to this PC.

From what i read it’s not system related , the functionality is just not there.

Or maybe it requires a certain exiv2 version to work and your build was made with an older version ?

It requires at least exiv2 v0.27.5 with ISOBMFF support enabled and the metadata reader in RT must now look in the right place in the metadata

The ticket seems to talk about an outdated branch in rawtherapee, not yet merged. And an update to make that branch current again, which is not yet done and is in a fork without a PR it seems …

Have no experience with it myself , just looking at the issue what’s the status

Exif data from CR3 files don’t working even on Win11 Pro, so I suppose it’s not a bug but a normal behaviour.

Maybe a weird question - and not trying to be ‘victim blaming’ - but why did you expect it to work ? Is it in the release notes ? Because AFAIK , CR3 support and specially the metadata has been a hot topic the last year or ao.

If you are asking this to me, the answer is: because ART is working fine on CR3 since a long time and I supposed a new release should have had this function working.

I tried to make the outdated metadata-exiv2 branch current in July 2022. It is that attempt that is recorded in the most recent posts here: CR3 metadata decoding support · Issue #6248 · Beep6581/RawTherapee · GitHub in the issue report pointed out by @Thanatomanic.

No PR was ever created, because there is an issue with the original code in the metadata-exiv2 branch. The issue is, as I see it, that even if CR3 metadata is visible using metadata-exiv2 branch (this works!), or a current version of it, the output from RT does not contain any embedded color profile at all. This issue was also confirmed by other tests done by @jhmnieuwenhuis.

The discussion is here: CR3 metadata decoding test of feature branch on Linux.

It is correct as stated by @paperdigits that metadata-exiv2 branch requires exiv2 v0.27.5 from GitHub - Exiv2/exiv2: Image metadata library and tools built using -DEXIV2_ENABLE_BMFF=On, to work.

I was able to resolve merge conflicts in outdated metadata-exiv2 branch. That was not hard, but I was not able to fix the issue of metadata-exiv2 branch code producing RT output files (TIFF, JPG) without any color profile embedded.

I am not in a position to give strong advice how to best proceed:

  1. Make metadata-exiv2 branch current again + fix missing embedded color profile in output

  2. Start from scratch again.

They decided to ifdef that despite no one being able to actually point to a relevant applicable patent?

Disappointing, but likely explains why pyexiv2 chokes on CR3 files (since pyexiv2 appears not to automatically use system exiv2 libraries, but a manually-copied version of the library at build time…)

At least for a while, even after RT includes exiv2 support, this may be a problem on some OSes, distributions.

This is where the flatpak shines.

Probably ignorant on my part , but what has the output file from RT and the chosen output profile to do with the library used for reading metadata ?

The output section should not have been touched , right ? And if it’s a bug in that version of exiv2, all the programs using it should have the same issue.

I agree, this is a regression error. It is not related to reading metadata. The feature branch using exiv2 lib for metadata is quite a large rewrite of RT and somehow another error sneaked in.

Because tagging the file with the profile requires writing metadata, and I am guessing this is the step that got broken - since the description of the problem is not that the wrong profile is written, but no profile is written.