handleGeneratePersonThumbnail incorrectly crops if thumbnail is regenerated with a different size #8317
Comments
|
Great catch! There's a PR (#7513) that scales these, but for a different reason. It's currently blocked because there was a bug raised that I can't reproduce. |
Oh yeah, that looks good! that seems like that would resolve this issue anyway. |
|
Hey @raymondnumbergenerator, could you verify it's solved by #7513? :) |
|
I don't know if it was in logs before but since upgrade to 106 I noticed the issue: |
|
@zigarn are you on 1.106.4? It is fixed in the latest hot fix |
|
Yes 1.106.4 |
|
How many of those errors do you see? Could you share an image that has that issue? Also, is your preview resolution default or did you change it? |
|
You can get some info about the asset for the failed job you shared by running this:
|
|
Ok I give you those info as soon as I can. |
|
I count 14 errors. Here is one of the pictures: On the person pages I checked, I noticed that every time it's with portrait pictures but the preview is cropped as paysage: On the photo information, we can see that other person thumbnail is misplaced: The query for corresponding person uuid: |
|
That's interesting, this thumbnail has apparently never been generated successfully. Do you know around when this asset was added to Immich? You can add |
|
It's from external library added when I created my instance of immich. There is a previewPath and the preview in person view is a webp file (didn't attach it as not supported by GitHub). Is there a way to reset thumbnail? |
|
I launched a Info from a {
"id": "43ed4128-0ef4-4bf6-8abe-95343d53d088",
"deviceAssetId": "Thaïlande(15).jpg",
"ownerId": "d38e2bf4-3df6-420c-bba9-a17731d74132",
"owner": {
"id": "d38e2bf4-3df6-420c-bba9-a17731d74132",
"email": "***",
"name": "***",
"profileImagePath": "upload/profile/d38e2bf4-3df6-420c-bba9-a17731d74132/3d155a5f-2e1b-4d06-98b6-50c2d591ebbd.jpg",
"avatarColor": "primary"
},
"deviceId": "Library Import",
"libraryId": "6576fc40-c645-45b5-aff7-8e01c72fdf33",
"type": "IMAGE",
"originalPath": "/usr/src/app/external/path/to/image/Thaïlande (15).jpg",
"originalFileName": "Thaïlande (15).jpg",
"originalMimeType": "image/jpeg",
"resized": true,
"thumbhash": "HAgaDQJ4iJ+Hp3eXeHeIZ8Rvjaz0",
"fileCreatedAt": "2013-01-08T16:35:55.000Z",
"fileModifiedAt": "2021-05-23T11:02:20.496Z",
"localDateTime": "2013-01-08T16:35:55.000Z",
"updatedAt": "2024-04-21T19:52:10.976Z",
"isFavorite": false,
"isArchived": false,
"isTrashed": false,
"duration": "0:00:00.00000",
"exifInfo": {
"make": "Panasonic",
"model": "DMC-TZ10",
"exifImageWidth": 2448,
"exifImageHeight": 3264,
"fileSizeInByte": 2877409,
"orientation": "6",
"dateTimeOriginal": "2013-01-08T16:35:55.000Z",
"modifyDate": "2013-01-08T16:35:55.000Z",
"timeZone": null,
"lensModel": null,
"fNumber": 3.3,
"focalLength": 4.1,
"iso": 125,
"exposureTime": "1/60",
"latitude": null,
"longitude": null,
"city": null,
"state": null,
"country": null,
"description": "",
"projectionType": null
},
"livePhotoVideoId": null,
"tags": [],
"people": [
{
"id": "15a4a281-3870-4176-b290-e0831d9518a4",
"name": "",
"birthDate": null,
"thumbnailPath": "upload/thumbs/d38e2bf4-3df6-420c-bba9-a17731d74132/15/a4/15a4a281-3870-4176-b290-e0831d9518a4.jpeg",
"isHidden": false,
"faces": [
{
"id": "fb8c84bd-b210-444d-a79a-8e1ea43b392c",
"imageHeight": 1920,
"imageWidth": 1440,
"boundingBoxX1": 468,
"boundingBoxX2": 555,
"boundingBoxY1": 1002,
"boundingBoxY2": 1142
}
]
},
{
"id": "6567188a-8dd9-470f-b371-515e191b0a22",
"name": "",
"birthDate": null,
"thumbnailPath": "",
"isHidden": false,
"faces": [
{
"id": "8bbb5fcf-609b-49f3-bbff-c43097e39ba6",
"imageHeight": 1920,
"imageWidth": 1440,
"boundingBoxX1": 1005,
"boundingBoxX2": 1085,
"boundingBoxY1": 997,
"boundingBoxY2": 1101
}
]
}
],
"unassignedFaces": [],
"checksum": "wsW5qd6Mo/RtSQjZLU8zrnZ+WYE=",
"stackCount": null,
"isOffline": false,
"hasMetadata": true,
"duplicateId": null
} |
|
I reproduced the issue with that image. There's a discrepancy between when we flip the dimensions based on orientation and when sharp does. In this case, we flip width and height for this image while sharp doesn't. The fix is simple - we know what sharp will orient it to since we have the preview dimensions, so we can just make the crop dimensions consistent with that. Doing this worked for everything when I ran facial recognition, including that image. |
|
Will there be any procedure to fix the processed images or it will by itself when launching the thumbnail job? |
|
With the fix in the next release, you can change the feature photo for a person (it can be the same image) and it will re-generate that person's thumbnail. Re-running thumbnail generation on all assets will also fix it. |
The bug
I reduced large thumbnail sizes and noticed that after thumbnails were regenerated the faces detected off the original image no longer generate thumbnails correctly.
Looking at the values for those faces still showed that the
imageHeightandimageWidthare still the size of the original thumbnail and the bounding boxes are still relative to that, which makes sense, the face detection was ran against the original thumbnail, but face cropping still tries to happen on a differently sized thumbnail against those parameters.The border that's drawn on the face when you hover over it in the photo viewer does correctly account for that though by adjusting for the height/width of the image. https://github.com/immich-app/immich/blob/main/web/src/lib/utils/people-utils.ts#L44
Something similar is never done in handleGeneratePersonThumbnail as far as I can tell.
Some of them outright fail, I assume from trying to crop out of bounds.
Happy to get a development setup up and put in a fix if people think the right approach here is to just normalize against the size of the asset it's actually cropping.
The OS that Immich Server is running on
Debian
Version of Immich Server
v1.99
Version of Immich Mobile App
v1.99
Platform with the issue
Your docker-compose.yml content
Your .env content
Reproduction steps
Additional information
No response
The text was updated successfully, but these errors were encountered: