Interlace / Progressive action

Thanks for posting the patch. I think this could be a nice addition, if it is indeed such an improvement for UX.

The patch needs some work though:

1. +++ b/sites/all/modules/contrib/imagecache_actions/coloractions/imagecache_coloractions.module
   @@ -80,6 +80,13 @@ function imagecache_coloractions_image_effect_info() {
   +  $effects['coloractions_interlace'] = array(
   

   Also implement the summary theme callback as well as the form callback. The form callback could contain more detailed help on what this effect does (for the various formats) and why/when to use it.

2. +++ b/sites/all/modules/contrib/imagecache_actions/coloractions/imagecache_coloractions.module
   @@ -497,3 +504,34 @@ function coloractions_file_formats() {
   + * Implementation of hook_{toolkit}_{effect}()
   

   We just standardized the documentation for our effects. Can you download the latest dev and follow the function order and documentation over there?

3. +++ b/sites/all/modules/contrib/imagecache_actions/coloractions/imagecache_coloractions.module
   @@ -497,3 +504,34 @@ function coloractions_file_formats() {
   +  watchdog('image', 'Image %file could not be interlaced: !message', array('%file' => $image->source, '!message' => t('This feature only works with ImageMagick, not GD.')));
   

   What about imageinterlace()?

Another option I want to mention, is merging this option into the change format effect. It already contains the quality parameter, this one seems comparable. What do you think? (@dman, @dalin)

I'm not incredibly excited about adding an effect that has no GD equivalent. I was actually hoping someone had found the option that would make this work in GD!

I see the argument for just merging it or exposing it as part of the 'save' options next to 'quality'. I don't actually *feel* that this low-level option brings enough value to be added to everyones UI as a new option on every config screen for adding first-class effects.
So, I would endorse putting it in with the 'change format/quality' option screen.

You claim

In these cases it may be useful to get the image dimensions for very large images ASAP to avoid a late page reflow.

Which sounds dubious. Do you have evidence that there is a difference between interlaced and non-interlaced and how they supply image dimensions? I'm pretty sure the width and height of an image are available in the first Kb of a JPEG header, regardless of the encoding. The real difference is about scanline loading vs pixellation - but it's not about the dimensions reserved on the page by the browser. ... in my experience.
Can you demonstrate the "late page reflow" difference you have seen? o_O

#3: Thanks for your reply. Good remarks.

- Quality is a jpg (only) term. For png, that value has a completely different meaning, so it cannot be seen separate from the format. But i agree, offering a "do not change" would seem logical if we keep the quality parameter and certainly if we add this effect.

- if 93% of the web is non-interlaced, should there than also be an option to switch it off, or in other words, should the effect get a parameter?

- I guess we better have a look at our other theme implementations, autorotate e..g is indeed a bit of duplication. We could change the name if we want to mention the word EXIF. So leave that one out, unless we add a parameter to the effect of course.

#5-1
Yep. I also thought it would make sense to extend the file format switcher with a file-format:"do not change" if we start putting putting technical save-as options into here. But I do think that the "technical save-as" options belong together.

Yeah, I'm all for interlacing as an aesthetic choice :-)

I just require a little scientific proof when someone claims performance (or SEO!) benefits without metrics :-B
I also gave corey a hard time about his filesize claims in #1854270: Posterize action for file size/bandwidth saving on PNGs !

Carry on!

Yes, I prefer to combine the "technical save-as" options as well, so we should go for that:

- New name for "change file format" that better covers its new features.
- New (default) option in select list: "do not change format".
- The interlace option should be a 3-way choice: leave as is (default), enable, disable.
- Documentation, help and summary theme need to be adapted.
- It will need a hook_update_n() to add the new parameter(s) to existing effects, or we are stick with testing for isset(...) first until the end of times.
- Test style definitions need to be extended with the new parameter(s) as well, but I will do so, when the rest of the patch is there.
- Add GD implementation for interlacing.
- Plus earlier remarks from #2 (that still hold).

- 1 RENAME. Yeah. No idea yet. Consider some prior-art labels I guess.
- 2 DEFAULT TO NO CHANGE. 100%
- 3 OPTION FOR DEFAULT. Um, yup, Agreed
- 4 DOCS++. Always good
- 5 HOOK_UPDATE. yeah, if we do it, the machine-name should be updated at the same time, and that needs an update. Though thinking about it .."change file format" is still accurate :-)
- 6 TESTS. sure- but after 7
- 7 GD SUPPORT. Is this even possible?
- 8 CODE STYLE. sure.

GD support, see #2-3: imageinterlace() should do the trick I guess.

Name:
- (file) save options? (irfanview)
- (file) save settings? (paint.net)

I am not sure what you mean with this. Where does jpegtran enter the story? Is that for both Imagemagick and GD? And why does it ignore progressive/interlaced settings?

A quick search revealed this on Wikipedia:

The jpegtran command-line program is useful to:
...
convert between progressive and non-progressive JPEG formats,
...

So progressive seems to be supported by jpegtran???

So, to get progressive jpg, eventually both issues need to be fixed. Moreover, for setups without image API optimization only this issue would suffice. So I propose to continue working on this issue regardless the state of the other issue. @dalin: can we count on you to post an updated patch according to the remarks made? You, your company or your client will be listed (with a link) on the project page as sponsor.

Couldn't wait, added 1-line GD support. Appears to work but may need some A/B testing.

Wow, we've been using this in production for nearly 2 years now for a few sites that have a fluid layout (based on image height). Sites are only getting more photography-rich and this has become a necessity for us.

I've updated the patch for the latest dev branch, and moved the action under canvas actions (which seems a more appropriate location than in color actions).

Patch looks clean visually. Thanks for revisiting a dormant (but useful) feature request.

No specific objection to shifting it to canvasactions
- it was in coloractions mostly because this actions nearest neighbour was file-format-switcher ... which was grouped in with coloractions because that's where transparency actions lived, and file-format and transparency options always lived together.

:-}

Thanks for rerolling. I committed the patch with some minor changes (unreachable statement, empty lines between @param's, renamed the toolkit operation to interlace as well) and added a form with some help text only, like with the autorotate effect. Improvements/additions to the help text are welcome, I'm not a native English speaker.

No, I meant fixed, see #20.