RAF and CR2 files: Face preview wrong due to wrong dimensions

[skylatian]

The bug

This bug differs from https://github.com/immich-app/immich/issues/12440 in that the preview box correctly surrounds the person's face, but the preview image that shows in the People tab (or in file details) is not zoomed/cropped to the correct location in a photo.

This issue is fixed when manually selecting "Select Featured Photo." This cases the profile picture/preview for that particular person to be cropped correctly.

(note - the image shown vs. source for "featured thumbnail" are slightly different photos (taken a few seconds apart), but the effect happens with that photo as well and I didn't want to re-blur for anonymity)

The overall \"People\" tab. Every one of these is a validly recognized person, the thumbnail ("Featured Photo") is just misaligned.

The OS that Immich Server is running on

Windows 10 Server

Version of Immich Server

v1.116.2

Version of Immich Mobile App

n/a

Platform with the issue

• [ ] Server
• [X] Web
• [ ] Mobile

Your docker-compose.yml content

#
# WARNING: Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.
#

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - /etc/localtime:/etc/localtime:ro
      - "D:/nas/Media:/home/user/photos1:ro"
    env_file:
      - .env
    ports:
      - 2283:3001
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, openvino] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://immich.app/docs/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, openvino, openvino-wsl] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/redis:6.2-alpine@sha256:2d1463258f2764328496376f5d965f20c6a67f66ea2b06dc42af351f75248792
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: docker.io/tensorchord/pgvecto-rs:pg14-v0.2.0@sha256:90724186f0a3517cf6914295b5ab410db9ce23190a2d9d0b9dd6463e3fa298f0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    healthcheck:
      test: pg_isready --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' || exit 1; Chksum="$$(psql --dbname='${DB_DATABASE_NAME}' --username='${DB_USERNAME}' --tuples-only --no-align --command='SELECT COALESCE(SUM(checksum_failures), 0) FROM pg_stat_database')"; echo "checksum failure count is $$Chksum"; [ "$$Chksum" = '0' ] || exit 1
      interval: 5m
      start_interval: 30s
      start_period: 5m
    command: ["postgres", "-c", "shared_preload_libraries=vectors.so", "-c", 'search_path="$$user", public, vectors', "-c", "logging_collector=on", "-c", "max_wal_size=2GB", "-c", "shared_buffers=512MB", "-c", "wal_compression=on"]
    restart: always

volumes:
  model-cache:

Your .env content

# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables

# The location where your uploaded files are stored
UPLOAD_LOCATION="D:/immich-library"
# The location where your database files are stored
DB_DATA_LOCATION=./postgres

# To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
# TZ=America/[]

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=release

# Connection secret for postgres. You should change it to a random password
# Please use only the characters `A-Za-z0-9`, without special characters or spaces
DB_PASSWORD=[redacted]

# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immich

Reproduction steps

The issue:

1. Open Photos tab
2. Witness faces not being centered

The manual fix:

1. Click on a person in the People tab (or from elsewhere)
2. Top right menu->Select Featured Photo
3. (Choose a photo)
4. See that Featured Photo now appears correctly system-wide

Relevant log output

No response

Additional information

No response

[C-Otto]

If I understand you correctly, each person's face photo (as shown on the "/people" URL, i.e. the "People" page) is showing a wrong part of the correct image (e.g. a plant behind the person instead of the actual head)?

[skylatian]

Correct, yes! That’s a much better way of putting it.

[C-Otto]

Thank you for the clarification! Do you know if there's anything special about the people/faces/photos? Did you modify them? Can you reproduce this (with new people/photos)?

[skylatian]

I didn't realize this until now, but it seems like it might only be happening with Fuji Raw (.RAF) files! The same behavior occurs if I select a .RAF photo as the preview manually. I just checked with Sony's Raw files (ARW) and they select the face correctly.

[C-Otto]

That's great (for debugging) :) Could you please provide a sample .RAF picture with a face on it?

[skylatian]

I will get back to you on that. For the life of me, I can't find one that uploads and causes the same issue. I appreciate your help!

[C-Otto]

It's possible that this issue was fixed in the meantime...

[skylatian]

I just updated from 116 to 117 earlier today, that might be it. All the scans had been done on 116. I’m re-running the face detection+recognition jobs now, I will report back once they’re done.

[stjeanp]

