schmitzal / tinyimg

TYPO3-Extension which compresses images (png & jpg) uploaded in the backend with the tinypng API
GNU General Public License v3.0
15 stars 11 forks source link

tinypng image sizes and fluid-styled-responsive-images extension #15

Closed Toccamonium closed 7 years ago

Toccamonium commented 7 years ago

Hi Alessandro,

great extension, thanks! I have a question/problem to the image size process in combination with fluid-styled-responsive-images. I create an png image, upload it to the typo3 backend. File size original 37 kb, with your extension reduced to 8 kb - great. Now I put this image with the CE text & media on my website. To serve for different devices a proper size of the image, I have also installed Alex extension. Now the problem is, when the png file gets processed, the file size is getting a lot bigger... like Photoshop does as standard. Any ideas how to solve this problem?

cheers, Florian

schmitzal commented 7 years ago

Hey Florian,

thanks for your feedback. I'll have to take a look at this on my test instance. Meanwhile you could check your image processing setup. Maybe there is something wrong with the configuration or something to optimize.

Does it work properly without the extension fluid-styled-responsive-images?

Best, Alex

schmitzal commented 7 years ago

Could you also provide the version number of TYPO3 and the extensions involved?

Toccamonium commented 7 years ago

Here arte the info you requested. We are using TYPO3 7.6.21 with your latest TER release of tinypng. I asked also Alex Schnitzler about this topic due to we are not really content with the image handling situation in the TYPO3 environment. Here is his answer: https://github.com/alexanderschnitzler/fluid-styled-responsive-images/issues/31#issuecomment-323277380

Right now we are developing on Alex's extension an more enhanced version so that editors can choose proper sizes for different grid columns. Because right now, when editors upload full size images and put it in a 3 col of gridelements, the image is too large as it just calculates viewport and not col-width. When I do have more infos I let you know if interested.

cheers, Florian

Toccamonium commented 7 years ago

I was just writing on Alex Github board about this issue. Right now, your extension does the processing when uploading an image. It would be cool if it would do it in combination with the TYPO3 image processing action :) Then we would have really an modern way of presenting perfect optimized images on RWD sites.

schmitzal commented 7 years ago

Implementing the compression in the image processing of TYPO3 isn't a solution, as this would create a huge amount of compressions on the tinify API and there are only 500 compressions per month for free. Imagine that someone switches from ImageMagick to GraphicsMagick and needs to clear the proccessed folder.

And the image processing of TYPO3 isn't the problem. I've tested this with multiple setups and images. If you upload a file (which gets then compressed by tinypng) and use this in a content element with resizing, the image processor of TYPO3 even makes it smaller in filesize than it was after compression.

So the problem must be in the other extension or in your setup. But I'll test this on TYPO3 7.6.21 with and without fluid-styled-responsive-images, as soon as I can, and come back with feedback.

Are you using ImageMagick or GraphicsMagick? And which version are you running? To assure the setup is pretty similar.

alexanderschnitzler commented 7 years ago

And the image processing of TYPO3 isn't the problem. I've tested this with multiple setups and images. If you upload a file (which gets then compressed by tinypng) and use this in a content element with resizing, the image processor of TYPO3 even makes it smaller in filesize than it was after compression.

I doubt that you can make up a general rule given the many options you can pass to the imagemagick binaries and the many different types of images you can have. What I expected so far is that with a high quality, processed images tend to get bigger (in size) than the original.

I understand that you have an api limit and your solution is just fine. I'd check if my extension can use anything non-api limited to always do the optimization last. That way One could use im to only resize the image and then optimize it.

Toccamonium commented 7 years ago

Sounds good :)

Hint about API limits: we are using a similar extension for our WordPress CMS. WP is processing also a lot of different image sizes and if customers are uploading a bunch of images filling a gallery, you are reaching 500 operations fast. Therefore you can create an account on tinypng, connecting it with your credit card and receive your API key. Whenever the 500 limit gets passed, they send you an invoice at the end of the month for costs of those additional image processing.

Works great, there should be just an clue for people to know about this.

schmitzal commented 7 years ago

Sure there is a method with payment. But most of the users won't pay for this feature. That's the reason why I'm trying to keep this extension as much "free to use" as possible. Compressing processed images wouldn't fit into this goal.. :)

schmitzal commented 7 years ago

Any further discussions can be done in the #ext-tinyimg slack channel. :)

Closed