Some picture's thumbnails are shown as a square in the gallery

[wonx]

Describe the bug

When displaying pictures in the gallery, some of them appear compressed horizontally or vertically, as a square, despite being landscape/portrait. When clicking over that picture, the full picture loads with the correct proportions. Inspecting the metadata, you can see how the resolution appears as 1 x 1 and 0.00MP.

Photo/video (optional) that causes the bug

It seems to be the case with pictures taken with a Moto G (5) Plus. Possible other camera models as well. (I can share a few examples in private).

Screenshots (optional)

Environment (please complete the following information):

• OS: OpenMediaVault 5.6 (based on Debian Buster)
• Browser Google Chrome

Used app version:

• Docker:latest (2022-07-02)

[Tos26]

Hello,

I get exactly the same behavior since the last update of my phone. I don't find the root cause neither the fix yet...

I can provide some samples of those photos if it can help

• Raspberry PI OS (Debian bullseye)
• Firefox browser
• PI gallery 2 v1.9.0
• Not Docker

[garret]

I also have the same issue using the latest version of the container at this time writing running on my Raspberry Pi 4b (Raspberry Pi OS 64bit).

At the moment, I have only put pictures taken with my Google Pixel 6 phone. Most of the portrait pictures thumbnails appear squared, which makes them look weird. Despite that, when clicking on the thumbnail picture, this is shown in the correct proportions when it is in "full screen" mode.

Please let me know if I can help with more testing to solve such issue.

[bpatrik]

Can you provide sample photos for testing? also can you test it on the nightly versions?

[wonx]

IMG_20210820_1.zip

