Handle optimizing existing original image again

[swissspidy]

• Do not re-optimize the original again if there is already an optimized version
• But what if the quality setting changed in the meantime, i.e. from 60 to 80? Generate another optimized version or edit the existing one? How to keep track of the multiple versions?

[erikyo]

Yep you are right, it's generally advisable to avoid multiple rounds of compression, especially with different formats (e.g., compressing from highly compressed JPEG to WebP). In such cases, artifacts tend to accumulate and it didn't lead to a good result to change the initial format.

Take a look at this -> https://cloudinary.com/blog/why_jpeg_is_like_a_photocopier

imho, keeping the original file is a good practice (the original one and not the resizes). This allows for the possibility to revert decisions and provides a baseline for comparison. perhaps adding a field to the attachment meta such as "source_media" might be enough.

[swissspidy]

Yep you are right, it's generally advisable to avoid multiple rounds of compression, especially with different formats (e.g., compressing from highly compressed JPEG to WebP)

Agreed. That's something I haven't fully implemented yet. Ideally before you first upload an image, we should check whether the image has a reasonable size and if not, force it to optimize.

imho, keeping the original file is a good practice (the original one and not the resizes). This allows for the possibility to revert decisions and provides a baseline for comparison. perhaps adding a field to the attachment meta such as "source_media" might be enough.

Yep, that's already implemented.

In this issue here, which I opened after just having a discussion with @ntsekouras, I want to figure out how to address this case:

1. You insert an existing image A on page X and also on page Y.
2. You edit page X in the editor, you click to compress that image with quality 80, and a new compressed version (image B) is uploaded
3. You edit on page Y, you still see image A. Now you compress it with quality 60.
4. Is a new image C uploaded? What happens to image B? How can the user manage all these different versions of the image?

[ntsekouras]

Maybe an approach would be to keep just one compressed version and in the above scenario, we would delete the previous compressed one and keep the new one. In order to do that though it would probably require to update the core Image block to check if there is a compressed version and pick the proper image url(and maybe some additions in how the srcset is produced(🤔 ) ?

If the above is viable, we would keep all the other attributes(caption, title, etc..) in sync too.

[swissspidy]

In order to do that though it would probably require to update the core Image block to check if there is a compressed version and pick the proper image url

I would probably just replace the file on disk, but not actually upload a new attachment to the database. Then you don't have to worry about keeping things in sync etc.
It might warrant an "Are you sure?" dialog to let the user know that existing images on their site will be replaced with the new version. While in this case the previous version with quality 80 is replaced with the 60 one, it's not really data loss (you can always re-compress the original at 80 to get it back).

Caveat: what happens if you convert the image to another file format instead?

Some alternatives:

• Simply upload a new version, do not touch any other versions. User may end up with X different images in different quality settings. Not the end of the world, but clutters the media library and disk a little bit.
• ..?

[erikyo]

Personally, I would prefer an approach where a new compressed version of the image is created rather than overwriting it. The main reason is that, in some cases, optimization may be specific to a particular page or size.

For example, let's imagine having an image used both as a hero on one page and as a cover for a link to that page. I might want to compress the image used as a cover more heavily, as it's placed on a page with many images and is also used as a small cover with an overlay. In this case, overwriting the compressed image could lead to an unintended side effect on the display of the hero.

Duplicating the optimized images would allow for maintaining a version specific to each use without inadvertently affecting other parts of the site. Additionally, it would be helpful to keep attributes such as caption and title synchronized.

[swissspidy]

That's a good point with different use cases 👍

Additionally, it would be helpful to keep attributes such as caption and title synchronized.

Do you mean true (unidirectional or bidirectional?) synchronization or just one-off copying these attributes upon compression?

[erikyo]

Maybe even in this case the "title" or the "description" could change depending on the context so maybe better the latter you proposed. I'm not a SEO expert but i guess is a good to have to be able to have different attachment details also in this case.

[swissspidy]

Another use case I'd like to cover here:

1. Upload image A to a post
2. Compress image A with quality 80 -> results in image B
3. Now if you want to compress image B with quality 60 -> should it compress A with quality 60 or B with quality 60 (which would essentially be A with quality 48 (0.8 * 0.6))

[erikyo]

IMHO - should it compress A with quality 60 (to avoid photocopy effect)

Compressed images should not be reused for reprocessing (that's the reason why many people are complaining about webp quality, while compressing almost indecent jpgs into webp, resulting in overlapping compression artifacts)