Incorrect image size determination with inferRemoteSize() or inferSize=true when JPEG image has specific metadata

[kadykov]

Astro Info

Astro                    v4.16.14
Node                     v20.18.0
System                   Linux (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

When using astro to generate a static site, I've encountered an issue where the size of remote images is incorrectly determined using inferRemoteSize() or by passing inferSize=true to the Image or Picture component.

In the minimal reproducible example, a sample photo with a size of 3730 x 5535 pixels is incorrectly reported as 48719 x 62538. This causes the Picture or Image image optimization to fail with the error "Processed image is too large for the HEIF format".

 generating optimized images 
[CouldNotTransformImage] Could not transform image `https://live.staticflickr.com/65535/54163807312_d8456912ba_o_d.jpg`. See the stack trace for more information.
  Hint:
    This is often caused by a corrupted or malformed image. Re-exporting the image from your image editor may fix this issue.
  Error reference:
    https://docs.astro.build/en/reference/errors/could-not-transform-image/
  Location:
    /workspaces/astro-image-size/node_modules/astro/dist/assets/build/generate.js:134:21
  Stack trace:
    at generateImageInternal (file:///workspaces/astro-image-size/node_modules/astro/dist/assets/build/generate.js:134:21)
    at async file:///workspaces/astro-image-size/node_modules/p-queue/dist/index.js:187:36
  Caused by:
  Processed image is too large for the HEIF format
    at Sharp.toBuffer (/workspaces/astro-image-size/node_modules/sharp/lib/output.js:163:17)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async generateImage (file:///workspaces/astro-image-size/node_modules/astro/dist/assets/build/generate.js:71:28)

I've tried adjusting export options in Darktable, such as resolution, color space, and applied effects, but the reported image size remains incorrect. However, if I remove all metadata from the image, the size is correctly determined.

It appears that specific metadata in the JPEG file is conflicting with the way inferRemoteSize() determines image size.

What's the expected result?

inferRemoteSize() and inferSize=true should correctly determine the image size, regardless of metadata.

Link to Minimal Reproducible Example

https://github.com/kadykov/astro-image-size

Participation

• I am willing to submit a pull request for this issue.

[ematipico]

Can you please provide a valid reproduction? The one you shared is empty

[github-actions]

Hello @kadykov. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with needs repro will be closed if they have no activity within 3 days.

[Princesseuh]

The repro isn't empty, it's a remote address in index.astro

[kadykov]

@ematipico The minimal reproduction example contains only this code:

---
import { inferRemoteSize } from 'astro:assets';
const {width, height} = await inferRemoteSize("https://live.staticflickr.com/65535/54163807312_d8456912ba_o_d.jpg");
---
<p>The real size of the image is 3730 x 5535, but `inferRemoteSize()` determines it as {width} x {height}</p>

The output is rendered here as:

The real size of the image is 3730 x 5535, but `inferRemoteSize()` determines it as 48719 x 62538

[kadykov]

I found this comment in jpeg reader, that could explain this bug:

// NOTE: we only support baseline and progressive JPGs here
// due to the structure of the loader class, we only get a buffer
// with a maximum size of 4096 bytes. so if the SOF marker is outside
// if this range we can't detect the file size correctly.

[kadykov]

The issue was resolved by correcting the handling of non-0xFF blocks, as shown in the linked pull request.

I am confused about the warning in the header regarding incorrect handling of the SOF marker when it falls outside of the 4096-byte buffer size. In the example file, the metadata size is approximately 68.4kB, and the code correctly determines the image dimensions. I wonder if the warning is outdated or if there is a specific scenario where the code would fail to handle the SOF marker correctly. Could someone please clarify the purpose of this warning and whether it is still relevant?