ART CR3 compatibility in linux

Damn xD I really can’t see it hahah, have you tested it in linux by any chance?

Here the last lines with and error:

CacheImageData::load / Error code 4 while reading values from "/home/chema/.cache/ART/data/IMG_8790.CR3.61da7cdf11184657187405be43fe454b.txt": No such file or directory importing metadata for Downloads/test cr3/IMG_8790.CR3 with exiftool terminate called after throwing an instance of 'Glib::SpawnError'

Here the entire log
https://gist.githubusercontent.com/neo22s/1f28eac5bf9256d881bdba74c6aa2b10/raw/f0627ce6858ba250fe58212eab15d281c3d707ec/txt

Hi Alberto!
I see in your screenshot that ART can read CR3 metadata, right?
I can see CR3 files, but with no metadata! How is it possible?
Thanks

@neo22s I have been working (almost) exclusively on Linux for about 20 years now :slight_smile:

Anyway, it seems you have a broken (or maybe too old) exiftool installation. I need to better trap this error in the code, but in the meantime you can try the following:

  • download the latest version of exiftool from http://exiftool.org

  • unpack it somewhere

  • point ART to it, i.e. set the following to the full path of the new exiftool:

@alvamatik: the same should work for you as well to get CR3 metadata.

Let me know if this works!

2 Likes

YES!!! that was the issue :wink: seems all working correctly now! thanks a lot :smiley:

I will do a blog post explaining step by step how to make it work.

THANKS A LOT this will improve my workflow a LOT.

2 Likes

I have done this blog post with the detailed installation, hope helps someone Canon CR3 support in Linux using ART, RawTherapee fork – Chema

3 Likes

@neo22s thanks for the post! I’ve added a link to it in the docs section of the home page. One minor point though: ART is a derivative of RawTherapee, not a clone. I say this so that people looking for RT+Canon CR3 won’t get disappointed when they see ART instead…

You are right I have changed clone for Fork , better? and thanks to you!! :wink:

1 Like

I have a strange problem with exiftool.
First if I use the deb package of @Dariusz_Duma it works perfectly, the path to my exiftool program is OK.
Then I use the appimage from @Carmelo_DrRaw (1.1-45) and all is OK I detect data from Raw CR3 files.
If I use my compilation (1.1-45) i only get a partial informationScreenshot_2 Screenshot_1
Where could be the problem ?
Thanks for your suggestion
I must say that it already works in previous versions.
Serge

did you compile exiv2 yourself? there is a known issue there with some compilation flags breaking exception handling

I carefully follow the method of @Morgan_Hardwood :

It woks perfectly for me.
What I noticed recently are new messages during the compilation. See joint fileComp.txt (2.2 KB)
Could it be related to that ?
Thanks
Serge Moreau

Hello Alberto,

I have the same problem as Serge.
My linux distro uses exiv2 0.27.2 compiled with the following flags :
cmake
-DCMAKE_C_FLAGS=“-O2 -fPIC”
-DCMAKE_CXX_FLAGS=“-O2 -fPIC”
-DCMAKE_INSTALL_PREFIX=/usr
-DLIB_SUFFIX=“64”
-DMAN_INSTALL_DIR=/usr/man
-DBUILD_SHARED_LIBS=ON
-DEXIV2_ENABLE_CURL=ON
-DEXIV2_ENABLE_VIDEO=ON
-DEXIV2_ENABLE_WEBREADY==ON
-DEXIV2_ENABLE_XMP=ON
-DEXIV2_BUILD_SAMPLES=OFF
-DEXIV2_ENABLE_NLS=ON

Can you tell me if these flags are correct or do I have to change them ?

Thanks.

PS : I use ART version 1.3

Hi @ecasaert,

you can try adding -fvisibility=default to your compilation flags (both CMAKE_C_FLAGS and CMAKE_CXX_FLAGS) and see if that helps.

Hi @agriggio,

I tried your solution but no luck :frowning: the problem is still there.

Do you have exiftool properly set up? You need a recent version and to make sure it is properly configured in the preferences

I have the same problem here.
Before on Ubuntu 18.04, I had put the path of a recent exiftool in preferences and everything was fine.
On Ubuntu 20.04 with Exiv2 from Ubuntu repositories (version 0.27.2), no exif for CR3, although exiftool is correctly indicated in the preferences.
Reproducible with Art 1.2 and Art 1.3 in compiled version.
With the AppImage, the exifs are present. But impossible to have access to the correction of objectives with the Appimage version.
So I use AdobeDngConverter to have the Exifs with the compiled version.

Ok, thanks for the info. I guess the problem is always the same: exiv2 is somehow miscompiled, so that exceptions do not get propagated. Would it be possible to try using a self-compiled exiv2 and see if the problem persists?

In the meantime I’ll try to get a 20.04 VM and see what is going on…

With the AppImage, the exifs are present. But impossible to have access to the correction of objectives with the Appimage version.

Can you send me your options file? Also, ping @Carmelo_DrRaw.

Yes, exiftool 11.98 is installed and the full path to it was set in the preferences.
Using exiftool on the command line gives all the information from a .CR3 file.

Hi,

I confirm the Ubuntu 20.04 package of exiv2 seems miscompiled, as exceptions are lost. Workaround:

  1. download the linux64 pre-built library from the exiv2 website:

    https://exiv2.org/builds/exiv2-0.27.2-Linux64.tar.gz

  2. unpack the tarball somewhere, e.g. /path/to/exiv2-0.27.2-Linux64

  3. open a terminal, and run ART as follows:

    $ LD_LIBRARY_PATH=/path/to/exiv2-0.27.2-Linux64/lib:$LD_LIBRARY_PATH /path/to/ART
    

Now it should work. You can make the above permanent by editing the menu entry for ART, or just wrap the above in a script.

It might be good to report this upstream to the Exiv2 ubuntu maintainers (ping @clanmills FYI)

Hi,

Yes, here : SwissTransfer - Envoi sécurisé et gratuit de gros fichiers

Thanks Alberto, It’s works fine.

Thanks. This is the offending entry:

[Lensfun]
DBDirectory=../share/lensfun/version_1

just change it to this:

[Lensfun]
DBDirectory=share/lensfun/version_1

and the appimage should work.

Thanks Alberto, It’s works fine.

Good! In the meantime, considering that some other people might be affected by this, I’ve implemented a “hack” that should make ART work also with the stock exiv2 lib of 20.04.

HTH

2 Likes