I just rebuilt all thumbnails in my library (~40k images), the majority of which are CR2 raw files. I'm seeing the exact same issue. The box around the face is correct, but the part of the photo used for the person's picture is wrong. I picked one person, opened an image with a (to me) good face, confirmed that the box was actually around his face, then went back to the person and set that as his featured photo. His featured photo is now a section of wall, not his face. I'm happy to share the file, if you need more data.

I'd rather not redo all of the face detection and grouping, because that was a lot of work, but if y'all think it'd be worthwhile, I'll kick it off tonight (US/Central) and it should be done by morning and will report back.

Edit: I just kicked off a full face detection/recognition job. Will report back when it's done.

I'm also running 1.117.0.

[C-Otto]

@stjeanp yes, please share the file and let us know of any pattern you might suspect (only CR2 raw files, for example?)

[stjeanp]

@C-Otto The redo of the face detection/grouping completed and I've found a good example, since this person only appears in five files, all of which are CR2 files. I can't attach the zip of them because it's too big, but if you message me, I can give you a URL to download it. Sorry. Here's some explanatory screenshots though. Please let me know what else you'd like me to do.

Before any changes were made:

Here's the person's face box:

And here's one where her feature photo is now a piece of the wall instead of her face, after selecting the topmost image to use as her feature photo:

[stjeanp]

Sorry, here's the face box on the image I used as the new featured photo:

[C-Otto]

Thanks, that looks helpful. I just sent a mail regarding the link to the raw file(s).

[stjeanp]

Got it, replied with the link. Let me know when you're good and I'll take it down.

[C-Otto]

Got it, thanks - feel free to delete the file.

[skylatian]

Looks like you got a sample file, thanks for taking care of that @stjeanp

I can confirm it's still happening after rebuilding all faces and people on 1.117. Thanks for your help @C-Otto

[C-Otto]

The image dimensions are off, for the images provided by @stjeanp I see 1728x1152 (2MP), while Gimp shows 3522x2348 (8MP). Using exiftool I get:

Image Width                     : 1728
Image Height                    : 1152
Canon Image Width               : 3504
Canon Image Height              : 2336
AF Image Width                  : 3504
AF Image Height                 : 2336
Exif Image Width                : 3504
Exif Image Height               : 2336
Image Size                      : 3504x2336

Any idea what might be the cause of having three different sizes?

This wrong image size does not only mess up the "generate face preview" bit, but also shows in the details pane on the screenshots above.

[C-Otto]

@skylatian do you notice any weirdness related to reported and actual image dimensions? You should be able to see what Immich thinks in the detail view (which you included in your screenshots). Maybe the actual images don't match these dimensions?

[skylatian]

@C-Otto I do, good catch.

• The immich-reported dimensions for the .RAF file are 2944 x 4416.
• All of my .RAF files show either 2944x4416 or 4416x2944 (depending on orientation) so it’s not random.
• The corresponding jpegs for each raw are 4160 x 6240 (as expected)
• If I download and check the .RAF in file explorer or finder, the dimensions correctly show as 4160 x 6240.

It seems immich is listing the resolution as scaled down by a factor of ~0.707 for mine compared to ~0.49 for @stjeanp’s. Sony RAWs do not have this problem. I have no idea why exiftool would report three sizes, maybe it’s something related to the baked-jpeg preview?

[mertalev]

There is an "Exif Image Width/Height" field in the CR2 sample above that's accurate. Can you check with exiftool if the RAF file also has this? We could prefer this field when it exists during metadata extraction.

[C-Otto]

Are you able to see/extract the JPG preview image that's part of the raw image? If so, is this preview smaller than the actual image? In https://exiftool.org/forum/index.php?topic=4709.0 this is mentioned as a possible cause.

With exiftool -b -previewImage -w .jpg IMG_8119.CR2 I get a JPG file that has size 1728x1152, confirming this idea. If this also holds true for RAF files, we might need to tweak exiftool or exiftool-vendored, or work around this in Immich itself.

[stjeanp]

I'm not sure where those Image Width values are coming from. Looking at the original in Lightroom, it agrees with the others that the dimensions are 3504x2336. I thought it might be one of the thumbnails, but the standard view one is 2160x1440. I'm hanging on to that hunch, but can't see the other thumbnails. I'm looking on the filesystem now.

[stjeanp]

Interestingly enough, the CR2 format allows for embedded, smaller JPEG versions of the image. I'm looking for a tool to do a deep dive into that CR2 file to see if it has any of that in it. Sort of a structure dump.

[skylatian]

from exiftool -'*height*' -'*width* -'*size*' filename.RAF I get (organized):

