API for progressive JPG and other recommended web thumb best practices

[jrochkind]

Is making sure the JPG output is a progressive JPG part of the ImageProcessing API?

It makes so much sense to make sure your thumbnails are progressive JPGs. They are often (for mathematical reasons I don't understand) smaller in file size, but more importantly they load in a way better for UX under a slow connection.

Another, although less important, thing that makes a lot of sense for web thumb JPGs, is stripping EXIF metadata, and making sure they are translated to color-profile sRGB.

These are things that all the guides for creating JPG thumbs on the web recommend (including Google's), but I find often left out or not highlighted in documentation in ruby easy-thumbnail-gen libraries.

[janko]

Is making sure the JPG output is a progressive JPG part of the ImageProcessing API?

It's not there by default, but you can pass options to the underlying processor:

ImageProcessing::Vips
  .source(image)
  .resize_to_limit(400, 400)
  .saver(interlace: true) # passed to #jpegsave and #pngsave
  .call

ImageProcessing::MiniMagick
  .source(image)
  .resize_to_limit(400, 400)
  .saver(interlace: "...") # adds -interlace (I'm not sure whether it should be "Line", "Plane", "JPEG", "PNG", "GIF" or something else)
  .call

It makes so much sense to make sure your thumbnails are progressive JPGs. They are often (for mathematical reasons I don't understand) smaller in file size, but more importantly they load in a way better for UX under a slow connections.

Yeah, sounds like for generating JPEG thumbnails interlacing should be the default (ImageOptim thinks so too). For PNGs we'd probably want to leave it off by default, because if I understood https://github.com/jcupitt/libvips/issues/140#issuecomment-47515390 correctly, generating progressive PNGs might negatively impact performance.

Another, although less important, thing that makes a lot of sense for web thumb JPGs, is stripping EXIF metadata,

Yes, that was something that I had in mind. For ImageMagick stripping EXIF and other metadata is as simple as using -thumbnail instead of -resize, though ImageProcessing uses -resize for #resize_* methods and it's not currently possible to switch to -thumbnail (PRs welcome). For libvips there isn't a built-in solution, though I've been playing with EXIF stripping locally and I might have a working solution (though would love to cover TIFF data as well).

Both ImageMagick and libvips have a "strip" option, but for ImageMagick that also strips color profiles, for libvips probably as well.

At the moment I'm reluctant to add it as default behaviour, as some people might not be using it only for generating thumbnails, e.g. they might resize the original image and not keep the original, so they might be surprised to find out that EXIF and other data is stripped.

and making sure they are translated to color-profile sRGB.

I'm not sure how to do that yet, but if that's a reasonable default we might add it to ImageProcessing.

For now we can just highlight how to do that in the README. Maybe we could add a :thumbnail saver option that will apply all these defaults for generating thumbnails.

[hmistry]

It's not a default setting as such things are best left up to the dev's using the library. The ImageProcessing API is a common generic wrapper to provide a uniform interface to underlying image processors like ImageMagick and Libvps. Different apps have different needs (e.g. image archiving, photographers, etc where preservation of quality and metadata is key).

I think linking such recommendations is a good idea. We would welcome a PR for consideration to such links that you feel will benefit dev's.

[jrochkind]

Right, whether default or not, I think a common generic API to exersize these options (whether in IM or vips), without having to provide back-end-specific directives, might be a good idea? Is my suggestion.

[jrochkind]

(PS: I actually work in digital preservation/archiving, and while we don't want to touch the originals, there is no reason I know of not to make the derivative/version thumbs optimized for the web).

[renchap]

I'm not sure whether it should be "Line", "Plane", "JPEG", "PNG", "GIF" or something else

It does not matter for JPEG files according to this answer: https://stackoverflow.com/a/36436945/1377358

[jrochkind]

For libvips there isn't a built-in solution (for stripping EXIF)

There is from the vips command-line, which makes it seem like there might be from libvips? See --strip and --delete options to vipsthumbnail. http://libvips.blogspot.com/2013/11/tips-and-tricks-for-vipsthumbnail.html

This kind of having to figure stuff out, though, is part of why I suggest that stripping metadata and progressive JPG should be part of the ImageProcessing API, figure it out once and put it in ImageProcessing, and then every consumer doens't have to figure it out -- and can have it keep working if they switch from IM to vips backends.

[hmistry]

@janko-m if you decide to add strip as default, please consider the additional time cost if any and provide option to turn it off.

When I implemented this a year ago using ImageProcessing with MiniMagick, I discovered stripping added another 200-300 ms to process time. My optimum recipe for version generation was:

1. fetch original
2. generate a large copy using resize and strip (have the 200-300 ms computation penalty once)
3. generate medium copy from large, small from medium, etc (no strip for metadata because there should be none to begin with)

[janko]

For stripping metadata both processors coincidentally already have the same API:

ImageProcessing::MiniMagick
  .saver(strip: true) # appends the `-strip` option
  # ...

ImageProcessing::Vips
  .saver(strip: true) # passes the `:strip` saver option
  # ...

However, as discussed in https://github.com/janko-m/image_processing/issues/28, it might not be desirable to strip by default, as people might be relying on EXIF tags existing, as was the case with earlier versions of ImageProcessing. Stripping also removes color profiles, which if I understood correctly might make the image display with different colors in the browser? From the post that @jrochkind linked to it seems that it should be a good as long as images are converted to the sRGB colorspace (if they aren't already).

Progressive JPEGs/PNGs are also easy to do, as mentioned previously. I agree with @jrochkind that we should at least document these common tips & tricks. I'm thinking we should add it as a wiki page, then link to it from the README.

I discovered stripping added another 200-300 ms to process time.

@hmistry Wow, that's good to know. I'm not getting any performance difference locally, but it may be visible with images that have more data.

It does not matter for JPEG files according to this answer

@renchap That's good to know, thanks!

[janko]

If anyone would like to take a stab at documenting these tips, or think that some should be applied by default, please feel free to edit the wiki and/or send a PR.

[jrochkind]

So I believe --strip doesn't actually remove color profile information, so is unrelated to converting to sRGB colorspace. If you read the blog post about vips, I believe this is what it says. --delete removes color profile information, so should only be done in some cases.

Yes, this stuff is confusing. That it is confusing to figure out is one reason I still suggest image_processing should provide operations that do it, not just docs on how minimagick/image_magick/vips do it.

I'm not sure why the discussion has become about what should be default. The issue as I opened it does not suggest anything about defaults. Nowhere I have suggested any of this stuff should be default. I have no real opinion on what should be default. It may indeed be reasonable for none of it to be default.

What I am still suggesting is that these operations should be part of the image_processing api, that image_processing should provide these operations. Because they are often best practices, recommended by many sources.

Of course you can pass the specific back-end-specific options to the specific back-end. But if we were just going to do that, why would we need image_processing at all? We could just use MiniMagick or ruby-vips or whatever. The reason this gem is valuable is because it encapsulates common operations so we don't have to go figure out how to do them. (And, as of recently, in a backend-independent way, which is awesome). The same reason we want a resize_to_limit method in image_processing is the reason we want operations in image_processing that allow you to easily do the things that many sources recommend as best practices when making JPG thumbnails for the web: progressive JPGs, stripping EXIF, possibly sRGB colorspace, possibly stripping color profile info.

Of course, this is just my opinion, you can disagree, but please let's not talk about what should be default anymore. And I hope you at least understand my suggestion now, I'm sorry I've been having trouble making it clear.

[janko]

I'm not sure why the discussion has become about what should be default.

Yeah, sorry, that was something that I unnecessarily added to the discussion. Since all of us are ok with this being opt-in, let's talk about the API.

Ok, these are some of my comments on what we've mentioned so far:

• Progressive JPGs
  • libvips has :interlace saver option, ImageMagick has -interlace option
• Stripping EXIF
  • I've been searching how to do it with ImageMagick but couldn't find it, -strip strips away more than just EXIF data
  • with libvips you can #remove EXIF metadata before saving (:strip saver option might also be an option?)
• Converting to sRGB colorspace
  • I haven't researched this yet; in the vipsthumbnail blog post it shows vipsthumbnail shark.jpg --eprofile /usr/share/color/icc/sRGB.icc --delete, but --delete is not exposed in ruby-vips, and I don't know where /usr/share/color/icc/sRGB.icc came from
• Stripping color profile info
  • vipsthumbnail has --delete, but it's not available from the Ruby API; I would prefer something that's not tied to generating thumbnails
  • would .remove("icc-profile-data") be enough for libvips?

We could add #progressive and #strip_exif methods to the API, and maybe more. We could definitely take a look at Sharp to see what solutions it has.

[jrochkind]

You gotta supply your own sRGB.icc color profile in vips for whatever reason. There are several open source ones under licenses that would allow you to package them with whatever you want, not sure why libvips chooses not to package one, maybe it doesn't want to decide for you which one to use. (I think under normal/default/non-expert use, any of them are just fine).

https://github.com/jcupitt/libvips/issues/776

This stuff is totally crazy confusing to figure out! Which is why figuring it out in image_processing for everyone else would be so useful heh.

[renchap]

I think this is a good idea to provide built-in "profiles" (the first one being web thumbnail) in this gem, as image processing (the field, not the gem 🙂 ) is complex and not easy to grasp.

Something to keep in mind is that the options will depend on the output image format. You dont want a progressive PNG for perf reasons, quality does not have the same meaning, …

[janko]

You gotta supply your own sRGB.icc color profile in vips for whatever reason. There are several open source ones under licenses that would allow you to package them with whatever you want, not sure why libvips chooses not to package one, maybe it doesn't want to decide for you which one to use. (I think under normal/default/non-expert use, any of them are just fine).

It seems that we should probably use this profile for sRGB conversion.

This stuff is totally crazy confusing to figure out! Which is why figuring it out in image_processing for everyone else would be so useful heh.

You can say that again. I've never even heard of "image profiles" until I started reading other libvips wrappers.

Something to keep in mind is that the options will depend on the output image format. You dont want a progressive PNG for perf reasons, quality does not have the same meaning, …

Interesting! Yeah, we should definitely try to do the right thing.

[jrochkind]

yep, that's the profile I ended up using myself too, since it it is after all direct from the International Color Consortium, and is licensed for unrestricted use and redistribution. It's not the one jcupitt used/recommended for whatever reasons. I think really just about any will do (if someone is enough of a digital image wizard to know enough to have a preference, they can do it manually :) ).