Here, I attached 3 pictures that have this issue. I have only tried with version 1.9.3, which I believe was the latest (I'm using this docker container https://hub.docker.com/r/bpatrik/pigallery2). I have not tried with nightly versions.

[martadinata666]

In my pigallery2 the image shown but there is some logs about exif buffer limits 🤔

The pics on pigpallery

The logs

pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:21 AM[SILLY][DiskManager] scanning directory: zip
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:21 AM[DEBUG][MetadataLoader] Error parsing exif /images/zip/IMG_20210820_171223182_HDR.jpg TypeError: Corrupt JPG, exceeded buffer limits
pigallery2d_app.1.car76vhj32a6@homelab    |     at validateBuffer (/home/debian/pigallery2/node_modules/image-size/dist/types/jpg.js:77:15)
pigallery2d_app.1.car76vhj32a6@homelab    |     at Object.calculate (/home/debian/pigallery2/node_modules/image-size/dist/types/jpg.js:101:13)
pigallery2d_app.1.car76vhj32a6@homelab    |     at lookup (/home/debian/pigallery2/node_modules/image-size/dist/index.js:34:53)
pigallery2d_app.1.car76vhj32a6@homelab    |     at imageSize (/home/debian/pigallery2/node_modules/image-size/dist/index.js:113:16)
pigallery2d_app.1.car76vhj32a6@homelab    |     at /home/debian/pigallery2/src/backend/model/threading/MetadataLoader.js:179:69
pigallery2d_app.1.car76vhj32a6@homelab    |     at FSReqCallback.wrapper [as oncomplete] (node:fs:681:5)
pigallery2d_app.1.car76vhj32a6@homelab    | Warning: DOMParser is not available. It is needed to be able to parse XMP tags.
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:21 AM[DEBUG][MetadataLoader] Error parsing exif /images/zip/IMG_20210820_182614410_HDR.jpg TypeError: Corrupt JPG, exceeded buffer limits
pigallery2d_app.1.car76vhj32a6@homelab    |     at validateBuffer (/home/debian/pigallery2/node_modules/image-size/dist/types/jpg.js:77:15)
pigallery2d_app.1.car76vhj32a6@homelab    |     at Object.calculate (/home/debian/pigallery2/node_modules/image-size/dist/types/jpg.js:101:13)
pigallery2d_app.1.car76vhj32a6@homelab    |     at lookup (/home/debian/pigallery2/node_modules/image-size/dist/index.js:34:53)
pigallery2d_app.1.car76vhj32a6@homelab    |     at imageSize (/home/debian/pigallery2/node_modules/image-size/dist/index.js:113:16)
pigallery2d_app.1.car76vhj32a6@homelab    |     at /home/debian/pigallery2/src/backend/model/threading/MetadataLoader.js:179:69
pigallery2d_app.1.car76vhj32a6@homelab    |     at FSReqCallback.wrapper [as oncomplete] (node:fs:681:5)
pigallery2d_app.1.car76vhj32a6@homelab    | Warning: DOMParser is not available. It is needed to be able to parse XMP tags.
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:21 AM[DEBUG][MetadataLoader] Error parsing exif /images/zip/IMG_20210820_183137520_HDR.jpg TypeError: Corrupt JPG, exceeded buffer limits
pigallery2d_app.1.car76vhj32a6@homelab    |     at validateBuffer (/home/debian/pigallery2/node_modules/image-size/dist/types/jpg.js:77:15)
pigallery2d_app.1.car76vhj32a6@homelab    |     at Object.calculate (/home/debian/pigallery2/node_modules/image-size/dist/types/jpg.js:101:13)
pigallery2d_app.1.car76vhj32a6@homelab    |     at lookup (/home/debian/pigallery2/node_modules/image-size/dist/index.js:34:53)
pigallery2d_app.1.car76vhj32a6@homelab    |     at imageSize (/home/debian/pigallery2/node_modules/image-size/dist/index.js:113:16)
pigallery2d_app.1.car76vhj32a6@homelab    |     at /home/debian/pigallery2/src/backend/model/threading/MetadataLoader.js:179:69
pigallery2d_app.1.car76vhj32a6@homelab    |     at FSReqCallback.wrapper [as oncomplete] (node:fs:681:5)
pigallery2d_app.1.car76vhj32a6@homelab    | Warning: DOMParser is not available. It is needed to be able to parse XMP tags.
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:21 AM[VERBS] GET /pgapi/gallery/content/zip 200 483ms
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:22 AM[SILLY] [SharpRenderer] rendering photo:/images/zip/IMG_20210820_183137520_HDR.jpg, size:480
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:22 AM[SILLY] [SharpRenderer] rendering photo:/images/zip/IMG_20210820_182614410_HDR.jpg, size:480
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:22 AM[SILLY] [SharpRenderer] rendering photo:/images/zip/IMG_20210820_171223182_HDR.jpg, size:480
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:22 AM[VERBS] GET /pgapi/gallery/content/zip/IMG_20210820_183137520_HDR.jpg/thumbnail/480 200 267ms
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:22 AM[VERBS] GET /pgapi/gallery/content/zip/IMG_20210820_171223182_HDR.jpg/thumbnail/480 200 211ms
pigallery2d_app.1.car76vhj32a6@homelab    | 12/16/2022, 10:32:22 AM[VERBS] GET /pgapi/gallery/content/zip/IMG_20210820_182614410_HDR.jpg/thumbnail/480 200 282ms

[bpatrik]

Try increasing the photoMetadataSize in the config.json

duplicate of #398

[wonx]

I have increased that value to "photoMetadataSize": 1524288

However, I don't know how to make pigallery rescan these pictures to update the metadata. (Indexing only adds new pictures).

[bpatrik]

Click on reset database or delete the database manually.

-- Sorry for being brief, sent from my phone.

On Mon, 19 Dec 2022, 19:05 wonx, @.***> wrote:

I have increased that value to "photoMetadataSize": 1524288

However, I don't know how to make pigallery rescan these pictures to update the metadata. (Indexing only adds new pictures).

— Reply to this email directly, view it on GitHub https://github.com/bpatrik/pigallery2/issues/516#issuecomment-1358040549, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZKA5WAJ3MXOGFUVXFM533WOCPWRANCNFSM52WWMLFQ . You are receiving this because you commented.Message ID: @.***>

[wonx]

Isn't there a way to reset or rescan a specific folder? My library is fairly large and it would take hours to repopulate the database.

EDIT: There's no need to rebuild the database, after a while, I entered pigallery2 again, and now all the previews have the correct proportions. Thanks!

[garret]

I have increased that value to "photoMetadataSize": 1524288

However, I don't know how to make pigallery rescan these pictures to update the metadata. (Indexing only adds new pictures).

So is this the solution for this issue? Didn't understood the conclusion... 🙃

[bpatrik]

The app does not ready the whole image when it searches for the metadata for better performance. Some images have a huge metadata part that is bigger than the default size that app reads. With that flag you can increase this buffer size. It's a shortcomings of the app to not detected the buffersize automatically.

-- Sorry for being brief, sent from my phone.

On Tue, 20 Dec 2022, 06:33 garret, @.***> wrote:

I have increased that value to "photoMetadataSize": 1524288

However, I don't know how to make pigallery rescan these pictures to update the metadata. (Indexing only adds new pictures).

So is this the solution for this issue? Didn't understood the conclusion... 🙃

— Reply to this email directly, view it on GitHub https://github.com/bpatrik/pigallery2/issues/516#issuecomment-1358862401, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZKA5UG2L3MRONJPZI5D5DWOFAKTANCNFSM52WWMLFQ . You are receiving this because you commented.Message ID: @.***>

[garret]

Ok thanks and what about the solution to this issue? Has not been found yet? Cannot really understand from reading all the past messages :)