Exif Image Height               : 2944
Exif Image Width                : 4416

Image Height                    : 2944
Image Width                     : 4416

Raw Image Height                : 1008
Raw Image Width                 : 6276

Raw Image Full Height           : 4182
Raw Image Full Width            : 6384

File Size                       : 59 MB
AF Area Point Size              : 4
AF Area Zone Size               : n/a
Grain Effect Size               : Small
Raw Image Full Size             : 6384x4182
Raw Image Cropped Size          : 6240x4160
Raw Zoom Size                   : 6240x4160
Image Size                      : 6240x4160

I have no idea where that RawImageHeight term comes from.

Output of exiftool -b -previewImage -w .jpg confirms that my built-in jpeg preview is 2944×4416, seems like it's from Exif Image Height and Exif Image Width.

[mertalev]

Of course this one doesn't use Exif Image Width/Height for the original... that would be too simple. Image Size looks a bit more promising as it's correct for both images.

[stjeanp]

At least in my case, that looks like it's in the CR2, possibly an embedded, lower resolution JPEG.

Extra information File: IMG_8121.CR2 File size: 7.3470 MB

TIFF header endianness: II magic_number: 0x002a offset_to_ifd: 0x000010

File: is little endian format

CR2 Header canon_raw_marker: CR version: 2 offset_to_raw_ifd: 0x012b3e

IFD0 number_of_entries: 14, in mem: 0x5639fb4ed4a0, next_ifd_offset: 0x012a90

entry number: 0 tag_id: 256|0x100, tag_type: unsigned short (2 bytes), number_of _values: 1, value_or_start_addr_to_data: 0x0006c0 unmarshal value: "1728 " entry number: 1 tag_id: 257|0x101, tag_type: unsigned short (2 bytes), number_of _values: 1, value_or_start_addr_to_data: 0x000480 unmarshal value: "1152 " entry number: 2 tag_id: 258|0x102, tag_type: unsigned short (2 bytes), number_of _values: 3, value_or_start_addr_to_data: 0x0000be unmarshal value: "8 8 8 " entry number: 3 tag_id: 259|0x103, tag_type: unsigned short (2 bytes), number_of _values: 1, value_or_start_addr_to_data: 0x000006 unmarshal value: "6 " entry number: 4 tag_id: 271|0x10f, tag_type: string (with an ending zero), number ...

[stjeanp]

And this:

