Call for testing: RawTherapee metadata handling with Exiv2 (includes CR3 support)

Thanks @HIRAM , that worked. I agree with @nosle that this is a big step forward.

I was pleased to see that gps data that was in the xmp file but not in the raw file found its way into the exif data of the resultant jpeg.

Hi, yes I now can star-rate raws in Digikam and RT shows those stars (as in ART).

Question: what does ‘bidirectional’ mean here? If I change the star ratings in RT, that’s not reflected in Digikam (same with ART). If I do the same in Digikam - change star ratings - that’s not reflected in RT as far as I can see.

Rawtherapee creates a pp3 file, but does not write to the xmp file

Metadata synchronization with XMP sidecars does not work in bidirectional mode.

into Preferences > Image Processing >Metadata :
Metadata synchronisation with XMP sidecars : Bidirectional
XMP sidecar style : Standard(FILENAME.xmp for FILENAME.ext)

If i set into Preferences > Image Processing > Processing Profile Handling :

  • Processing profile saving location : Save processing profile to the cache
    Of course, this does not work in bidirectional
  • Processing profile saving location : Save processing profile nex to the input file
    a pp3 file is created and other programs like Digicam use an xmp file and not pp3

Any chance of a Monterey build of this, for those Mac users who can’t run Ventura please?

@Andy_Astbury1 What is the architecture of your Monterey system?

Intel, public release works fine but just wanted to test the CR3 exif

Update - This was apparently some kind of cacheing issue. After clearing everything it’s normal now.

Ok. the intel side should work fine on Big Sur, Monterey, and higher. For the Apple Silicon side, it’s Ventura and higher. If it doesn’t run, it should give you a statement as to why it is not going thru.

Screenshot 2023-03-30 at 01.02.32

This is all I see…

Thanks @Andy_Astbury1 I will take a look after a rehearsal this evening.

1 Like

Okay… there are two copies in Applications judging by the name… this causes some errors. See if you can limit it to one RT at a time in the Applications folder by moving both things out, then reinstall.

Okay, removed stable public release + all associated files. Installed latest dev and it just crashes on start attempt.
Attached is .pdf of crash report.
Translated Report (Full Report Below).pdf (51.3 KB)

Could do with getting it working like public release as it needs banging out on YouTube asap!

By associated files being removed, I would also try removing the ~/Library/Containers/RawTherapee folder if you haven’t already.

@paulmatthijsse I’ve seen the text editing issue before elsewhere and on Windows. No idea what causes it though.

@apostel338 Thanks for showing where the lens information is. I will fix it in the upcoming days.

@marter When you add metadata to the image, do you have the “Metadata copy mode” set to “Apply modifications”? Also, are you able to provide a sample raw file which has the lens detection issue?

@lphilpot I guess there should be an automatic cache refresh when users upgrade to a version with Exiv2 enabled. That would prevent confusion for users.

@schorschbey That’s a good suggestion. I agree there should be a clear visual indication corresponding to the metadata copy mode. Like @paulmatthijsse, I can’t reproduce the slowdown on Linux. I will try later with Windows.

Thanks again to everyone who tested! Keep the comments coming if you notice any other issues not mentioned yet.

@Lawrence37 my bad, the added metadata are exported fine. But the issue of incorrect lens-detection is still existing, a RAW file is added. Lensfun is recognizing a Konica Minolta KM 24-105 mm, but the shot was taken at 135 mm with a Sigma 18-200 f/3.5-6.3 DC.

DSC00826.ARW (24,3 MB)

@HIRAM Still crashes at startup
Translated Report (Full Report Below).pdf (54.4 KB)

Thank you for trying, @Andy_Astbury1
It looks like the app is trying to sync with the system cache. It should be reset with this command in terminal update_dyld_shared_cache -root / -force*
then see if you can generate a different crash report.

* This command is probably not going to work on Monterey… let me see if there is something else.

I would try a boot into safe mode followed by a normal boot:

I think @Andy_Astbury1 to run on your cpu may require nehalem-westmere build flags, as I’m currently using a later spec. Later this afternoon I will put the westmere-tuned x86_64 build on the drive. 5.9 was built for sandybridge-ivybridge the minimum spec for macOS 11.3 (non-hackintosh).

@Andy_Astbury1 The build in the shared folder now targeting Nehalem-Westmere, see if that will run on your Mac.