Support » Plugin: EWWW Image Optimizer » Feature Request: JPEGMini and TinyPNG

Viewing 15 replies - 16 through 30 (of 43 total)
  • Plugin Author nosilver4u

    (@nosilver4u)

    Ok, I did more extensive testing, and realized that pngquant will often reduce an image even on subsequent runs, because it is lossy, so it is just like saving a jpeg multiple times, you lose data nearly every time.

    I used this combination: pngquant, then optipng, then zopfli (via advpng) or pngout for compression.

    There were a few images where tinypng still beat this combination, but overall, I was able to beat tinypng by about 10% (~30kb) on a test set of 28 images (~500kb).

    That’s very promising, as it means users will be able to do lossless PNG optimization without paying for another external service. JPEGmini is something else altogether, and neither will be implemented anytime soon, but now I at least have somewhat of a plan.

    I just want to add my +1. 🙂

    +1, thank you so much for making this happen!!

    +1 as well. Both TinyPNG and JPEG Mini are hidden gems, and to see them integrated into a WordPress plugin would be a boon to the community.

    Plugin Author nosilver4u

    (@nosilver4u)

    Ok, need some feedback from all of you, if you don’t mind?

    The original plan was to implement the lossy optimizations for resizes only. While this is technically feasible, it’s not very elegant, and I wonder if we wouldn’t be leaving out a lot of images where folks would want to use the lossy option. Even worse, I was planning on just doing resizes from the Media Library, and the supported gallery plugins. So what happens to all the stuff we run through the ‘optimize more’ functionality?

    A slightly better option is to just hook it into the wp_image_editor implementation that the plugin uses, so that anything WP edits would have lossy optimization (at least for plugins that do things the ‘right’ way).

    Again, even though that seems pretty safe, I have two concerns:
    1. There are still probably going to be images that folks would rather use the lossy optimization on.
    2. It’s going to be rather difficult to inform users on what IS and ISN’T using lossy optimization. Worse, I wouldn’t even be able to tell them without looking at the code for any and every plugin that users might ask about.

    So… I think I’m going to have to revise the plan, and enable lossy optimization for EVERYTHING. I’m sure Ian is already cheering, haha. Anyway, please give me some feedback on that. Is it great? Is it wonderful? Or are there drawbacks? I don’t do a lot of image heavy websites, and very few PNGs, so it would be great to get some insight from those that it would affect more.

    Plugin Author nosilver4u

    (@nosilver4u)

    Also, I’ve already implemented pngquant (lossy PNG) on the cloud side, now I just have to compile it 15 different times for the rest of you so I can enable it in the core plugin. Planning to have it done next week sometime.

    JPEGmini is still a ways out, been emailing them back and forth trying to figure out the best way to integrate, and hoping they’ll give me some sort of kickback to lessen (or eliminate) the cost of development. If they refuse, I might have to see if someone wants to either sponsor a JPEGmini server for a couple months, or give me access to an AWS instance.

    Hmmm, well I’m not sure if I understand all the process but I would be concerned about quality. With more than 5000 images I wouldn’t risk to damage the quality too much.

    For example, in the settings “optipng optimization level”, I have set up the level 3: 16 trails, because the level 2 wasn’t giving back enough quality.

    I personally now use only JPG but I tried tinyPNG with a few of what I had and the output wasn’t great at all. The quality of the image was too bad for me, at least on my tests. Now, for a thumbnail, who cares, but for main images is different. If someone does the bulk optimisation without taking any precaution, he could end up with a bad surprise. Imho.

    Plugin Author nosilver4u

    (@nosilver4u)

    That’s what I wondered, hopefully a couple other folks will weigh in on this as well.

    Regarding optipng, that doesn’t make any sense, because optipng is totally lossless. It doesn’t have the ability to degrade the image quality, it only reorganizes the image data that already exists to achieve the best filesize. Even if you convert a JPG to PNG (for things like logos and such), it can’t degrade the image, because an exact pixel by pixel copy is created, and then optimized with optipng.

    I don’t know, I can’t remember anymore what the problem was at that time because there was also the problem of 2 steps as it didn’t convert Jpg to png in the first step. I remember I was optimizing the first images one by one to check how they were and with level 2:8 trials the results were not good so I went for level3:16 trials and they were good, so I set up that level and start bulking.

    Plugin Author nosilver4u

    (@nosilver4u)

    Ah, ok. The levels are compression settings, not quality settings. Just to explain a little better the way PNG optimization works:
    PNGs are stored using zlib compression, which has several different parameters (and different compression methods even). So, what optipng does, it it tries different parameters to get the best compression level (each combination of parameters is a ‘trial’). At level 1, it tries what it thinks is the best combination. At level 2, it tries 8 different combinations, and so on. It’s a nearly exponential process, so higher levels use much more CPU, but there generally is very little savings over level 3. Level 2 is the default because it does pretty good without overtaxing your CPU, but level 3 will usually squeeze out some more savings. Optipng also does some other things to try and achieve better storage size, but that’s the gist of things. PNGOUT does some of that, but uses it’s own special zlib algorithm which achieves results similar to the zopfli algorithm, so it can often make an optimized image even smaller, but at the cost of more CPU usage.

    TinyPNG (and pnquant) actually reduce the color pallette to achieve their savings, so they discard some colors, resulting in a quality loss, which is generally imperceptable. But apparently you’re more perceptive than the average person, hah!

    😀 Thanks for the explanation. And yes, maybe I pay more attention because it’s for a photography site after all and I also watch thousands of pictures every week. So I usually accept a loss in quality for the web but not if it’s going to change the general visual impact. It really depends on the type of pictures, or even screenshots and yes, tinyPNG does a great job but probably it depends on the quantity or type of colours inside each different image. I was impressed by the saving of kb but I couldn’t be generally satisfied for all tests. And they offer just one possibility, and there’s no way to choose a level 1, or 2 or 3, for example. So, that’s why I wouldn’t risk it for a bulk optimisation.

    Plugin Author nosilver4u

    (@nosilver4u)

    It might be interesting for you to try a direct pngquant implementation. My plan currently is to use the default setting which attempts the least quality decrease. Check pngquant.org for a program that you can use on your OS, and see what you think of the results.

    All our product images (~1000) are all PNGs as we use the alpha channel.
    In the product catalogue, images are loaded by the dozens in relatively high-res (retina display craze now).
    For us, we accept a minor decrease in quality in return for much faster loading. Waiting visitors that are just quickly browsing, especially over slower connections, are much more likely to bounce.
    TinyPNG’s standard savings are fantastic for us.

    Plugin Author nosilver4u

    (@nosilver4u)

    I’d like to see more feedback, so if anyone else is following this thread, feel free to put in your thoughts on the matter.

    I DO have an idea though. I was originally trying to think about how to catch all the weird edge cases, and make sure resizes from the Media Library, NextGEN, FlaGallery, and others would get lossy optimization. In other words, I was trying to think of how to INCLUDE every image where people would want lossy optimization applied.

    What if we instead focus on what to EXCLUDE? While I hate adding options, it almost seems unavoidable that the best approach here is to have an option to exclude full size originals from lossy optimization. I think this would be way easier from a programming standpoint, since there are less images to think about.

    Everything lossy is perfect for us, exclusion option is a good idea for the odd case!

Viewing 15 replies - 16 through 30 (of 43 total)
  • The topic ‘Feature Request: JPEGMini and TinyPNG’ is closed to new replies.