PW 3.0.10: Expands image resize options

[ryan]

Most of this week and ProcessWire 3.0.10 has been focused on covering issue reports and related tweaks/fixes, which you'll see in the commit log. But we've also got a major upgrade to the core in 3.0.10 as well, with the introduction of ImageMagick and a new module type: ImageSizerEngine– 

http://processwire.com/blog/posts/processwire-3.0.10-expands-image-resize-options/

[Martijn Geerts]

That's the way I love it ... Thanks Horst & Ryan !

[Jugibur]

Thanks Ryan and Horst for this great improvement!

Newer ImageMagick versions preserves the color profiles as I know. Perhaps this is causing some of the file size difference in the examples.

If explicit no profiles wanted, they could be removed with the "-strip" parameter.

If you have AdobeRGB profiles embedded, image colors could be flat on sRGB-Monitors and/or some Browsers without color management. With IM you could convert these profiles to sRGB.

[horst]

@Jugibur: that's all right what you are saying. - But, ...

the -strip param is only available in the CLI version of ImageMagick, not with the PHP extension. But the PHP extension can handle embedded image markers as well, if, and only if: needed dependencies are compiled in. For ICC conversion, the lcms lib needs to be compiled in, what seems not by default or not with all extensions. Other cons are: with the PHP extension of Imagick, you cannot determine if it is supported / compiled in or not! And if it is supported, it will expand the processing time up to 3-4 times, compared to the processing time without ICC conversion.

Therefore, and to have a homogenuous behave across all engines, we strip all image markers by default, but excluding IPTC. (stripped ones are: ICC, EXIF, XMP, JPEG-Comments, and others)

Here are two more modules for the new ImageSizerEngine System:

• ImageMagick CLI
• Netpbm CLI

Edited March 5, 2016 by horst

[Jugibur]

Thanks for clarification, Horst!

But unfortunately, stripping all markers (and icc-profiles) arent't always help to make a homogenuous rendering, because Browsers interpret images without profiles in different ways.

Try this test with Chrome, Firefox and, if you have, Safari:

http://cameratico.com/tools/web-browser-color-management-test/

Especially the section "How does your browser interpret untagged images and page elements?" is expressive:

It shows, that Chrome and Firefox interprets untagged images in a wrong way (to what the W3C recommends).

The colors are unnatural luminous compared to Safari (in OS X).

So if converting a profile isn't possible in practice why not let the admin choose, if he wants to preserve a icc-profile (like Adobe RGB)?

But is it possible just to preserve the icc-profile after resizing the image?

I have found different answers and infos and since I know from your post there are different builds / versions and sometimes the need of Little CMS, what's your opinion / infos here? 

[horst]

@jugibur: just to clarify: PW doesn't alter the original image per default. There is only one situation where the original image will be altered: If you have settings for max-image-width or height set with an imagefield and an uploaded image exeed those limits, then PW creates a resized variation and stores that as the original! Otherwise, the original image will not get touched in any way!

So, in short, ;-)

The common denomination for colorspaces is sRGB! Browsers (and all other PC devices in a colorspace chain) per default do assume the sRGB profile, at least, if a profile is missing. Therefore, no ICC profile is needed.

If you want to use more advanced features, should this be done automated by a webbrowser? We all know that different webbrowsers has done and do interpret features in different implementations, regardless of W3C standards. This is for different reasons: product- / company- political, simply missunderstood things or bugs, or what ever. If you want to publish images, do you really want to go that far, that you want use/try browser- or feature-sniffing, and than serve different imagevariations (with and without ICC) on assumed browsertypes? Using sRGB is the fastest (and a painless) way to serve homogenious results to different browsers.

But what I meant with homogenious, was not how the images will look like in browsers of different vendors. I meant, that the way how PW handles the manipulations should be nearly independend of the used or available engine(s). So, per default, we use the lowest denominator, what is GD or everything else without ICC conversion possibilties.

Also, for the average user and in most cases ( > 99% ?), the images will be in sRGB colorspace. Hopefully, most people who uses other colorspaces, also have a bit knowledge about imagehandling and therefor will know what they do. So, for those people, it may be an optional comfort feature to have ICC, but I'm not 100% sure, if this is really a comfort, despite all downside aspects.

Long story / short saying: The default and core in PW only will have features that are used and or available for more than 30% of (assumed) PW installations.

All other things belong into third party tools / modules.

[Jugibur]

Yes, sRGB is the standard for the web and the most devices are able to show this more or less in the same way.

My question above about preserving an icc-profile after resizing (perhaps for a thumbnail) was because even if you have sRGB converted images, but they are tagged with an sRGB-profile, they are different rendered on wide-gammut monitors on nearly all browsers (tested on OS X).

Without an sRGB-profile embedded they shown more saturated / luminous on wide-gammut monitors.

Yes, the graphic designer / photographer should do the right things in his editing app before embedding it to a website, but that's another topic. 

Lets imagine / assume an editor haven't the possibilities or the knowledge to correct his images in the "right" way... 

So even stripping an sRGB profile from a sRGB converted image have effects. That's why I'm asked for the possibility to let the admin choose if the profile should preserved (or more general, if it is possible *without* Little CMS anyway). 

[horst]

... (or more general, if it is possible *without* Little CMS anyway). 

Ah, sorry, don't got this fully. With the everywhere available GD lib it is not possible to do any sort of colorspace detection / prevention / conversion.

With ImageMagick, as CLI or PHP-Extension, it is only possible with compiled-in lcms to proceed colorspace operations. And only then, it would make sense to keep an ICC profile.

To clarify my understanding of a colorspace workflow:

• detect the colorspace (ICC profile) of the incoming image
• transform it into a workflow colorspace (e.g. AdobeRGB or ECI-RGB)
• do all manipulations
• transform it into sRGB colorspace just before output
• optionally embedd sRGB profile

I never would use the incoming profile as the output-profile, I ever would transform into sRGB. (Browsers and CMS's are not Photoshop, ;-))

Embedding an output profile into an imagevariation requires lcms. Processing it in the above workflow will increase the processing time up to 4 times for every variation. We have tested a lot on this two years ago.

[Jugibur]

Ok, now it's clear, thanks for your explanations!