Colorspace handling and the future of ImageMagick.

[anthony]

Colorspace in IMv6 has problems.

• 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.

Basically we need to form a strategy for handling things. in IMv7.
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.

Ideas, comments, suggestions, or completely new stratagies are welcome at this time.

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?

[fmw42]

some luminance definitions can be either plain or gamma corrected. see http://en.wikipedia.org/wiki/Luma_(video) and http://en.wikipedia.org/wiki/Luminance_(relative)

see also under terminology at http://en.wikipedia.org/wiki/Gamma_correction


So it is not clear to me whether IM is using linear or gamma corrected Rec609Luma and Rec709Luma colorspaces.

[anthony]

I am really confused about what this all means. I thought any "RGB" triplet was just that. If I define rgb=(10,110,210), then I mix r,g,b in that proportion. I assume that this is just what IM does to create any color defined by some triplet. Where does sRGB come in? I have never really understood sRGB and so far any explanations have not made sense to me. Does this have to do with some gamma correction or application after setting the triplet? Or does it have to do with some gamut limitations.

But does the values in rgb=(10,110,210) represent a linear RGB values, or some sRGB color? If sRGB (and that appears to be the intent) then what should you do if you draw this color to a linear RGB, keep the values (as the user wanted this values as is), or convert the user given values from sRGB to linear-RGB so the color remains correct!


Does a user giveing a value of grey(50%) mean a mathematical 50% gray value, or a visually perfect mid-tone gray which has a normalized value closer to a 75% value in sRGB colorspace?

EG: Does the user giving a value of gray(50%) mean mathematically (and visually) linear-RGB or a darker sRGB colorspace gray? This can be vital for working with FFT images, lighting shade overlays, and displacement maps, which are all mathematical, and working with linear-RGB images (including read and write).

This is also why Xwindows "grey" (a visual mid-tone gray) has very different color values to either a mathematical "gray50" (8-bit color), the SVG "grey" color, or a calculated 50% gray (all of which is a visually darker than mid-tone grey)

Code: Select all

convert xc:grey xc:gray50 xc:gray xc:'gray(50%)' +append txt:-
# ImageMagick pixel enumeration: 4,1,65535,rgb
0,0: (48830,48830,48830)  #BEBEBEBEBEBE  grey
1,0: (32639,32639,32639)  #7F7F7F7F7F7F  grey50
2,0: (32382,32382,32382)  #7E7E7E7E7E7E  gray
3,0: (32768,32768,32768)  #800080008000  rgb(50.0008%,50.0008%,50.0008%)

See ColorName conficts where X11 "gray" (which was the same values as X11 "grey") did not match the SVG "gray" colorname values.

All the discussion about IM 6 having backwards definition of -colorspace sRGB is making my head swim in trying to understand what sRGB means and how IM got it backwards.

It got it backward because in the very early days (IMv4 and before) -colorspace would initiallu define the colorspace of a image about to be read in. But it was also used to convert images to new colorspaces. That latter became more pominent, but sRGB handling didn't change!

Just know that -colorspace sRGB when applied to a image just read in converts FROM sRGB to linear RGB. That is what it does, and it is a pain! The headaches this caused me is why it was rarely brought up previously.

Is there some clear explanation of the difference or definitions? The link above does not help. It is just a statement with no clear explanation of what that means and how it relates to IM.

Nope, their never has been. Just what was coded. You remember what the IM 'options' documentation looked like years ago, single line description with no detail or explaination, it was why IM Examples are started in the first place!

Colorspace was just one area in which any 'fix' would cause major disruptions to scripts and programs, which is why it was always left for a major revision number change.

Alpha values at the start of IMv6 was also more 'matte' value handling, that changes one little step at a thing throughout IMv6 development. IMv7 is making that last conversions (level and thresholds) to alpha while adding mutli-channel handling.

[fmw42]

But does the values in rgb=(10,110,210) represent a linear RGB values, or some sRGB color?

I guess I am still confused about what sRGB means in context of a color triplet? How is that different from a linear representation? A color triplet is a color triplet (probably what you mean by linear), but it would have to undergo some gamma correction to be sRGB. But then the values are not 10,110,210 any more.

