change jpegoptim to guetzli for much better compression of JPG

[mikhailnov]

And I also added the Russian translation to trimage.desktop

[Kilian]

Hi @mikhailnov thanks for this pull request. I have a couple of issues with it:

• Trimage should only compress losslessly, guetzli is lossy whereas jpegoptim can be configured to be lossless. -For the main target (debian/ubuntu), Guetzli is part of the main repositories from Debian Sid but not earlier, and this could be a problem with dependencies on those versions.

Mostly the first is a problem. Can guetzli be configured to be lossless?

[mikhailnov]

Hello, Kilian, thanks for the reply. 1) I did think about loosinbg losslessness when making this pull request, but I tried to compress jpg and png with Trimage for many times, in most cases jpgs are not comressed at all. This made using Trimage for jpgs useless for me. I don't know for which use-cases you designed this awesome program, but I use it for quick compression of images for web-sites. I care about the users with a slow internet connection and a limited amount of internet traffic)) For me lossless compression is in general not as interesting as getting an output image which will be very near to the original, but will have the least weight possible. From all tools that I have tested guetzli is the best. It can be used with --quality 100, but it seems to be not lossless and makes no sense as --quality 95 outputs a similar result of a much lower weight, but you can also test it with --quality 100, maybe it will be nearer to lossless, well, it seems to be very near, but for most useceses 9 will probably be better.

I took a test image 1-orig.png (2 MB), then saved it as 1-orig.jpg using GIMP with the jpeg export qualit 100% and got a 668,8 KB file. $ guetzli --quality 95 1-orig.jpg 1-guetzli1-95.jpg All images are here: https://yadi.sk/d/rsAmrf8x3KuqpM Guetzli with quality 95 has a good result.

Already released versions of Ubuntu/Debian will not update Trimage, older ones can package a new one, there is no problem.

Of course, it may break the fuctionality that other users use Trimage for, but I did not find a solution.

If you will not merge this, I will understand you, but will probably make a for of Trimage, but I am currently not able to maitain a python/Qt projects by myself due to lack of qualification, that's why forking is a bad idea.

Still, I will probably make a bash script which will get a folder with images for input and will convert them all using all CPU cores, not only one as Trimage does. Trimage is excellent for quick processing of a few of images, but not for many of them due to lack of multithreading (and I do not know Python well enough to contribute multithreading at the moment).

[mikhailnov]

By the way, I packaged guetzli git master and Trimage 1.1 with my changes for Ubuntu >= 16.04 in my repository:

wget -q -O- http://repo.dumalogiya.ru/keys/mikhailnov_pub.gpg | sudo apt-key add -
sudo wget -O "/etc/apt/sources.list.d/dumalogiya-xenial.list" http://repo.dumalogiya.ru/dumalogiya-xenial.list
sudo apt update
sudo apt install trimage

[Kilian]

That repo is pretty nice!

For me, conceptually, I think there are two ways to compress images:

1. Automated using tools such as trimage, which should compress but you should also be able to run without checking (meaning that no image data is removed)
2. Manual lossy compression where you choose the lowest acceptable quality, for which you have to check the output.

I really want Trimage to be a guaranteed automated tool, and take for granted that lossy compression tools will always yield better results. I'm more than happy to support/help with a trimage-lossy fork or something like it (maybe there are more ways to lossily compress png's too?), but Trimage will remain lossless.

[mikhailnov]

OK, I see your point, that's a wise decision. I renamed my fork to optimgaika (оптимгайка), https://github.com/mikhailnov/optimgaika , now I will continue developing it separately and will probably add lossy compression of png and webp and maybe gif. As I'm not a pythonist, I will probably have to make some bash scripts which will interact with the main pyhon code written by you. If you continue developing trimage and , for example, port it to Python 3 and Qt5, I will try to backport the changes. Debian seems to try to get rid of Qt4 packages.