codingjoe / django-pictures

Responsive cross-browser image library using modern codes like AVIF & WebP

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

images are converted incorrect

vchrisb opened this issue · comments

First, thank you for you efforts! A test migration from django-stdimage did work for me.

My model is configured with aspect_ratios=[None, '4/3'], file_types=['WEBP'], pixel_densities=[1, 2], but all images are converted wrongly.

e.g. an original image has a dimension of 4288x2848 and is a JPG.

for the "none" ratio, there are images scaled from 100w to 2400w, but all (beside 800w,1600w and 2400w) are identical and have a dimension of 99x66.
800w, 1600w and 2400w are also identical but 799x531 and in good quality.

for the "4/3" ratio, all images have the correct image dimension, e.g. 800x600 for 800w, but are in a very poor quality.

I looked at the sources, but did not figure out what leads to this outcome.

hm… interesting, let me check…

So, I checked and yes, there seems to be an error for None (intrinsic aspect ratio).

Regarding quality: We render those images with pillows defaults. If you are on a high-res display, your picture app might blow up the pixels. However, in a browser you'll get the proper 2x or 3x experience. That being said, WebP uses VP8, which is very outdated. If you are looking for optimal quality, AVIF is MUCH better.

Found it! It smelled like state leaking and it was ;) I'll create a patch…

Thank you.
Images generated for "4/3" are very blurry, even when opening in Chrome.
The None version on the other hand (for the same width) is crisp.

"4/3" in 800w:
image

"None" in 800w:
image

@vchrisb this is also due to state leakage. We accidentally reduce the size of the source image… Which means all images that follow will be bad.

I'm running local tests on my patch right now… but my poor M1 CPU is too slow :P Should have gotten an M1 Ultra…

btw, Is there actually an option (or planned) to define the sizes that are getting generated?
I only will use it with restframework and and 4 different sizes are enough for my use case. Generating and storing 18 different images for the example above is a bit wasteful. ;)

Hm… are you sure you only need 4 different sizes? Pixel densities and screen sizes can vary drastically. You might need more variations than you think. However, you can set your grid from 12 to 6. This will decrease the number of sizes. Generally, I created this package under the assumption that storage is cheap and bandwidth isn't.

I am planing, that you can use the template tag without the actual file model. Some might use a proper picture CDN.

Would you do the honors to review #20 ?

I might reconsider the the required sizes. ;) Haven't spend too much time looking into it, yet.
I do store/serve images on/from GCP using django-storages, make the image variants available using django restframework and render html in the browser.