stjeanp@gepetto:~/cr2dump$ exiftool IMG_8121.CR2 ExifTool Version Number : 12.40 File Name : IMG_8121.CR2 Directory : . File Size : 7.3 MiB File Modification Date/Time : 2024:10:09 16:10:57-05:00 File Access Date/Time : 2024:10:09 16:11:03-05:00 File Inode Change Date/Time : 2024:10:09 16:10:57-05:00 File Permissions : -rw-r--r-- File Type : CR2 File Type Extension : cr2 MIME Type : image/x-canon-cr2 Exif Byte Order : Little-endian (Intel, II) Image Width : 1728 Image Height : 1152 Bits Per Sample : 8 8 8 Compression : JPEG (old-style) Make : Canon Camera Model Name : Canon EOS 30D Preview Image Start : 87063 Orientation : Horizontal (normal) Preview Image Length : 447565 X Resolution : 72 Y Resolution : 72 Resolution Unit : inches Modify Date : 2010:08:21 19:41:27 Exposure Time : 1/25 F Number : 4.0 Exposure Program : Program AE ISO : 100 Exif Version : 0221 Date/Time Original : 2010:08:21 19:41:27 Create Date : 2010:08:21 19:41:27 Components Configuration : -, -, -, - Shutter Speed Value : 1/25 Aperture Value : 4.0 Flash : Off, Did not fire Focal Length : 40.0 mm Macro Mode : Normal Self Timer : Off Quality : RAW Canon Flash Mode : Off Continuous Drive : Single Focus Mode : AI Focus AF Record Mode : CR2 Canon Image Size : n/a Easy Mode : Manual Digital Zoom : None Contrast : Normal Saturation : Normal Sharpness : +3 Metering Mode : Evaluative Focus Range : Not Known Canon Exposure Mode : Program AE Lens Type : Canon EF 17-40mm f/4L USM or Sigma Lens Max Focal Length : 40 mm Min Focal Length : 17 mm Focal Units : 1/mm Max Aperture : 4 Min Aperture : 22 Flash Activity : 0 Flash Bits : (none) Focus Continuous : Single Zoom Source Width : 0 Zoom Target Width : 0 Photo Effect : Off Manual Flash Output : n/a Color Tone : Normal Focal Type : Zoom Focal Plane X Size : 23.04 mm Focal Plane Y Size : 15.37 mm Auto ISO : 100 Base ISO : 100 Measured EV : 8.62 Target Aperture : 4 Target Exposure Time : 1/25 Exposure Compensation : 0 White Balance : Auto Slow Shutter : None Shot Number In Continuous Burst : 0 Optical Zoom Code : n/a Camera Temperature : 20 C Flash Guide Number : 0 Flash Exposure Compensation : 0 Auto Exposure Bracketing : Off AEB Bracket Value : 0 Control Mode : Camera Local Control Measured EV 2 : 8.75 Bulb Duration : 0 Camera Type : EOS Mid-range Auto Rotate : None ND Filter : n/a Self Timer 2 : 0 Canon Image Type : Canon EOS 30D Canon Firmware Version : Firmware 1.0.6 Owner Name : unknown Serial Number : 0820514251 Set Function When Shooting : Default (no function) Long Exposure Noise Reduction : Off Flash Sync Speed Av : Auto Shutter-AE Lock : AF/AE lock AF Assist Beam : Emits Exposure Level Increments : 1/3 Stop Flash Firing : Fires ISO Expansion : Off AEB Sequence/Auto Cancel : -,0,+/Enabled Superimposed Display : On Menu Button Display Position : Previous (top if power off) Mirror Lockup : Disable AF Point Selection Method : Normal E-TTL II : Evaluative Shutter Curtain Sync : 1st-curtain sync Safety Shift In Av Or Tv : Disable Magnified View : Image playback only Lens AF Stop Button : AF stop Add Original Decision Data : Off Canon Model ID : EOS 30D Num AF Points : 9 Valid AF Points : 9 Canon Image Width : 3504 Canon Image Height : 2336 AF Image Width : 3504 AF Image Height : 2336 AF Area Width : 78 AF Area Height : 78 AF Area X Positions : 8 -555 571 -931 8 947 -555 571 8 AF Area Y Positions : 504 270 270 4 4 4 -262 -262 -496 AF Points In Focus : 4 Thumbnail Image Valid Area : 0 159 7 112 Serial Number Format : Format 2 Original Decision Data Offset : 0 File Number : 100-8121 Bracket Mode : Off Bracket Value : 0 Bracket Shot Number : 0 Long Exposure Noise Reduction 2 : Off WB Bracket Mode : Off WB Bracket Value AB : 0 WB Bracket Value GM : 0 Filter Effect : None Toning Effect : None Lens Model : EF17-40mm f/4L USM Internal Serial Number : F0212382 Tone Curve : Standard Sharpness Frequency : n/a Sensor Red Level : 0 Sensor Blue Level : 0 White Balance Red : 0 White Balance Blue : 0 Color Temperature : 5200 Picture Style : Standard Digital Gain : 0 WB Shift AB : 0 WB Shift GM : 0 Measured RGGB : 1136 1024 1024 492 VRD Offset : 0 Sensor Width : 3596 Sensor Height : 2360 Sensor Left Border : 84 Sensor Top Border : 19 Sensor Right Border : 3587 Sensor Bottom Border : 2354 Black Mask Left Border : 0 Black Mask Top Border : 0 Black Mask Right Border : 0 Black Mask Bottom Border : 0 Color Data Version : 1 (1DmkIIN/5D/30D/400D) WB RGGB Levels As Shot : 2114 1024 1024 1498 Color Temp As Shot : 5625 WB RGGB Levels Auto : 2114 1024 1024 1498 Color Temp Auto : 5625 WB RGGB Levels Measured : 2110 1020 1026 1495 Color Temp Measured : 5625 WB RGGB Levels Daylight : 2040 1024 1024 1591 Color Temp Daylight : 5200 WB RGGB Levels Shade : 2362 1024 1024 1319 Color Temp Shade : 7000 WB RGGB Levels Cloudy : 2203 1024 1024 1444 Color Temp Cloudy : 6000 WB RGGB Levels Tungsten : 1581 1138 1138 2773 Color Temp Tungsten : 3200 WB RGGB Levels Fluorescent : 1851 1072 1072 2440 Color Temp Fluorescent : 3752 WB RGGB Levels Kelvin : 2040 1024 1024 1591 Color Temp Kelvin : 5200 WB RGGB Levels Flash : 2236 1024 1024 1402 Color Temp Flash : 6283 WB RGGB Levels PC1 : 8191 1049 1049 512 Color Temp PC1 : 3944 WB RGGB Levels PC2 : 8191 1049 1049 512 Color Temp PC2 : 3944 WB RGGB Levels PC3 : 8191 1049 1049 512 Color Temp PC3 : 3944 WB RGGB Levels Custom : 2040 1024 1024 1591 Color Temp Custom : 5200 Per Channel Black Level : 128 127 127 127 Flash Output : 0% Flash Battery Level : n/a Measured RGGB Data : 49008 45781 44363 21060 Picture Style User Def : Standard; Standard; Standard Picture Style PC : None; None; None Custom Picture Style File Name : User Comment : Flashpix Version : 0100 Color Space : sRGB Exif Image Width : 3504 Exif Image Height : 2336 Interoperability Index : R98 - DCF basic file (sRGB) Interoperability Version : 0100 Focal Plane X Resolution : 3959.322034 Focal Plane Y Resolution : 3959.322034 Focal Plane Resolution Unit : inches Custom Rendered : Normal Exposure Mode : Auto Scene Capture Type : Standard Thumbnail Offset : 76800 Thumbnail Length : 10263 Photometric Interpretation : RGB Samples Per Pixel : 3 Rows Per Strip : 256 Planar Configuration : Chunky Strip Offsets : 829540 Strip Byte Counts : 6874326 CR2 CFA Pattern : [Red,Green][Green,Blue] Raw Image Segmentation : 1 1798 1798 Drive Mode : Single-frame Shooting Lens : 17.0 - 40.0 mm Shooting Mode : Program AE WB RGGB Levels : 2114 1024 1024 1498 Aperture : 4.0 Blue Balance : 1.462891 Image Size : 3504x2336 Lens ID : Canon EF 17-40mm f/4L USM Megapixels : 8.2 Preview Image : (Binary data 447565 bytes, use -b option to extract) Red Balance : 2.064453 Scale Factor To 35 mm Equivalent: 1.6 Shutter Speed : 1/25 Thumbnail Image : (Binary data 10263 bytes, use -b option to extract) Lens : 17.0 - 40.0 mm (35 mm equivalent: 27.2 - 64.1 mm) Circle Of Confusion : 0.019 mm Field Of View : 31.4 deg Focal Length : 40.0 mm (35 mm equivalent: 64.1 mm) Hyperfocal Distance : 21.32 m Light Value : 8.6

