Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[5.x] Media Cache thumbnails #43272

Closed
brianteeman opened this issue Apr 14, 2024 · 16 comments
Closed

[5.x] Media Cache thumbnails #43272

brianteeman opened this issue Apr 14, 2024 · 16 comments

Comments

@brianteeman
Copy link
Contributor

Steps to reproduce the issue

Add some png and jpg images to the /images folder

Go to the Filesystem local plugin and enable cache
image

Compare the file sizes in /images and /media/cache/com_media/thumbs

Expected result

ALL the files in the cache have been reduced in both dimension and filesize

Actual result

All the file dimensions have been reduced but the filesize has in some cases increased

System information (as much as possible)

I have prepared a zip containing 5 images so that we can compare with the same image

filename original filesize kb cache filesize kb reduced
image1.png 44.05 105.85
image2.png 452.83 75.3 ✔️
image3.png 30.47 93.39
image4.jpg 250.94 27.79 ✔️
image5.jpg 114.55 26 ✔️
image6.jpg 260.38 34.84 ✔️

Test Images

test.zip

Comments

I appreciate that the original images might have been saved with different compression algorithms and ratios. These are just a random selection of images on my hdd.

In all cases the file has been reduced in dimensions so at the very least it would be reasonable to assume that its a bug if the reduced file is double the storage size of the original

@Fedik
Copy link
Member

Fedik commented Apr 14, 2024

It kind of expected, for PNG.
It not a bug.
I would say: it is how algorithm work for PNG.

In theory we can try to play with higher compression, but still, in some cases PNG can be bigger.

@brianteeman
Copy link
Contributor Author

How can it be expected to reduce the dimensions of a png and yet the filesize increases by 300%

That completely defeats the objective of the thumbnail creation

/me doesnt understand how it is not a bug - please can you explain

@Fedik
Copy link
Member

Fedik commented Apr 14, 2024

It is PHP side (PHP GD), not Joomla.
All we can do is try to set "quality" https://www.php.net/manual/en/function.imagepng.php different from default.

How can it be expected to reduce the dimensions of a png and yet the filesize increases by 300%

Depend from amount of detail the image have, it can happen for PNG in any application, not only PHP

@brianteeman
Copy link
Contributor Author

As the purpose of creating the thumbnail is to crerate a fast loading version of the image and this thumbnail will only be displayed in the media manager why not always set the compression to the maximum.

Otherwise any png that has been optimised before uploading to joomla will generate a larger file when resized

@brianteeman
Copy link
Contributor Author

The code exists already to select the image quality. Its just not used at all so the compression defaults to 0 :(

@Fedik
Copy link
Member

Fedik commented Apr 14, 2024

It a bit tricky, PNG have a range -1 ... 9, JPG -1 .. 100.
Need an extra logic, extra code, but should be possible.
Someone can try.

I just can't say how much it will really help. For cases when User upload "optimised PNG", the thumbnail still may be bigger after PHP processing.

As the purpose of creating the thumbnail is to crerate a fast loading version of the image

Well, it is more for really large (resolution) images , for images with small resolutions it probably irrelevant

@brianteeman
Copy link
Contributor Author

I did a quick manual try with PNG set to 9 and the difference was amazing.

Our code supports different settings for jpg and png compression/quality it's just not being used for the thumbs

@dgrammatiko
Copy link
Contributor

@brianteeman although the Image class supports different compression ratios the functionality for the thumbnails doesn't expose it:

$image->createThumbnails([$this->thumbnailSize[0] . 'x' . $this->thumbnailSize[1]], $image::SCALE_INSIDE, dirname($thumbnailPath), true);

public function createThumbnails($thumbSizes, $creationMethod = self::SCALE_INSIDE, $thumbsFolder = null, $useOriginalName = false)

I did the implementation for the thumbnails so I guess this is my fault, if you need to blame somebody

@brianteeman
Copy link
Contributor Author

not interested in blame - just interested in making the thumbs functionality work as intended. I am certain you didnt intent to make the thumbnails bigger than the original ;)

@dgrammatiko
Copy link
Contributor

If you still have the test site available could you try adding:

$image->setThumbnailGenerate(false);

after: https://github.com/joomla/joomla-cms/blob/45adb61f8306b945f43b4326305fafe87c154aa2/plugins/filesystem/local/src/Adapter/LocalAdapter.php#L952C9-L952C35

Should do the trick

@brianteeman
Copy link
Contributor Author

surely that just disabled the creation of thumbnails ??

@dgrammatiko
Copy link
Contributor

surely that just disabled the creation of thumbnails ??

The docs say that this controls the quality:

/**
* Method for set option of generate thumbnail method
*
* @param boolean $quality True for best quality. False for best speed.
*
* @return void
*
* @since 3.7.0
*/
public function setThumbnailGenerate($quality = true)

@brianteeman
Copy link
Contributor Author

my bad - i will test that soon

@brianteeman
Copy link
Contributor Author

all that does is to create reall bad quality thumbnails that are the same filesize as the good ones

filename original filesize kb cache filesize kb cache filesize after
image1.png 44.05 105.85 1-5.85
image2.png 452.83 75.3 75.3
image3.png 30.47 93.39 93.39
image4.jpg 250.94 27.79 31.34
image5.jpg 114.55 26 30.48
image6.jpg 260.38 34.84 42.02

@dgrammatiko
Copy link
Contributor

@brianteeman check #43282

@alikon
Copy link
Contributor

alikon commented Apr 15, 2024

please test #43282

@alikon alikon closed this as completed Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants