Option for progressive jpeg

agree 100%

This is great!

As that article points out "Choosing the progressive option is win-win, and should always be the default.". Therefore in this patch I've made progressive the default. I wasn't quite sure which progressive method to choose as the default. Google reveals scant details about the difference between the two. But Stoyan Stefanov uses 'plane' for all of his examples, so I chose that one.

I also added some missing t() on the #options. While #options are always run through check_plain(), they aren't auto-translated.

One consideration would be GIFs and PNGs. These will also be interlaced by ImageMagick. My research shows mixed results here. Sometimes larger file sizes, sometimes not. But I can't find any articles with the same detail of analysis as the above article about JPGs (for example I found no details about CPU impact during rendering or a list of what browsers actually render them interlaced). Given that image styles are used on JPGs an order of magnitude more commonly than on GIFs or PNGs, it is probably sufficient to simply interlace all formats.

One final consideration is file size. The article above notes that the benefits of progressive JPGs does not exist for files < 10k. Unfortunately that sort of information is unavailable here since image_imagemagick_save() strips out the useful information about the image. It might be worthwhile to alter that function to pass that information along so that we could automatically not interlace small files.

Also making this work for GD is much simpler, so this should be core worthy as well:
http://www.php.net/manual/en/function.imageinterlace.php

After further thought, I'm second guessing myself.

The main benefit that the article describes is to avoid re-flows as the images arrive (and a secondary advantage of ever-so slightly smaller file sizes for progressive JPGs (but sometimes considerably larger GIFs or PNGs)). However Drupal's image style system is really smart and outputs img tags with height and width attributes so reflows aren't an issue.

On the flip-side is a psychological cost. It's damn annoying to try to read a chunk of text as the huge progressive image flashes away beside the text that you're reading.

I see that I actually forgot to attach the patch to my last post. So rather than attach it I think I'll just mark #4 as RTBC :-P

+++ b/imagemagick_advanced/imagemagick_advanced.module
@@ -52,6 +52,20 @@ function imagemagick_advanced_form_system_image_toolkit_settings_alter(&$form, &
+    '#title' => t('Interlacing method'),
...
+    '#options' => array(
+      'line' => 'Line',
+      'plane' => 'Plane',
+    ),
...
+    '#description' => t('Specify the type of <a href="@help-url">interlacing</a> scheme. Use <strong>Line</strong>, or <strong>Plane</strong> to create an interlaced GIF or progressive JPEG image.', array(

I'm relatively familiar with image formats, compression, and stuff, but the majority of users will probably not be able to make sense of this setting.

Do we need to provide both options or could we limit support to either line or plane?

Do both options work for both GIF and JPEG?

If we need/want both, could we add #descriptions for each option to clarify and recommend when to use either one?

+++ b/imagemagick_advanced/imagemagick_advanced.module
@@ -75,6 +89,10 @@ function imagemagick_advanced_imagemagick_arguments_alter(&$args, $context) {
       $args['colorspace'] = '-colorspace ' . escapeshellarg($colorspace);
...
+    $args['interlace'] = "-interlace {$interlace}";

This needs an escapeshellarg() like all the other arguments that output user-supplied values for the command.

@Dalin: Don't second guess yourself - progressive are not "just" for that. You should always remember that bandwidth is not always available. You could be accessing a webpage by mobile over gprs, or your wifi connection on a public event is simply awfull. Add a flexslider loading 10 images at almost full screen resolution, and you can feel a delay on image downloading.

If you have progressive images, it doesn't look like there's a technical glitch or badly programmed.
If you don't, you see a big hole where the pictures should go to... not so nice.

I poked around "convert" a little to see if I could make sense of the various interlace options.
The results I saw were 100% identical binaries, regardless of using "line" or "plane". Also, no problems converting .gif either way.
As I would have expected different results, I am not sure if things were processed the way they should be - maybe someone more knowledgeable about the differences in interlacing can double check on that.

A quick test using a simulated lossy EDGE connection (240 kbps / 200 kbps, 1% package drop, delay 400ms) and a number of real world image samples showed a huge benefit in using interlaced images - not only was the overall file size and thus loading time smaller, but the perceptible delay in image rendering is significantly shortened. So +1 on making this available to Drupal.

+1!!

We are getting into sites using Picture with completely fluid and responsive layouts... This means that we use max-widths and images must be left to scale to the full browser width. In such a case, progressively loading JPEGs are essential to reduce reflow as the page loads.

So I've had problems with this patch when combined with the patch from #1802534-4: ImageMagick scale breaks animated gifs to support scaling gifs.

I've attached a new patch that skips interlacing if the source image is a gif, but I'm not sure that's actually desirable here so mostly this is for conversation and for me to track the change I made.

What is the status of this issue? Have any of you put these patches into place?

We have had this in production for months. Can we get this merged?

Works like a charm.

Is there any way to add this patch to a new module version and release it? I'm willing to make a monetary donation to the current maintainer, organization, or someone who wants to update it for me. End goal is to be able to click a check box and get all images served as progressive jpegs.

Drupal 7 is EOL