WP generates duplicate pictures after Upload

[fotodrachen]

After upload a picture different sizes of smaller versions are generated.
Default-steps (longest side):

150 - Thumbnail
300 - Medium
768 - Medium large

1024 - Large
1536 - ?
2048 - ?

To minimize the diskspace I use the 1536-size als 'full' upload. So no smaller 1536-version has to be generated.
In some cases the size 'large' (1024) is generated twice.

• only for portrait, not for landscape (hight > width)
• only for aspect-ratio 4:3 (1.333..)

4:3 is the format of MFT (micro four-thirds) cameras. When I use the options 'original' (from raw) or '4:3' with the crop-tool in darktable and limit the size to 1536 pixels on darktable-export = WP-upload, this error happens.

Uploading the size 1153x1536 Pixel generates the sizes 768x1023 AND 769x1024.

Example

Use this as full:
​https://fotodrachen.de/wp/wp-content/uploads/Lohbluete_20230920_0131.jpg

Results:
​https://fotodrachen.de/wp/wp-content/uploads/Lohbluete_20230920_0131-768x1023.jpg
​https://fotodrachen.de/wp/wp-content/uploads/Lohbluete_20230920_0131-769x1024.jpg

[opurockey]

Default subsizes of images for 1024 and 768 like 1024*1024 and 798*0;

WordPress uses aspect ratio preservation (proportional scaling) for soft-crop sizes. The original image is 1153 × 1536 (portrait orientation — height > width).
The core ratio from the original:

width/height = 1153/1536 ≈ 0.7507
height/width = 1536/1153 ≈ 1.3321

1024×1024 → produces 769×1024
This is a soft crop (constrain within a bounding box). WordPress asks: which dimension hits the limit first?

Try fitting to width 1024:
height = 1024 × (1536/1153) = 1024 × 1.3321 = 1363.9 ❌ exceeds 1024

Try fitting to height 1024:
width = 1024 × (1153/1536) = 1024 × 0.7507 = 768.72 → 769 ✅ fits

Since it's a portrait image, height is the constraining dimension. So height is locked to 1024, and width is derived from the ratio → 769×1024.

768×0 → produces 768×1023
The 0 means no height constraint — only width is fixed. Height always scales proportionally.

height = 768 × (1536/1153) = 768 × 1.3321 = 1023.05 → 1023
Width is locked to 768, height is derived from the ratio → 768×1023.

Why 769 vs 768? (the subtle difference)
1024×1024 Height locked to 1024. So 1024 × (1153/1536) = 769
768×0 Width locked to 768. So 768 × (1536/1153) = 1023

The multipliers are different (1024 vs 768), so the resulting constrained dimension differs by 1 pixel after rounding. They're both correct — they just start from a different anchor dimension.

[siliconforks]

Replying to opurockey:

width/height = 1153/1536 ≈ 0.7507
height/width = 1536/1153 ≈ 1.3321

I think the problem here is that the image width:height ratio is not exactly 3:4.

Shouldn't the image be 1152x1536 instead of 1153x1536?

If the image were 1152x1536 it would be exactly 3:4 and it would generate Lohbluete_20230920_0131-768x1024.jpg, instead of getting two images Lohbluete_20230920_0131-768x1023.jpg and Lohbluete_20230920_0131-769x1024.jpg.

[fotodrachen]

I think the problem here is that the image width:height ratio is not exactly 3:4.

Yes, 1536:1153 (1,3321) is not exactly 4:3 (1,3333) but this is what I get from darktable crop "original". Original-sensor-size for MFT is 5220:3912 (1,3343).

Other raw-development-tools may have other rounding deviation.
But that does't matter. WordPress should be able to downsize every free selected aspect ratio to ONE picture for each level.
Why is 1536:1153 a problem and 1153:1536 is not?

[siliconforks]

Replying to fotodrachen:

But that does't matter. WordPress should be able to downsize every free selected aspect ratio to ONE picture for each level.

It is generating one picture for each level:

thumbnail	Lohbluete_20230920_0131-150x150.jpg
medium	Lohbluete_20230920_0131-225x300.jpg
medium_large	Lohbluete_20230920_0131-768x1023.jpg
large	Lohbluete_20230920_0131-769x1024.jpg

Note that the medium_large size works differently than the medium and the large sizes. The medium and large sizes look at the longest side of the original image and reduce that to 300 and 1024 respectively. The medium_large size always looks at the width of the original image and reduces that to 768.

[fotodrachen]

Replying to siliconforks:

Note that the medium_large size works differently than the medium and the large sizes.

OK, if that was the goal, then the goal has been achieved.

• medium_large has width 768 (768x1023)
• large has longest 1024 (769x1024)

Sorry for the noise.
I had assumed it was a consistent cascade or pyramid structure with a factor of approximately 2 between each level.
I’m familiar with this kind of setup from tiled web services that use aerial imagery. It’s used there to speed up the services.
But I don't understand the point of generating two nearly identical images that differ in size by just one row of pixels.
There are surely smarter solutions, such as having both sizes link to the same file within a tolerance.
I have 173 such duplicates on my website that are taking up disk space.

[siliconforks]

Replying to fotodrachen:

I had assumed it was a consistent cascade or pyramid structure with a factor of approximately 2 between each level.

By default, it does not really work like that, but if you want it to work like that, you could probably just edit the medium_large_size_h option in your database and change it from 0 to 768. Then the medium_large size should behave similarly to the medium and large sizes.

But I don't understand the point of generating two nearly identical images that differ in size by just one row of pixels.
There are surely smarter solutions, such as having both sizes link to the same file within a tolerance.

It is probably possible to write a plugin that does that. For example, you could use the image_resize_dimensions filter to skip any images that are similar in size to images already generated.

A simpler alternative would be to simply remove any sizes that you don't think are necessary. There are existing plugins which can do that, e.g., ​Disable Media Sizes.

[fotodrachen]

Replying to siliconforks:

It is probably possible to write a plugin that does that. For example, you could use the image_resize_dimensions filter to skip any images that are similar in size to images already generated.

A simpler alternative would be to simply remove any sizes that you don't think are necessary. There are existing plugins which can do that, e.g., ​Disable Media Sizes.

What WordPress does with the images isn’t really documented and happens in the background.
You can only see the generated files if you look in the uploads folder via FTP.
Now that I understand what’s going on, I can pay attention to this when uploading images.
I prefer not to change the default settings, because they must serve a purpose and other parts of the code expect these sizes.
In the future, I will use specific sizes and aspect ratios for my images.
I’ve summarized what to look out for in my blog and addressed it to German-speaking Darktable users.

​https://fotodrachen.de/groesse-und-format-der-bilder-in-wordpress/