[bpatrik]

It's not a bug. It's a misconfiguration issue. You need to change the value of photoMetadataSize

-- Sorry for being brief, sent from my phone.

On Tue, 20 Dec 2022, 11:30 garret, @.***> wrote:

Ok thanks and what about the solution to this issue? Has not been found yet? Cannot really understand from reading all the past messages :)

— Reply to this email directly, view it on GitHub https://github.com/bpatrik/pigallery2/issues/516#issuecomment-1359148039, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZKA5QIJBF3ULCZUPOTL53WOGDEBANCNFSM52WWMLFQ . You are receiving this because you commented.Message ID: @.***>

[garret]

Ok and how do I know to which value should I change? Is there a suggested value?

[wonx]

Yes, for me changing that value in config.json solved the issue. However, I don't know if that means that the default value should be higher, in order to prevent this issue in other users.

[garret]

I have changed the "photoMetadataSize" to 1524288, restarted the container, regenerated all the thumbnails but I still have the issue present with the same pictures.

[bpatrik]

@garret There is no recommended value. You need to set higher than your biggest metadata(if you really want to be nitpicking you can use some 3rd party tool to extract the exif/iptc, etc.. data from your photos, measure the size of that and find the max among all your photos. ). No need to regenerate thumbnails, these should have the correct aspect ration. The issue is with the metadata loader, so you need to reindex your gallery. (you can trigger reindex in one folder if you change a file there. Given that your file system supports that)

If reindex does not help, can you try setting that number even higher? If I remember correctly, you cannot set it too high to break the app. If that does not help can you send me a photo with the issue?

@wonx I dont want to increase the default value as it is usually not a problem, but would rather slow down everyone's indexing speed. Also a long term solution to this problem is #277

[Tos26]

hello,

I performed the process described above (photoMetadataSize) and the thumbnails remain squared. So, I compared 2 photos: one with good ratio and one as square.

For both, the metadata size is the same, 1.3 kB.

After editing the metadata, the only difference I found is on the Orientation parameter (Except the values for ExposureTime and so on which are specific to the photo...): Bad ratio => Orientation = Unknown (0) Good ratio => Orientation = Horizontal (Normal)

Can this value unknown play a role to the thumbnails ratio ?

You can find the files attached to help to understand this behavior.

Thank you in advance for your support

[Tos26]

Hello,

Following my previous post, I edited the metadata of a photo to change the Orientation parameter and set it to Horizontal (Normal). This action fixed the issue and the thumbnail is now properly displayed.

Before :

After :

So I think this parameter not filled is the root cause of the bad ratio of thumbnails. Is it possible to propose a patch to fix this ?

[Tos26]

Last information from my investigations:

Here is the log after new image addition:

Hope it can help to solve the problem.

Thank you

[bpatrik]

Thanks. That looks odd. I will take a look once I get back to my comp.

