X3Photo Gallery Forums

Kraken does the same.
I haven't compared this one with the one you mentioned, but you can give it a try....

https://kraken.io/web-interface

These image size "crunchers" are quite useful, but keep one thing in mind: They will only affect the large "original" images that you upload. Smaller images (than the original) which often display in your X3 gallery, are resized by X3/PHP and therefore remain unaffected. Also, if you want to use any of the EXIF/IPTC image meta data in the future, make sure you don't strip away this info from the image (some apps do that, to make them even smaller).

Having said that, it certainly is a good idea to optimize the file size for originals (large size uploaded), as they can often be quite big, and most of these applications apply lossless optimization. Personally, I have used https://imageoptim.com/, which does the job.

I imagine you will find almost identical results between jpegmini and imageoptim, as they probably use the same engine for crunching jpg files. The reason you don't see any difference in quality, is because they both do lossless compression. It is a good idea.

andreamarucci wrote:I've tried with the same image that Jpegmini squashed from 3.5Mb to 980Kb. Imageoptim reduced it a lot less to 3.3Mb.

Are the resulting image the same dimensions? Squashed from 3.5mb to 980kb is not possible if it is lossless. All these applications likely have settings, and using lossless compression, it just tries to squash the images without affecting the image quality in any way whatsoever, so it looks identical after squash. This will normally result in maximum 10-20% smaller file size. For higher compression, the app is applying non-lossless compression ... The result of that depends on your originals. Likely the 3.5Mb original has almost no compression, perhaps because it is original camera files?

So conclusion, just be aware of the difference between lossless and lossy compression techniques. Imageoptim only does lossless, and therefore it does not recompress the JPG itself, which will be the same as the original. For lossy compression, you need to find a good balance between image quality and file size.

andreamarucci wrote:I've used jpegmini, the images look exactly the same but they occupy a lot less space...

I don't know if you do, but I would use an iPad to make these visual comparisons.... just because it has its retina-screen....

Hello,

I'm also using jpegmini. There is also a server integration that can be run frequently to process also the files created by other applications. It's expensive, though.

@Mjau-mjau: jpegMINI is NOT lossless. It really compresses the files by factors between 1.4 up to 4 (for my images) compared to the "save to web" in Photoshop. The results are excellent and with no visible loss (http://www.jpegmini.com/main/technology).

I have tried many of the image optimizers out there, but jpegMini is superior to all of them (also in terms of speed and ease of use).

What I do occationally is, that I mount my server webroot via sshfs and run jpegMini on it. jpegMini is clever enough to ignore everything that is no jpg file and also detects if a file has already been processed. So it does only compress the delta images. I can just throw the whole webroot folder at it. This works very well for wordpress based sites, because the thumbnails etc. are created as static files. I'm not sure how imagevuex handles this.

Best Regards,
Stefan

@sHagen Good tips!

sHagen wrote:@Mjau-mjau: jpegMINI is NOT lossless. It really compresses the files by factors between 1.4 up to 4 (for my images) compared to the "save to web" in Photoshop. The results are excellent and with no visible loss ( http://www.jpegmini.com/main/technology ).

Ok cool. My only point was that LOSSLESS and LOSSY are not competing methods. Often, with images that are already balanced in terms of compression/quality (from another app or service), you can still squeeze out a bit more by running them through a lossless compressor, without touching the actual image pixels. This is what we did with images in the X3 demo gallery.

Most compression applications including imageoptim, also support "lossy" minification:


You wouldn't use it if you have already compressed-for-web from another process, as that would be counter-productive. LOSSY compression should only be applied once from original images, which could often be high-quality (low compression) JPG files directly from a camera.

Anyidea to support the webp format？ 

lenstudio wrote:Anyidea to support the webp format

WebP would be nice, but there are many challenges:

• X3 would have to convert ALL your JPG images to WEBP on server. Obviously we can't expect each user to upload all their images in two formats, where each image has an identical sibling.
• Your server disk usage would almost double: X3 would need to create WEBP versions of ALL your jpg images, as well as smaller, resized versions of each image.
• There will be many server issues to deal with. PHP version requirement, issues in quality/compression when converting some images from jpg to WEBP, and errors when trying to resize to very large image sizes.
• Unlikely you will be able to convert large jpg files to webp, if you are on a shared host.
• Deleting images from the panel would need to delete TWO sets of images (jpg and webp) for each image.
• All images would always need to be synchronized when uploading, moving, copying etc. If somehow a JPG image does not have a twin WEBP image (from a range of possible mistakes), then the browser will report "File not found" error.
• Of course, WEBP is only supported in one browser currently: Chrome.
• I have done many tests with webp. It makes a massive difference for lossless format, and when using 24-bit transparency. However, if you optimize your JPG images with the best tools, benefits of WEBP are much less evident.

If we hosted all X3 websites on our own server, it would not be too difficult to implement.

Did you have any additional ideas of how we could practically implement this without too many problems?

lenstudio wrote:Anyidea to support the webp format？

New release X3.28.0 now supports Google's webp image format. In reality, it's too early to use webp, because it's not yet supported in Explorer, Safari or iOS (ref caniuse.com/#search=webp). X3 will create webp resized images (thumbnails) in JPG format so they will display in ALL browsers, but it's up to the browser if it can display the full-size webp image.

You might ask if X3 can create webp copies of all jpg images (or the other way round) for selective display across different browers. This is theoretically possible, but it's not something we will currently pursue in X3. This would basically DOUBLE server storage (two copies of each image), and it would require a lot of CPU and memory to duplicate all images. Besides, webp does not offer much benefit over jpg when it comes to photographic images.

Read more about latest X3.28.0 release:
www.photo.gallery/blog/photo-gallery-x3-28/

I decided to write a blog post about optimizing images. See post:
Optimizing Images for Photo Websites