Page 2 of 2

Re: Resizing properly in a world of {default=sRGB}

Posted: 2011-04-16T00:44:53-07:00
by Wolfgang Woehl
magick wrote:It looks like the docs are wrong (we'll correct that). The source code uses 0.04045 for K0.
Ugh, I was grepping an ancient version. Apparently 6.6.3-10 was the last one that used 0.03928f. Sorry for the noise.

Re: Resizing properly in a world of {default=sRGB}

Posted: 2011-04-17T06:50:46-07:00
by anthony
One point that the Wikipedia for sRGB article makes, is that all images that do not specify a profile, should by default be considered sRGB.

I suppose that also means that by default, writing to images not containing a profile should also write sRGB.

This may require some transition (perfect for IM v7) but it also means that colorspace and profiles will need to be more tightly integrated, and 'linear' operations will need automatic switching of colorspace (profile) to a linear model.

However some method of specifying the input image is already 'linear' (or some specific profile) other than the default sRGB selection, will be needed.

This is a very important discussion.

Re: Resizing properly in a world of {default=sRGB}

Posted: 2011-04-17T07:53:17-07:00
by NicolasRobidoux
I agree it's super important.

Maybe what you need is some sort of flag that informs ImageMagick is to use the sRGB convention: no profile means sRGB on input and, independently, output, and intermediate operations should be done in linear space.

Something kinda like -web true/false with the default being true since sophisticated users will know when what they have is already in linear colorspace.

I think it is important that it be an option.

Re: Resizing properly in a world of {default=sRGB}

Posted: 2011-04-17T18:33:24-07:00
by anthony
THIS is suggestions only, and currently no relation to the current working of IM

I would probably make it more like (type shouldn't really deal with 'Alpha' components)

Code: Select all

   convert   -colo-profile RGB  image.png    ....      output.png
This will read "image.png" as being a linear RGB image, and eventually writes the image as linear RGB.

ASIDE: Note -color-profile is in some ways doing what the option -type was intended to do when it was first created. I may be -type should be the option for this.

Even if some internal function changes stored colorspace the output color-profile remains RGB
As such something like this

Code: Select all

   convert   -color-profile RGB  image.png    .... -colorspace CMYK     output.png
would still output a linear RGB image.

Remember in this scenario the default -type will be sRGB, as some operators (resize, convolve, distort, etc) may automatically convert (if at least a IM Q16) images to linear RGB for processing.


Code: Select all

   convert   -color-profile RGB  image.png    .... -color-profile sRGB    output.png
would convert image from linear RGB to a sRGB color profile.

For JPEG it would replace the ICC and ICM color profile meta-data as appropriate, assuming IM actually knows where standard color profile information is.

Questions for Glenn...
Can PNG take profile information?
Can it handle CMYK?
Is CMYK ment to be linear?
Is their a sCMYK?
JPEG I believe converts colors to a YUV type color for actual fourier transform compression, as such it always maps colors to sRGB, unless a color profile is present. Is this correct?