Tos26 @.***> ezt írta (időpont: 2023. febr. 4., Szo 1:44):

Last information from my investigations:

Here is the log after new image addition:

[image: image] https://user-images.githubusercontent.com/23366980/216681988-38b60215-4348-47e2-978a-6bd75180613e.png

Hope it can help to solve the problem.

Thank you

— Reply to this email directly, view it on GitHub https://github.com/bpatrik/pigallery2/issues/516#issuecomment-1416259953, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABZKA5QGGEFOAQFW44CJFVTWVVGXJANCNFSM52WWMLFQ . You are receiving this because you commented.Message ID: @.***>

[Tos26]

@bpatrick Hello, have you been able to take a look on this issue ?

[bpatrik]

Looked into the photo. It says 213263882-4b67488c-aaf1-451e-a0a3-ab0392af847e.jpg for

TypeError: Invalid JPG, marker table corrupted
    at validateBuffer (<...>\node_modules\image-size\dist\types\jpg.js:81:15)
    at Object.calculate (<...>\node_modules\image-size\dist\types\jpg.js:101:13)
    at lookup (<...>\node_modules\image-size\dist\index.js:34:53)
    at imageSize (<...>\node_modules\image-size\dist\index.js:113:16)
    at <...>\src\backend\model\threading\MetadataLoader.js:180:69
    at FSReqCallback.wrapper [as oncomplete] (node:fs:681:5)

that leads to the following in the image-size lib:

function validateBuffer(buffer, index) {
    // index should be within buffer limits
    if (index > buffer.length) {
        throw new TypeError('Corrupt JPG, exceeded buffer limits');
    }
    // Every JPEG block must begin with a 0xFF
    if (buffer[index] !== 0xFF) {
        throw new TypeError('Invalid JPG, marker table corrupted');
    }
}

Note: I'm not owing the image-size lib, just using it. Based on this it looks like the photo has a broken exif data. The other photo looks fine.

Do you edited these photos in any form or were they created with an old camera?

[bpatrik]

Hello,

Following my previous post, I edited the metadata of a photo to change the Orientation parameter and set it to Horizontal (Normal). This action fixed the issue and the thumbnail is now properly displayed.

Before :

After :

So I think this parameter not filled is the root cause of the bad ratio of thumbnails. Is it possible to propose a patch to fix this ?

How did you edit the metadata? Opening it with a text /hexa editor and only changing 1 byte or did you use an external tool that potentionally rewrite the whole exif/iptc data of the photo (and fixed the bad exif block)

[bpatrik]

Adding more data:

This is what the app's exif reader sees:

good photo, 213262712-cf5051a7-d376-48ec-8bf8-9bf67805481f.jpg:

ExifData {
  startMarker: { openWithOffset: [Function: openWithOffset], offset: 0 },
  tags: {
    ImageWidth: 4608,
    ImageHeight: 2128,
    Make: 'realme',
    Model: 'realme 3 Pro',
    Orientation: 1,
    XResolution: 72,
    YResolution: 72,
    ResolutionUnit: 2,
    ModifyDate: 1593168059,
    YCbCrPositioning: 1,
    InteropIndex: '',
    ExposureTime: 0.000348,
    FNumber: 1.7,
    ExposureProgram: 0,
    ISO: 250,
    DateTimeOriginal: 1593168059,
    CreateDate: 1593168059,
    ShutterSpeedValue: NaN,
    ApertureValue: 1.16,
    BrightnessValue: NaN,
    ExposureCompensation: 0,
    MaxApertureValue: NaN,                                               
    MeteringMode: 0,
    Flash: 16,
    FocalLength: 4.28,
    SubSecTime: '492000',
    SubSecTimeOriginal: '492000',
    SubSecTimeDigitized: '492000',
    ColorSpace: 65535,
    ExifImageWidth: 0,
    ExifImageHeight: 0,
    SensingMethod: 0,
    SceneType: 0,
    ExposureMode: 0,
    WhiteBalance: 0,
    FocalLengthIn35mmFormat: 0
  },
  imageSize: { height: 2128, width: 4608 },
  thumbnailOffset: undefined,
  thumbnailLength: undefined,
  thumbnailType: undefined,
  app1Offset: 24
}

