Why product_image is cropping the images?
I do not see any case where this could be a feature as default behavior. All products and images are diverse width and height.
Tryton always should contain the true data of the company, not an altered cropped version.
If the problem is that in a website it should be rendered in equal dimensions, it can be addressed with css or with some method on images that generate a cache with custom dimensions.
Also, this behavior is not documented on docs:
The images are stored as `JPEGs <https://en.wikipedia.org/wiki/JPEG>`_ format
and with a maximal horizontal and vertical size of 2048 pixels.
I propose to remove the crop and use size of the _resize as width to return image based on a ratio from the original.
I’m wondering also if the 2048 max restriction is correct as required or should be only a default value allowing to be deactivated. For example, for high detailed images like blueprint plans. So why limiting to 2048 if screen market is growing on usage of more pixels (4k screens on most industrial - engineering laptops)?
Thanks for your answer, but most of the responses provided are assuming product_image is only used for ecommerce/webshop.
There also can be internal tooling platforms where this big images are needed, and as the name suggest, this module should be valid for product and not only for ecommerce usages.
What about books? Sofas? Films? They have their own ratio. Try to upload a book cover as image and you will see that most times (depending on the book), the title and author is half cropped. A shop for jewelry, It’s not normal to crop the same for a ring photo and a necklace on the center of the image. The necklace most important part is on the bottom.
I can understand the standardize need but I think the best is to find some solution to cover all use cases, so: I propose to allow some image configuration to toggle cropping and if so, define the ratio or size desired.
Normally for the designer, the box where the image goes is standard and they have to find the best way to display it depending on the use case.
Instagram post grid is square but when you open the image is in another ratio.
Pinterest grid is equal in width but flexible in height
But it’s leaving great usage cases for the product_image outside.
You are reducing the functionality of a module to a simple cropping function. What about the thumbnails, the cache and resizes also.
I want this standardisation sometimes, If I sell books I want to display in the ecommerce all the book cover, take a look on any book ecommerce, so the original size should be maintained. I love the resize option to optimize for web but maintaining the ratio.
Why are you against of making the module more generic and available for more use cases, while maintain the same functions?
This also makes the company have the same photos on the company disk (original) and on Tryton.
For another project I just made a standard ratio image, no matter if the ratio is (2,2) squared on (3,2), but at least it’s not cropping a image that can contain valuable information on the cropped part, it only adds white padding on the sides to make it fit the ratio.
In many cases, images might have essential information that can be lost if cropped. By adding white padding, the original content remains intact, and the image still adheres to a standard aspect ratio. This approach ensures visual consistency without sacrificing information.
I think this option could be valid also by having a default ratio on product config, and allowing to customize it on each product.
I leave here the code I used to add the padding, but it’s not yet integrated with product_image.
Also you are assuming that the images provided are not standard, the image professionals normally provide you with all the images in the standard format, if all your images in your company are the same ratio, they are standard in your own business without applying any transformation. As I already demonstrated some comments ago, the standard ratio of a sector is not the same for all sectors (see books).
Indeed if we used an image format with transparency support. I would accept that instead of cropping (fit) image, we use padding with a transparent background but only for images out of the ratio by a specific value like 10%.
The available image formats with this supports that supports transparent background and is supported by Pillow are JPEG 2000 and WebP. I think WebP is the best choice for now.
But in order to support different format, we must have a migration path and even better a backward compatibility. So it will require to support different format in the routes and cache.
But also how to manage request for JPEG images with transparent background.
I can confirm, as a publisher, that squares are not the only choice for web product images for books.
The ideal solution for a web usage would be for us to store the images as they are entered, and rely on another service to resize them with vips, store them in cache or in S3 in different size and formats as necessary for the various web stores exposing a catalog.
Yes, that’s the same approach services like imgix are using, store your full images and serve it caching the requested url. That way, you can customize your standard for that image based on what web developer decide which will perform better for that website.
For me, as I started saying in the first message, the best approach is to not transform the image on the upload to Tryton as we always want the real data on Tryton. Latter we can talk about how we can create such URL that transform (crop / fit / whatever) the image and cache them.