ImageMetadataReader does not handle FileType.Crx

[hanslovsky]

I am using metadata-extractor to automatically rename my Canon camera's jpegs with date information. Now, I want to do the same thing for raw files (CR3), but I found that ImageMetadataReader [does not handle FileType.Crx]("Canon EOS R3.cr3" ) (here I use jgo to run imageMetadataReader.main):

$ jgo com.drewnoakes:metadata-extractor:2.19.0:@ImageMetadataReader "Canon EOS R3.cr3"
Processed 11.708 MB file in 14.73 ms

[File Type] Detected File Type Name = CRX
[File Type] Detected File Type Long Name = Canon Camera Raw
[File Type] Expected File Name Extension = cr3
[File] File Name = Canon EOS R3.cr3
[File] File Size = 12277000 bytes
[File] File Modified Date = Wed Feb 21 23:18:31 -05:00 2024

The example image "Canon EOS R3.cr3" is the same one as in #605. I am a bit confused because the author of #605 seems to be able to extract image metadata from the same image.

In my Code, I tried using ImageMetadataReader, which does not read any information, and TiffMetadataReader, which fails with TiffProcessingException: Unclear distinction between Motorola/Intel byte ordering: 0.

This is a minimum example using the image from #605 using Kotlin's kscript:

#!/usr/bin/env kscript

@file:DependsOn("com.drewnoakes:metadata-extractor:2.19.0")

import java.io.File

import com.drew.imaging.ImageMetadataReader
import com.drew.imaging.tiff.TiffMetadataReader

val file = File("Canon EOS R3.cr3")
println("image metadata: ${ImageMetadataReader.readMetadata(file).directories}")
println("tiff metadata: ${TiffMetadataReader.readMetadata(file).directories}")

The output is

image metadata: [File Type Directory (3 tags), File Directory (3 tags)]
Exception in thread "main" java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
        at Main_Metadata_extractor_issue$Companion.main(Main_Metadata_extractor_issue.kt:6)
        at Main_Metadata_extractor_issue.main(Main_Metadata_extractor_issue.kt)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.jetbrains.kotlin.runner.AbstractRunner.run(runners.kt:70)
        at org.jetbrains.kotlin.runner.Main.run(Main.kt:188)
        at org.jetbrains.kotlin.runner.Main.main(Main.kt:198)
Caused by: com.drew.imaging.tiff.TiffProcessingException: Unclear distinction between Motorola/Intel byte ordering: 0
        at com.drew.imaging.tiff.TiffReader.processTiff(TiffReader.java:60)
        at com.drew.imaging.tiff.TiffMetadataReader.readMetadata(TiffMetadataReader.java:71)
        at com.drew.imaging.tiff.TiffMetadataReader.readMetadata(TiffMetadataReader.java:48)
        at kscript.scriplet.Metadata_extractor_issue.<init>(Metadata_extractor_issue.kts:10)

It is quite obvious to me that I am doing something wrong here, especially since #605 can retrieve metadata from CR3. Is there another MetadataReader that I should use for raw CR3 images?

[StefanOltmann]

I suspect this will be fixed by #624.

@drewnoakes just hadn’t had the chance to review that PR.

[hanslovsky]

Awesome, thank you! I will try with the code from the PR

[nosnhojbob]

#656 as well - chiming in on this too for hope of PR review(s). There may be more updated to follow, as it appears that there are some CRX uuid boxes which provide XMP data as well - @TSGames and I provided the essential EXIF and GPS pieces

[hanslovsky]

I tested #624 and #656 and both work for me, with #656 being up-to-date with upstream.

[nosnhojbob]

ping to @drewnoakes - would you have time to review PR #656? looks like a couple folks are pending on that getting merged. I apologize if I jumped right into working it, without being assigned on this issue