Fuji RAWs resolution after import 1920x1280 instead of 6000x4000

[100102533]

Describe the bug

After importing, darktable shows a resolution of 1920x1080 instead of 6000x4000 in the lighttable module. It seems as if the resolution of the embedded image is initially shown after the import.
The darkroom module shows the correct resolution of the RAW file.
My camera: Fujifilm XT-2. I will upload some screenshots and the output of exiftool for one of the RAWs.

Steps to reproduce

1. Setting the preferences
   1.1 lighttable -> pattern for the thumbnail tooltip:
   $(FILE_NAME).$(FILE_EXTENSION)$(NL)$(EXIF_DAY)/$(EXIF_MONTH)/$(EXIF_YEAR) $(EXIF_HOUR):$(EXIF_MINUTE):$(EXIF_SECOND)$(NL)$(EXIF_EXPOSURE) • f/$(EXIF_APERTURE) • $(EXIF_FOCAL_LENGTH) mm • $(EXIF_ISO) ISO$(NL)$(SENSOR_WIDTH) x $(SENSOR_HEIGHT)
   1.2 darkroom -> pattern for the image information line:
   $(FILE.NAME).$(FILE.EXTENSION) • $(EXIF_EXPOSURE) • f/$(EXIF_APERTURE) • $(EXIF_FOCAL_LENGTH) mm • $(EXIF_ISO) ISO • $(SENSOR_WIDTH) x $(SENSOR_HEIGHT)

2. Import Fuji X-T2 RAWs

3. Check the resolution values in the lighttable module
   4.1 Check the tooltips resolution: 1920x1080 (attachment resolution_lighttable_1920x1080.png)
   4.2 Check "image information" in the left panel: width=1920, height=1280 (attachment resolution_lighttable_1920x1080.png)

4. Check the resolution values in the darkroom module
   5.1 Choose one of the pictures and switch to darkroom module
   5.2 Check the information line resolution: 6048x4038 (attachment resolution_lighttable_1920x1080.png)
   5.3 Check the tooltip resolution: 1920x1080 (attachment resolution_darkroom_6048x4038.png)

5. Switch to the lighttable module
   6.1 Check the tooltips resolution of the first picture: 1920x1080 (attachment resolution_lighttable_6048x4038.png)
   6.2 Check "image information" of the picture in the left panel: width=6048, height=4038 (as opposed to 4.2) (attachment resolution_lighttable_6048x4038.png)

Expected behavior

darktable should show the same resolution for the same picture in every module

Logfile | Screenshot | Screencast

Fuji_RAW_exifs.txt

Commit

No response

Where did you install darktable from?

darktable.org

darktable version

4.2.1

What OS are you using?

Linux

What is the version of your OS?

debian 12 - bookworm

Describe your system?

No response

Are you using OpenCL GPU in darktable?

I dont know

If yes, what is the GPU card and driver?

No response

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

I can reproduce this only with RAW.
I don't use lua scripts

[kmilos]

Thanks for opening this separate issue. Already discussed in #15587 (comment) w/ upstream PR.

[victoryforce]

darktable, like any other exiv2 client, has the right to reasonably expect that the data returned by the exiv2 method call will be correct. Unfortunately, this was not the case with imageWidth/imageHeight for RAF files. Since the PR with the corresponding fix is already in the exiv2 repo, it can be expected that the next release of exiv2 will contain the bug fix.

The question is whether we should now push a temporary fix into the darktable codebase that will effectively duplicate the fix in exiv2. At this point, we can't even conditionally compile such code for versions of exiv2 that provide inaccurate information, because the fix in exiv2 hasn't been accepted yet, and we don't know exactly which version it will be in.

[kmilos]

FYI, mingw-w64-ucrt-x86_64-exiv2-0.28.1-2 is now available in the MSYS2 repo w/ the backported fix, so this could now be tested in theory.

NB.: This still won't make it for dt 4.6, at least not for Windows (the plan is to still keep exiv2 0.27.7 there for other reasons).

[wpferguson]

FYI, mingw-w64-ucrt-x86_64-exiv2-0.28.1-2 is now available in the MSYS2 repo w/ the backported fix, so this could now be tested in theory.

@100102533 Here's a link to a weekly snapshot with exiv2-0.28,1, darktable-4.5.0+1308~gb15765654a-win64.exe - Google Drive

[kmilos]

@wpferguson The patched "-2" package literally appeared today, so your weekly wouldn't have it...

[100102533]

@100102533 Here's a link to a weekly snapshot with exiv2-0.28,1, darktable-4.5.0+1308~gb15765654a-win64.exe - Google Drive

@wpferguson Thanks for the link, but I'm a linux user ;-)

[github-actions]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

[victoryforce]

Summing up. This is an upstream bug, which is already fixed in the Exiv2 library. For Linux builds of darktable 4.8 in current distributions, this will automatically mean that darktable does not have this problem.

Attn @kmilos: Regarding the Windows build, we have to make some sort of decision because of another Exiv2 issue that makes the latest versions of the library incompatible with the current darktable on the Windows platform.

But it is doable, so adding some temporary code to darktable to fix the problem with older Exiv2 versions doesn't make sense. So I'm closing this issue.

[kmilos]

@victoryforce The Canon lens detection issue has been fixed in exiv2 dev, but I don't know when the next 0.28.3 release will happen. Until then, it doesn't make too much sense to push for the Windows UTF-8 switch (and require Windows 10 as minimum) either, so I guess status quo (keep 0.27.7 on Windows) is the only/best option at the moment...