bad photo, 213263882-4b67488c-aaf1-451e-a0a3-ab0392af847e.jpg:

ExifData {
  startMarker: { openWithOffset: [Function: openWithOffset], offset: 0 },
  tags: {
    ImageWidth: 4608,
    ImageHeight: 2128,
    Make: 'Realme',
    Model: 'realme 3 Pro',
    Orientation: 0,
    XResolution: 72,
    YResolution: 72,
    ResolutionUnit: 2,
    ModifyDate: 1654876257,
    YCbCrPositioning: 1,
    InteropIndex: '',
    ExposureTime: 0.000536702,
    FNumber: 1.7,
    ExposureProgram: 0,
    ISO: 160,
    DateTimeOriginal: 1654876257,
    CreateDate: 1654876257,
    ShutterSpeedValue: NaN,
    ApertureValue: 1.16,
    BrightnessValue: NaN,
    ExposureCompensation: 0,
    MaxApertureValue: NaN,
    MeteringMode: 0,
    Flash: 16,
    FocalLength: 4.28,
    SubSecTime: '868000',
    SubSecTimeOriginal: '868000',
    SubSecTimeDigitized: '868000',
    ColorSpace: 65535,
    ExifImageWidth: 0,
    ExifImageHeight: 0,
    SensingMethod: 0,
    SceneType: 0,
    ExposureMode: 0,
    WhiteBalance: 0,
    FocalLengthIn35mmFormat: 0
  },
  imageSize: undefined,
  thumbnailOffset: undefined,
  thumbnailLength: undefined,
  thumbnailType: undefined,
  app1Offset: 590
}

This is how the app extracts photo size:

https://github.com/bpatrik/pigallery2/blob/45e3a8fd5251e994100a50b3b2dc51040f33c62c/src/backend/model/threading/MetadataLoader.ts#L194-L220

You can see, that the fields it tries to recover the original size are missing from the bad photo. I will try to add ImageWidth , ImageHeight and hope that it always contains the right value and does not break the app for others. Reading this forum its not always the case: https://exiftool.org/forum/index.php?topic=10818.0

This fix will work for this particular photo. If you see similar issues with other photos, please use a 3rd party tool to fix the exif data in your photos.

[Tos26]

@bpatrick

Thank you for this analysis and I agree with the conclusions. I think your modification can fix the issue.

Some answers to your questions:

How did you edit the metadata? Opening it with a text /hexa editor and only changing 1 byte or did you use an external tool that potentionally rewrite the whole exif/iptc data of the photo (and fixed the bad exif block)

I used an external tool to read and set the horizontal parameter, so I guess it rewrote the whole metadata.

Do you edited these photos in any form or were they created with an old camera?

My phone is a Realme 3 pro, running Android 11, not so old. All photos from this phone have the same issue in Pigallery2 since an update of the firmware of my phone.

[bpatrik]

@BPatrick

Thank you for this analysis and I agree with the conclusions. I think your modification can fix the issue.

Some answers to your questions:

How did you edit the metadata? Opening it with a text /hexa editor and only changing 1 byte or did you use an external tool that potentionally rewrite the whole exif/iptc data of the photo (and fixed the bad exif block)

I used an external tool to read and set the horizontal parameter, so I guess it rewrote the whole metadata.

That can be a problem.

Do you edited these photos in any form or were they created with an old camera?

My phone is a Realme 3 pro, running Android 11, not so old. All photos from this phone have the same issue in Pigallery2 since an update of the firmware of my phone.

I would consider it 'new' and I would expect it to 'just work'.

Is the problem still there on the latest nightly build?

[Tos26]

Hello,

I didn't find the nightly build, where can I find it ?

[Tos26]

Hello,

I installed the version 2.0.0 et I can confirm now that this issue is solved: All the thumbnails have the good ratio. I think this ticket can be closed.

@bpatrik => One comment: It could be helpful to update the readme.md and change the expected version number of node.js for the 2.0.0 version (>=18; <20) for those don't use Docker, like me.