[Almost bug] -colorspace sRPG option deceiving/inconsistant

[SineSwiper]

The way IMv6 handles 'sRGB' colorspace is actually reversed. That is to say specifying "-colorspace sRGB" converts a image from sRGB to RGB, and visa-versa. That is "-colorspace sRGB" actually converts an image from sRGB to linear RGB colorspace.

This was the result of IM choosing RGB as its internal default, rather that the network default of sRGB.

This colorspace handling weirdness is considered a bug, and is one aspect that will be fixed as part of the planned IMv7 development. However it will not be fixed in IMv6.

I'm not quite understanding the delay to fix this one. It's more of a wording problem than something to do with the internals. IMO, it should work like this:

• -colorspace sRGB - Converts to sRGB
• -colorspace oRGB - Converts to (original vanilla) RGB
• -colorspace RGB - Is an alias of sRGB

I picked sRGB as the alias of RGB, because it's more useful and standard in almost all cases. It gets rid of the super-darks, which also helps in quantization. Everybody's happy except for the guy who wants to actually go from sRGB to RGB, and that just requires some minor script adjustments to use the oRGB colorspace.

Oh, and while we're talking about colorspaces, can you add LMS? This one is pretty useful for human perception, and Wikipedia has a quick matrix on converting from XYZ to LMS.

[anthony]

The problem is that images that are generally read in are sRGB colorspace (mostly a gamma factor).
See Human Color Perception
http://www.imagemagick.org/Usage/color_ ... perception

But not all images are in this colorspace. many images (mostly mathematical and mask images) are linear RGB.

However operators in IM really should be using linear RGB form. And colors are specified in sRGB colors. That makes things very difficult.
See Drawing
http://www.imagemagick.org/Usage/draw/#colorspace

IM has grown organically over many years, Even the +gamma setting is not well documents and does not generally work as documented (+gamma just sets the image gamma level not change the gamma function)

It is only with the development of IMv7 we can look at a non-backward compatible change to fix these colorspace issues.
That way draw can draw using sRGB defined colors, on images in Linear RGB colorspace, just as it is supossed to. Also resize can then do its job using linear RGB values, even though the image is stored as sRGB! and so on.

These are important changes but not directly backward compatible.

[SineSwiper]

I keep hearing a lot about the mythical IMv7. Any idea when that's going to come out or at least when we'll see a beta?

[anthony]

It is being worked on.

Magick is currently working on 'write masks'.

While I have now completed a review of various options in the CLI, and am now writing code for a 'scripting' version of imagemagick. That is one that can read command line options from a file or pipe, allowing more program control of imageMagick processing, including co-processing (IM in backgroudn processing images, under full control of a parent shell, PHP or other program.

It can already can process images with just one channel (grayscale) images instead of enforcing a minimum three channel per image policy. and alpha channel really is an alpha channel (and not a matte channel with conversions). It can even handle images with multiple extra channels and masks.

Once these parts are done it will be released as 'alpha' for developers to work on it further. Eg: tightening of options, allow using of 'escapes' in more arguments, and improved colorspace handling, etc.

Schedule calls for about mid year for this.
For more information and notes see the IMv7 notes in IM Examples, Development and Bug reports
http://www.imagemagick.org/Usage/bugs/