[stjeanp]

Based on the response from the exiftool-vendord.js maintainer, it sounds like it's back on this side of the fence. I'm not sure if it's possible, but would it make sense to have a list of tags, in preferred order, to try? First one found wins. We'd probably need to crunch a LOT of different file formats to ensure that the priority list is correct. Edge cases will be a real challenge.

I think I understand how delicate this potentially is, because the wrong "fix" could break it for other image files. So, without coming off as pushy, and believe me, I'm not trying to sound like that at all, what would be the approach to resolving this. I'll be happy to help any way I can (I'm primarily a security guy these days, but have done software development in my past, though that was in Python, Perl, Ruby, and C).

[mertalev]

I think a priority can be problematic because two images can have the same tag, but use it differently. Looking at vendor-specific tags would be more reliable for those particular vendors, but is quite the rabbit hole.

I checked our test assets for E2E testing and all of them would work correctly with Image Size. Given that it works for the images here as well, it might be fine to just use that instead.

[stjeanp]

If that looks like it'd work, that's great! If you need to add a one of my images to the test suite, I've got some better ones that I'd be happy to contribute. Please let me know if there's anything I can do to help.

[mertalev]

It'd be great if you could make a PR to add one in the test-assets repo!

[C-Otto]

If we go along the route of considering multiple tags, we could just take the maximum we find.

[skylatian]

Raw Image Full Size : 6384x4182 Raw Image Cropped Size : 6240x4160

You’d think, but apparently not! As far as I know, the “cropped” resolution here is the correct one. This is from a Fuji x100v

[stjeanp]

@mertalev - I'm looking at the repo now and will open a PR later today. I've upgraded bodies a few times and have CR2s from an EOS 30D, EOS 70D, and a PowerShot G12. The raws from the 30D and G12 are showing the smaller image size issue. I can't find a 70D RAW that's exhibiting this issue though.

Would you like me to include all three files in the PR?

[C-Otto]

Ideally you'd open separate PRs (and include the exiftool output in each). That'd be my preference, if that counts :)

