- the default input setting RGB actually represents sRGB, though it could also represent linear RGB when processing mathematical images.
- the operation -colorspace sRGB actually converts a sRGB image to a linear image, which is the oppisite of what the operation seems to emply
- consequently most operations used by users are being performed against non-linear data. and to 'do it right' requires some extra work
See http://www.imagemagick.org/Usage/resize ... colorspace
- draw is also a linear operation but color names are sRGB so if you convert your image to linear colorspace and draw he color, that color will be wrong when you convert the image back to sRGB colorspace.
- it is also known if the other colorspace conversions are actually assuming a RGB image is sRGB or linear RGB!
- then we have gamma-RGB images, and grayscale that could also be linear,srgb,gamma modified (masks and alpha are always linear)
- when you say gray50 do your mean a linear mahematical 50% gray, or a sRGB (darker) 50% gray?
- colorspace conversions have major rounding issues when 8 bot values are used internally (IM Q8)
- image +gamma setting is not currently used by anyone with any great effect. PNG codec uses it, but its use destroys the image results.
NOTE IMv7 allows the use of more channels, and even the processing single channel grayscale images!
PS: I have already be caught by grayscale PNG images in IMv7 devleopment!!!
Some Ideas include...
- make colorspace sRGB actually mean sRGB! and verify handling of other colorspace conversions
- add a -linear +linear setting that defines if input/output of images should be regarded RGB or sRGB, (sRGB assumed by default)
- alturnativally "image" (-read/-write operation) always reads a sRGB image
but add a -import /-export operation for mathematical (linear) images or other 'unspecified in image' color spaces.
- OR users must use a -set colorspace after reading linear images! -- this works for input, not outptut!!!!
- attach to individual colors the colorspace of those colors so they can be converted as needed to match the image in question (draw, color compares)
- either give a 'warning' or 'auto-convert to linear' for operations that need images in linear format!
- Note this actually includes quantization and dithering which is vital for GIF color reduction, only afterward should colors convert automatically to sRGB for saving (unless 'linear' flag is set)
- Remove the use of 'gamma' setting.
As part of this, John Cupitt of VIPS image processing package, was asked by Nicholas Robidoux for his view and solutions he went though for the VIPS package. He responded with a summery on the VIPS blog...
http://libvips.blogspot.com.au/2012/01/ ... olour.html
It looks like (but not directly specified) that images being read in are automatically converted to XYZ colorspace for processing, but all other operations assume the user is knowing what they are doing. No colorspace setting is attached to the image themselves, and it simplifies everything, but may make working with special colorspaces (like Hue), more difficult.
NOTE: this means image data values in memory may have little equivalence to the image actually loaded, but then we have that issue in IM already, just not that big a difference as RGB remains RGB. Do we want to go that far?