Why cropping images on product_image?

Feature Ideas
1

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.

1 Like
2

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)?

3

To standardize format. And the square format is the most common because it is the more flexible for designer.

Because this will make the website perform very badly.

I have seen any webshop platform allowing more.

It makes no sense to store blueprint plans as JPG image.

But more of the ecommerce is done on mobile.

4

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.

for example,

  • 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.

1 Like
5

The point is standardisation. If you do not want that, use something else.

6

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.

1 Like
7

Then why not making it configurable?

8

Yes they all use a square design.

Because a square is the only format for which a requested size is unambiguous.

9

Just checked a random amazon book page, and it does not use a square design:

imatge
imatge1231×463 104 KB

Event you can see that the miniatures on the page are shown in squared size which crops the content of the text.

10

Just my first 3 top results in google search:

imagen
imagen643×713 139 KB

imagen
imagen696×643 116 KB

imagen
imagen628×828 161 KB

11

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.

@classmethod
def fit_into_frame(cls, image, target_ratio=(3, 2)):
    img = PIL.Image.open(io.BytesIO(image))
    width, height = img.size

    original_ratio = width / height
    desired_ratio = target_ratio[0] / target_ratio[1]

    if original_ratio < desired_ratio:
        new_width = int(height * desired_ratio)
        new_height = height
    else:
        new_height = int(width / desired_ratio)
        new_width = width

    left_padding = (new_width - width) // 2
    top_padding = (new_height - height) // 2

    new_img = PIL.Image.new('RGB', (new_width, new_height), (255, 255, 255))
    new_img.paste(img, (left_padding, top_padding))

    return new_img
12

The main issue is that you arbitrary fill with blank.
That’s one more reason that standard module uses crop so it makes no assumption about a potential background.

13

Crop is making an assumption which is worse, it’s saying that some part of the image is not important.

If that’s a problem, it can be personalized in product config allowing:

  • Transparent background
  • hex color
  • Fill with the most dominant edge color of the image (I already have the function to do it).

Apart from that I think that the following configs can be added in conjunction with the previous:

  • Crop option (actual)
  • Don’t apply any transformation
  • Fit image to frame (allow the user to select a ratio, like my previous comment)
14

You miss the all point of standardisation.

15

For me the most important is to don’t transform, as people often invest in good photographers for their products. Normally those professional adjust the results to the expectations of the clients.

16

Not with fit_to_frame.

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).

17

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.

18

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.

2 Likes
19

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.

1 Like