[stjeanp]

Will do! Working on that now.

[stjeanp]

@C-Otto - Quick question: do you want people in them or just landscapes/buildings/etc. I've got both, and have people ones that are me and my spouse, both of which give permission to use the files.

[C-Otto]

I think the actual contents don't matter, we only care about the metadata. If you provide pictures of your wall or just plain black images, that still helps (and it might keep the filesize down).

[stjeanp]

Sounds good. There are three PRs waiting for review. Glad to have been able to help out, and please let me know if there's anything else I can do to help move this fix forward.

[C-Otto]

https://github.com/immich-app/test-assets/pull/11 can be used to reproduce this, I think. Image Width/Height are 1600x1200, but 3648x2736 seems to be closer to the truth.

[C-Otto]

@skylatian can you provide a RAF file where neither "ImageWidth" nor "ExifImageWidth" show the correct width?

[C-Otto]

How many faces/people are affected? Even with the fix, you'd need to somehow fix the preview images (manually is one way, but there are others).

[stjeanp]

For me, I've got 900+ detected faces over ~40k images. I don't mind doing a rebuild once the fix is in. That might be onerous for some users though.

[skylatian]

@skylatian can you provide a RAF file where neither "ImageWidth" nor "ExifImageWidth" show the correct width?

Happy to, I'll open a PR later today.

Unfortunately, I looked at a raw (.DNG) from a family member's Ricoh GR3, and neither ImageWidth nor Image Size lists the correct resolution.

Image Height                    : 4064
Image Width                     : 6112
File Size                       : 31 MB
Default Crop Size               : 6000 4000
Preview Image Size              : 720x480
Image Size                      : 6112x4064

Image Size and Image Width are the same, but the correct resolution is Default Crop Size as confirmed by Lightroom and Finder. If I'm not mistaken, https://github.com/immich-app/immich/pull/13377 wouldn't address this. Thoughts?

[mertalev]

@skylatian can you provide a RAF file where neither "ImageWidth" nor "ExifImageWidth" show the correct width?

Happy to, I'll open a PR later today.

Unfortunately, I looked at a raw (.DNG) from a family member's Ricoh GR3, and neither ImageWidth nor Image Size lists the correct resolution.

Image Height                    : 4064

Image Width                     : 6112

File Size                       : 31 MB

Default Crop Size               : 6000 4000

Preview Image Size              : 720x480

Image Size                      : 6112x4064

Image Size and Image Width are the same, but the correct resolution is Default Crop Size as confirmed by Lightroom and Finder. If I'm not mistaken, https://github.com/immich-app/immich/pull/13377 wouldn't address this. Thoughts?

This is truly incredible.

At least using Image Size wouldn't be a regression in this case. Maybe we can consider Default Crop Size as well if it wouldn't cause issues elsewhere.

[stjeanp]

It's not going to bother the three Canon bodies I've got RAWs from, none of them use that tag.

stjeanp@gepetto:~$ ls Canon*
CanonEOS30D.CR2  CanonEOS70D.CR2  CanonPowerShotG12.CR2
stjeanp@gepetto:~$ fgrep -i 'default crop size' Canon*
stjeanp@gepetto:~$ 

[skylatian]

This is truly incredible.

Isn't it? Update on the Ricoh, though. I hadn't run exiftool with the -a flag previously, and running it with that reveals:

exiftool -'*height*' -'*width*' -'*size*' -'*jpg*' -a -g1 file.DNG

---- File ----
File Size                       : 31 MB
---- EXIF ----
Image Width                     : 160
Image Height                    : 120
Image Width                     : 6112
Image Height                    : 4064
Default Crop Size               : 6000 4000
Image Width                     : 6000
Image Height                    : 4000
---- MakerNotes ----
Preview Image Size              : 720x480
---- Composite ----
Image Size                      : 6112x4064

So... there are THREE Image Width tags? This is unique to the Ricoh, as far as I can tell. I agree Default Crop Size is probably the right move for this camera. That tag isn't present in the Fufi RAFs, though.

[C-Otto]

Please provide interesting example images so that I can tune the PR and retain that knowledge in automated tests. It doesn't make a lot of sense to break metadata extraction for other cameras, nor does it feel right to ignore information already noted in this issue. It's a mess, but if we're able to hide that mess in somewhat clean code, I'd say that's an improvement.