Color names may be another issue. They are still defined by only one set of triplets? Someone had to make that definition, X11 or CSS. Now I know there are some differences in the definition of a few colors between X11 and CSS (see http://en.wikipedia.org/wiki/X11_color_names). But I don't see how that relates to sRGB vs RGB.

I had always thought that given some (linear) color triplet, the display device/monitor would just automatically adjust (gamma correct) the triplet so that it looked correct. Is this not the case? So why does one need a sRGB color rather than just the linear triplet? I guess I am missing something fundamental as it just does not "click" with me.

[anthony]

What was actually confusing me, was when Anthony mentioned that IM colors (not images) were sRGB. I don't understand that. When you make a color for a pixel or swatch that is RGB=(255,0,0) how is that not linear?

Sorry to have bothered you.

It's no bother.

RGB(255,0,0) isn't a particularly good example because it's pure red
in a linear, rgb, or sRGB colorspace.

However, consider RGB=(127,00,0) which is half red intensity in a
linear colorspace but has about 0.5^(1/2.2) red intensity in sRGB.

If you have a linear-colorspace image, you have to boost the gamma
by 2.2 to display it properly on a sRGB monitor. But the viewer only
knows to do that if the image is somehow marked as being in a linear
colorspace (e.g., a PNG with a gAMA 1 chunk.

If your monitor has some other known colorspace, and you have
an ICC profile for it, then you can combine the known colorspace
of the image with the known colorspace of the monitor. Firefox,
for example, does that. Unfortunately there are a lot of improperly
marked images and monitors around, so Firefox can produce
unexpected results. That's compounded by the fact that Internet
Explorer handles gamma wrong, so you get different results
from IE and Firefox.

So for images that are intended for the web, probably the best
thing to do is convert them to sRGB with IM, and not mark
them with an sRGB or gAMA chunk because browsers are
going to assume sRGB anyhow.

Glenn

[anthony]

But does the values in rgb=(10,110,210) represent a linear RGB values, or some sRGB color?

I guess I am still confused about what sRGB means in context of a color triplet? How is that different from a linear representation? A color triplet is a color triplet (probably what you mean by linear), but it would have to undergo some gamma correction to be sRGB. But then the values are not 10,110,210 any more.

The point is are the values sRGB values (which is typical when specifying a color triplet), or are thye linear (for math and mapping image work)?

If sRGB (typical case). then to draw it 'correctly' on to a sRGB image both the image and the color will need to be converted ti linear-RGB, the values drawn, then the result converted back to sRGB. Currently such a color is typically drawn directly onto a sRGB image, and that we want to fix.

But users working with mathematical images will not want any such conversions done. The images and values being used are all linear-RGB (or linear-greyscale, or possibly even LAB, or XYZ). We need to ensure IM does the right thing when working with various images, and that means knowing if BOTH images and colors are in the colorspace required to draw on the image correctly.

Color names may be another issue. They are still defined by only one set of triplets? Someone had to make that definition, X11 or CSS. Now I know there are some differences in the definition of a few colors between X11 and CSS (see http://en.wikipedia.org/wiki/X11_color_names). But I don't see how that relates to sRGB vs RGB.

It seems that generally colors are all defines as sRGB color values. but user defined colors may not be known.
is that 'gray(50%) going to be used on a sRGB image or on a mathematical image. Perhaps in that case the colorspace is 'undefined' and the value just gets used directly, as appropriate for the 'normal' colorspace of the image.
Though IM sill needs to know if an image is a real sRGB type image, or a linear mathematical type of image.

I had always thought that given some (linear) color triplet, the display device/monitor would just automatically adjust (gamma correct) the triplet so that it looked correct. Is this not the case?

Only if the monitor or device knows the colorspace of the image, (by default sRGB if undefined).

[fmw42]

The point is are the values sRGB values (which is typical when specifying a color triplet), or are thye linear (for math and mapping image work)?

I do not understand what is the difference? Give me an example of a sRGB triplet values vs an RGB triplet values for the same color? This is the point that I do not understand. What does R=128, G=0, B=0 mean? Is that defining sRGB or RGB?

[anthony]

If you are drawing on a sRGB image that is a dark red or 'firebrick' color.

Code: Select all

 convert -size 100x100 xc:'rgb(128,0,0)' show:

But if you draw those values directly on a mathematical image, that is generate a visually half-dark red color (whcih is a lighter red than 'firebrick')

Code: Select all

 convert -size 100x100 xc:  -colorspace sRGB  -fill 'rgb(128,0,0)' -draw 'color 0,0 reset' -colorspace RGB  show:

(remember in IMv6 -colorspace sRGB converts to linear RGB)


Arrggghhhh.... Cristy has changed something!
I can no longer get... -set colorspace sRGB -colorspace RGB to make any change.
It is now broken backward compatibility as I can not convert linear images to sRGB images in IMv6.

This example from no longer produces a visually linear gradient with visually equal amounts of white and black, but more black than white.

Code: Select all

  convert -size 100x100 gradient: \
          -set colorspace sRGB -colorspace RGB gradient_sRGB.gif

From IM Example, sRGB Colorspace Correction
http://www.imagemagick.org/Usage/color_basics/#srgb


Anyway assume the above worked as we got a visually half-dark red (not firebrick)....

But if we want to draw onto a linear image (the correct way) a color which has sRGB values of (128,0,0), in other words 'firebrick' then the color much be converted to be linear RGB (made darker) before drawing.
That means IM must know us the user is wanting the values (128,0,0) to represent be sRGB (firebrick), or linear (half-red),
so IM can 'draw' then correctly.

The alternative is that colors like rgb(128,0,0) is undefined in terms of colorspace, and always applied as is (linear RGB or sRGB) but a named color like 'firebrick' is alwways regarded as a 'sRGB' color and much be converted to the equivelent linear-RGB color if being applied to a linear-RGB image

[fmw42]

OK, I am starting to see the picture now (pardon the pun). So IM creates canvas (xc:) colors with a built in gamma correction on the RGB triplet to sRGB. Seems odd to me in that your first example (sRGB swatch) is not what I would have expected to see (visually) color-wise. I would have expect to see a color like your second color, which I assume is linear RGB, but one has to go through hoops to get it that way. I don't really understand the background for sRGB (except that it has to do with monitors and gamma), but it all seems backwards to me. Colors look more correct when created as true linear RGB and then displayed.

(remember in IMv6 -colorspace sRGB converts to linear RGB)

So what does -colorspace RGB do, convert to sRGB (so that -colorspace RGB and -colorspace sRGB are reversed)?

Why does IM always want to create/use by default sRGB colors, when most if not all processing should be done in linear RGB?

[anthony]

Yes it should, but only if the image was already defined as being in colorspace sRGB If it was just read in then it is already ing marked as being RGB colorspace (actually sRGB).

Eg: convert image.gif -colorspace RGB ....
should do nothing as the image is marked as being RGB (through it is really sRGB)

-- unless this has now changed, as something has changed recently in IMv6.

[fmw42]

Sorry we crossed posted. See my edited comments above.

[anthony]

[Should IM assume the image is sRGB when there is no profile?

This is the concept that is being thought of. And the one that is recommended by the web consortium, for web browsers and other image programs. My starting post of this discussion was exactly that.

If most input images are to be assumed to be sRGB (when no profile is present), then how do we tell IM that 'this' image (whether read in or created) is to be thought as linear RGB (or linear grayscale) as it will be a mask or a mapping image, and thus already linear.

One method was a -linear setting to change the default.
Another was -import RGB "image" and -export "image" (from Nicholas)
and a third was \( "image.pgm" -set colorspace linear-RGB \)

The latter is my current preference, including the term 'linear-RGB', but I am open to discussion.

I would assume PNG as a simple way in which a PNG image would be thought as 'linear RGB' when it is read in. Perhaps it is a gMMA profile with a 0 setting?

Regardless some formats like GIF, and PbmPlus do not provide a way to specify it is linear RGB.

Gradient: images I would assume would gener

If this is the case, then it seems that any IM processing should automatically include a sRGB to RGB conversion before processing and the reverse after processing. This, then, should be automatic, unless the user specifies that the colorspace is not sRGB (perhaps by a -define or a pre-read -colorspace).

This is one of the questions I hope to answer in the public discussion.

As I know so little about this issue, these are just my thoughts. I do not know what is practical or even the correct way to handle it.

Hope you do not mind my bouncing my thoughts (and perhaps misconceptions) off you.

Again why I wanted a discussion.

[anthony]

Colorspace and PNG..

After a private discussion with Glen, it seems for PNG images...

• PNG with no gamma or color profile a PNG is to be assumed to be sRGB
• If it has gamma 1.0 it is linear
• There is a push to make 8-bit PNG use sRGB, but 16-bit PNG to be saved as linear.

[anthony]

Proposed IMv7 changes.

• Make IM colorspace label sRGB actually mean image data is sRGB, and not linear.
• Images reading PNG, GIF and JPEG default to marking images as being sRGB, unless specified otherwise (for example a gamma=1.0 profile in PNG), or user gives -set colorpace RGB.
• In a similar way: gradient images are 'RGB' by default, while most canvases generated using a colorname is 'sRGB'.
• Draw and other applications of color, has the color converted to the right colorspace before it is applied to a image.

Comments?

[rnbc]

As long as you can stil work with channels and values "as is", which is important for those using imagemagick as a research tool, I would say all operators could be made colorspace aware, and work differently for different colorspaces and different luminance functions.

How to make colorspace support generic? Well, that's a problem! The generic answer is:

- N channels
- Each channel has a specific spectral power curve and power baseline.
- Each channel has a specific luminance curve Y=f(X).

This makes it possible to represent any input device (raw sensor, or whatever) and any output device (even laser projectors, etc), and convert between representations any such representations (complex, but possible, even if a different number of channels is involved in each phase).

Using such a representation each colorspace is only a fes tables describing the spectral powers and luminance functions. Could even support user-defined colorspaces with ease.

The less generic answer is: assume some sort of RGB, and define a number o of colorspace conversion functions. Make the operators work in the largest gammut color space (CIE1931?) and convert from/to that colorspace as needed. Hope for the best.