Legacy ImageMagick Discussions Archive

IM 6.8.7.1 beta Mac OSX Snow Leopard

# create linear gray, but gamma=0.4545 and not gamma=1

imbh convert xc:"gray(50%)" gray_linear.png

Code: Select all

Image: gray_linear.png
  Format: PNG (Portable Network Graphics)
  Mime type: image/png
  Class: DirectClass
  Geometry: 1x1+0+0
  Units: Undefined
  Type: Grayscale
  Endianess: Undefined
  Colorspace: Gray
  Depth: 16/1-bit
  Channel depth:
    gray: 16-bit
  Channel statistics:
    Gray:
      min: 32767 (0.499992)
      max: 32767 (0.499992)
      mean: 32767 (0.499992)
      standard deviation: 0 (0)
      kurtosis: 0
      skewness: 0
  Colors: 1
  Histogram:
         1: (32767,32767,32767) #7FFF7FFF7FFF gray(49.999237048905165182%)
  Rendering intent: Undefined
  Gamma: 0.45455
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Background color: gray(255)
  Border color: gray(223)
  Matte color: gray(189)
  Transparent color: gray(0)
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 1x1+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Zip
  Orientation: Undefined
  Properties:
    date:create: 2013-10-15T16:05:16-07:00
    date:modify: 2013-10-15T16:05:16-07:00
    png:bKGD: chunk was found (see Background color, above)
    png:cHRM: chunk was found (see Chromaticity, above)
    png:gAMA: gamma=0.45455 (See Gamma, above)
    png:IHDR.bit-depth-orig: 16
    png:IHDR.bit_depth: 16
    png:IHDR.color-type-orig: 0
    png:IHDR.color_type: 0 (Grayscale)
    png:IHDR.interlace_method: 0 (Not interlaced)
    png:IHDR.width,height: 1, 1
    png:text: 2 tEXt/zTXt/iTXt chunks were found
    signature: a062f1b579409527e2ff138cd134ef5f124ff5de934c02151398d5742338cfb9
  Artifacts:
    filename: gray_linear.png
    verbose: true
  Tainted: True
  Filesize: 240B
  Number pixels: 1
  Pixels per second: 1000TB
  User time: 0.000u
  Elapsed time: 0:01.000
  Version: ImageMagick 6.8.7-1 2013-10-08 Q16 http://www.imagemagick.org

PS. Just downloaded the latest beta and this is still the same problem as above. I also confirmed this same problem with miff format

Has this linear vs non-linear for grayscale been removed so that all gray is non-linear and one then needs to follow it with -grayscale rec709luminance?

Where is the bug? The command ...

Code: Select all

convert xc:{any_colour} g.png

... should create a consistent output, whatever the colour. The result should be sRGB, gamma=0.4545.

Or am I misunderstanding?

snibgo wrote:Where is the bug? The command ...
Code: Select all
convert xc:{any_colour} g.png
... should create a consistent output, whatever the colour. The result should be sRGB, gamma=0.4545.

Or am I misunderstanding?

gray colors defined without parenthesis are non-linear and with parenthesis are linear. At least that was the way I thought it was supposed to be. It should be that way also for grayscale gradients. It used to be that for quite a while now.

See changelog

2012-07-08 6.7.8-3 Cristy <quetzlzacatenango@image...>
Return linear grayscale for gradient:white-black.
gradient:white-black is sRGB whereas gradient:'icc-color(rgb,255,255,255)- icc-color(rgb,0,0,0)' is linear RGB whereas gradient:'gray(255)-gray(0)' is linear grayscale.

# this is non-linear (gamma=0.4545)
imbh convert -size 100x100 gradient:gray50 -verbose info:

Code: Select all

Image: gradient:gray50
  Format: GRADIENT (Gradual linear passing from one shade to another)
  Class: DirectClass
  Geometry: 100x100+0+0
  Units: Undefined
  Type: Grayscale
  Base type: Grayscale
  Endianess: Undefined
  Colorspace: Gray
  Depth: 16/1-bit
  Channel depth:
    gray: 16-bit
  Channel statistics:
    Gray:
      min: 32639 (0.498039)
      max: 65535 (1)
      mean: 49087 (0.74902)
      standard deviation: 9591.7 (0.14636)
      kurtosis: -1.20024
      skewness: 5.72215e-09
  Colors: 100
  ...
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Tile geometry: 100x100+0+0
  Background color: gray(255)
  Border color: gray(223)
  Matte color: gray(189)
  Transparent color: gray(0)
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 100x100+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Undefined
  Orientation: Undefined
  Properties:
    date:create: 2013-10-15T17:17:02-07:00
    date:modify: 2013-10-15T17:17:02-07:00
    signature: fd8afef0b40235705380eef107e245e7cf374d00a179323fcbc9c2c3890139d5
  Artifacts:
    filename: gradient:gray50
    verbose: true
  Tainted: True
  Filesize: 0B
  Number pixels: 10K
  Pixels per second: 27KB
  User time: 0.000u
  Elapsed time: 0:01.369
  Version: ImageMagick 6.8.7-1 2013-10-15 Q16 http://www.imagemagick.org

#This was supposed to be linear:
imbh convert -size 100x100 gradient:"gray(50%)" -verbose info:

Code: Select all

Image: gradient:gray(50%)
  Format: GRADIENT (Gradual linear passing from one shade to another)
  Class: DirectClass
  Geometry: 100x100+0+0
  Units: Undefined
  Type: Grayscale
  Base type: Grayscale
  Endianess: Undefined
  Colorspace: Gray
  Depth: 16/1-bit
  Channel depth:
    gray: 16-bit
  Channel statistics:
    Gray:
      min: 32767.5 (0.5)
      max: 65535 (1)
      mean: 49151.2 (0.75)
      standard deviation: 9554.23 (0.145788)
      kurtosis: -1.20024
      skewness: -7.47046e-08
  Colors: 100
 ...
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Tile geometry: 100x100+0+0
  Background color: gray(255)
  Border color: gray(223)
  Matte color: gray(189)
  Transparent color: gray(0)
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 100x100+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Undefined
  Orientation: Undefined
  Properties:
    date:create: 2013-10-15T17:19:24-07:00
    date:modify: 2013-10-15T17:19:24-07:00
    signature: a86eb252d877620137ccfa348dee337b5e39a6114b825bb83c76f8b14c5b9939
  Artifacts:
    filename: gradient:gray(50%)
    verbose: true
  Tainted: True
  Filesize: 0B
  Number pixels: 10K
  Pixels per second: 10EB
  User time: 0.000u
  Elapsed time: 0:01.000
  Version: ImageMagick 6.8.7-1 2013-10-15 Q16 http://www.imagemagick.org
Fred-Weinhauss-Mac-mini:images fred$

So this is also a bug.

Ah, I see what you are are saying. That changelog entry is old. I think IM shouldn't treat gray differently to colours. When it does (which it did from approx 6.7.9 to 6.8.5), we get into difficulties when a colour image becomes gray or nearly gray, or we use a gray image to modify a colour image, and so on.

It seems to me that gray(50%) should be and do the same as rgb(50%,50%,50%).

icc-color is different, as that explicitly states the colorspace.

snibgo wrote:Ah, I see what you are are saying. That changelog entry is old. I think IM shouldn't treat gray differently to colours. When it does (which it did from approx 6.7.9 to 6.8.5), we get into difficulties when a colour image becomes gray or nearly gray, or we use a gray image to modify a colour image, and so on.

It seems to me that gray(50%) should be and do the same as rgb(50%,50%,50%).

icc-color is different, as that explicitly states the colorspace.

I believe that was why the icc-colors were introduced so that you could create linear rgb or non-linear srgb.

Both of those seem to work properly (in terms of gamma) in the latest IM 6.8.7.1 beta.

imbh convert xc:"icc-color(rgb, 0.5,0.5,0.5)" -verbose info:
gamma=1

imbh convert xc:"icc-color(srgb, 0.5,0.5,0.5)" -verbose info:
gamma=0.4545

snibgo wrote:Ah, I see what you are are saying. That changelog entry is old. I think IM shouldn't treat gray differently to colours. When it does (which it did from approx 6.7.9 to 6.8.5), we get into difficulties when a colour image becomes gray or nearly gray, or we use a gray image to modify a colour image, and so on.

It seems to me that gray(50%) should be and do the same as rgb(50%,50%,50%).

icc-color is different, as that explicitly states the colorspace.

Maybe this is going beyond what you're saying, but how can gray be treated the same as colors in general when colors have essential colorspace distinctions like RGB vs sRGB and the Gray colorspace stores no such distinctions (unless we try to convey this via image->gamma for grayscale images only)? (I still think we should have a CieLuminance or CieY colorspace for linear grays.) I'm talking about images within IM in general, not necessarily values as designated by rgb() or icc-color().

(I still think we should have a CieLuminance or CieY colorspace for linear grays.)

From your other note at viewtopic.php?f=2&t=24191&start=30#p103941, it would appear that you want Y from XYZ. Is that correct?

We already have XYZ colorspace, so you just need to extract the green channel from it. I was under the impression that XYZ was a linear colorspace, if I am not mistaken. (http://en.wikipedia.org/wiki/CIE_1931_color_space)

It is stored internally as per the following, but it looks like it is stored as non-linear. I am not sure this is correct.

mbh convert rose: -colorspace XYZ -verbose info:
Image: rose:
Format: PPM (Portable pixmap format (color))
Mime type: image/x-portable-pixmap
Class: DirectClass
Geometry: 70x46+0+0
Units: Undefined
Type: TrueColor
Endianess: Undefined
Colorspace: XYZ
Depth: 8/1-bit
Channel depth:
red: 16-bit
green: 16-bit
blue: 16-bit
...
Rendering intent: Perceptual
Gamma: 0.454545

If you really think this is needed, then post the suggestion as an enhancement on this forum and see what the IM developers reply.

Dabrosny wrote:Maybe this is going beyond what you're saying, but how can gray be treated the same as colors in general when colors have essential colorspace distinctions like RGB vs sRGB and the Gray colorspace stores no such distinctions (unless we try to convey this via image->gamma for grayscale images only)? (I still think we should have a CieLuminance or CieY colorspace for linear grays.) I'm talking about images within IM in general, not necessarily values as designated by rgb() or icc-color().

Colorspaces RGB and sRGB are meaningful to gray images, just as they are to images with colour.

A colorspace defines the meaning of the pixel values. For a three-channel image where the channels represent red, green and blue, a colorspace has the same meaning whether or not the channels happen to be equal. When they are equal, we can save time and space by storing only one channel but this doesn't change the meaning of a colorspace.

There are an infinite number of possible colorspaces, but two that are of particular importance are RGB and sRGB.

An image that happens to be grey might have a colorspace of RGB or sRGB (or one of an infinite number of other colorspaces).

When we create an image with "xc:{any_colour}", IM assumes the colorspace is sRGB. We can test this by converting to sRGB and comparing the result with the original. ("-compare" just looks at pixel values, ignoring the colorspace.) Windows syntax:

Code: Select all

%IM%convert ^
  xc:{any_colour} ^
  ( +clone -set colorspace HSL ) ^
  -metric RMSE ^
  -format %%[distortion] ^
  -compare ^
  info:

This returns zero for various colours, including khaki, gray50, rgb(50%%,50%%,50%%) and gray(50%%). I think this is good behaviour.

fmw42 wrote:
(I still think we should have a CieLuminance or CieY colorspace for linear grays.)
Are these from CieLab or YCbYCr, namely linear versions of the first channel of CIELab or YCbCr? Please clarify.

It is the Y in CIE 1931 XYZ, which is the same Y that L* in CIELab is defined nonlinearly in terms of, yes.

I'm not as familiar with YCbCr but if you mean the nonlinear luma Y', then no, luma is defined as an ad hoc linear combination of nonlinear R', G', and B' rather than directly in terms of linear luminance Y. But the same linear Y probably does appear somewhere in there, not directly related to luma Y' but linearly related to the linear RGB for those primaries (linear versions of R', G', B').

What I want is exactly what's produced today by applying -grayscale rec709luminance to an srgb input image (no further formula clarification required), but identified as such as CieLuminance or something similar.

fmw42 wrote: Note we already can create linear Y from -grayscale rec601luminance or rec709luminance.

I know, -grayscale rec709luminance is what I've been using to linearize sRGB because it uses the rec709 primaries.
(But you have to *know* that fact, and the fact that you have to start with sRGB and not linear RGB as seemingly indicated in the documentation page.)
The problem is that the result is not identified by a colorspace other than "gray", so further processing doesn't recognize it for what it is.

Dabrosny wrote:If you really think these are needed, then post the suggestion (with clarification of what you want as per my question) on this forum and see what the IM developers reply.

That's what I have been asking for for two weeks in my thread "need explicitly linear and nonlinear GRAY colorspaces", which begins "To avoid ambiguity with "Gray", I suggest that we add an explicitly-linear 1-channel colorspace called Luminance (or LinearGray...)",
and later:

Dabrosny wrote:I would like to be able to do
Code: Select all
      -colorspace Luminance
(or CieY or LinearY or RelativeLuminance or LinearGrayscale or what ever we want to call it) in order to produce the standard linear luminance from *any* initial colorspace.

My post was modified while you were posting after I saw you wanted Y from XYZ. Please re-read my post above.

What I want is exactly what's produced today by applying -grayscale rec709luminance to an srgb input image (no further formula clarification required), but identified as such as CieLuminance or something similar.

I am not a colorspace expert, but LAB L is not the same as Y from YCbCr which is the same as rec709luma.

XYZ should be linear, but IM seems to have it coded as non-linear with a gamma=0.4545. I do not believe that is correct.

So I am confused, since Y from XYZ may be related to L from LAB, but I am not sure it is the same as Y from YCbCr even if in linear form. Thus I am not sure what you want if you want it to be the same as rec709luminance, which is the same as a linear Y from a linear YCbCr. Correct me if I am wrong about this.

fmw42 wrote:
What I want is exactly what's produced today by applying -grayscale rec709luminance to an srgb input image (no further formula clarification required), but identified as such as CieLuminance or something similar.
I am not a colorspace expert, but LAB L is not the same as Y from YCbCr which is the same as rec709luma.

I didn't say that Lab L is the same as Y, I said "L* in CIELab is defined nonlinearly in terms of" (CIE linear) Y.
Specifically, L* = 116 x f(Y) - 16 where f(Y) is a specific function of the CIE linear luminance Y.

It is not clear to me from the formulas in command-line-options.html whether "YCbCr" is the usual nonlinear colorspace (more correctly written as Y'CrCb where Y' is the rec709 Luma) defined in terms of gamma-compressed R',G',B', or whether it is a linear equivalent where Y is the linear luminance.

I don't want the rec709 luma (which is nonlinear) at all; I want the original linear "rec709luminance" (which I'm calling Cie Y), which IM can already calculate (correctly!) as rec709luminance, so there isn't any question about how to calculate it or "which Y".

You're missing my point -- it isn't that IM can't calculate Y, but just that once it does, it labels it as being in a generic "gray" colorspace which is then assumed to be nonlinear (like a grayscale version of sRGB)

It should identify the colorspace as CieY or CieLuminance (or Luminance or LinearLuminance or LinearGray or even rec709luminance though the latter is somewhat misleading as i mentioned).

fmw42 wrote: XYZ should be linear, but IM seems to have it coded as non-linear with a gamma=0.4545. I do not believe that is correct.

So I am confused, since Y from XYZ may be related to L from LAB, but I am not sure it is the same as Y from YCbCr even if in linear form. Thus I am not sure what you want if you want it to be the same as rec709luminance, which is the same as a linear Y from a linear YCbCr. Correct me if I am wrong about this.

I want the numeric data values of the image to be the same as what is currently produced when "-grayscale rec709luminance" is applied to an image that is initially in sRGB colorspace, period. Everything else is just me trying to explain what this is and isn't equal to.

If by "linear Y from a linear YCbCr" you mean a directly gamma-expanded version of nonlinear rec709luma, this is not equal to rec709luminance (try some examples if you don't believe me), and this is not the way rec709luminance is calculated, and so this is not what I want.

If instead you mean a specific linear combination of the linear RGB (where the latter is defined using rec709 (thus sRGB) primaries) as is currently done by -grayscale rec709luminance, then, yes, this is what I want.

snibgo wrote:
Dabrosny wrote:Maybe this is going beyond what you're saying, but how can gray be treated the same as colors in general when colors have essential colorspace distinctions like RGB vs sRGB and the Gray colorspace stores no such distinctions (unless we try to convey this via image->gamma for grayscale images only)? (I still think we should have a CieLuminance or CieY colorspace for linear grays.) I'm talking about images within IM in general, not necessarily values as designated by rgb() or icc-color().
Colorspaces RGB and sRGB are meaningful to gray images, just as they are to images with colour.

A colorspace defines the meaning of the pixel values. For a three-channel image where the channels represent red, green and blue, a colorspace has the same meaning whether or not the channels happen to be equal. When they are equal, we can save time and space by storing only one channel but this doesn't change the meaning of a colorspace.
...

An image that happens to be grey might have a colorspace of RGB or sRGB (or one of an infinite number of other colorspaces).

Yes! I agree with you 100%. But then why doesn't the colorspace of a grayscale image show as "RGB" or "sRGB" in IM? Instead it shows as "gray", from which we can't tell whether its values represent linear (RGB) data or nonlinear (sRGB) data.

Currently IM assumes sRGB when the colorspace is "gray", which is often a good default.
But this doesn't make sense when, for example, the grayscale image is the result of -grayscale rec709luminance, or the image is the result of reading in a png file having gAMA=1 (and no sRGB chunk).

So, for a grayscale image that is known to be linear, I believe the colorspace either needs to be set as "RGB", or some new colorspace that is linear like RGB but also indicates that it is grayscale, such as CieY or CieLuminance or Luminance or even RGBgray -- I'm not as particular about which.

I prefer GrayLog and GrayLinear (as well as Gray which would mean gamma is unspecified).

glennrp wrote:I prefer GrayLog and GrayLinear (as well as Gray which would mean gamma is unspecified).

I'm fine with GrayLinear (I think it''s clear enough, even if it could be said to beg the question, linear in what or linearly-related to what?, the most specific answers being that it's a linear function of Luminance or Luminous intensity(SI unit: candela), luminosity, radiant intensity, or perhaps even "light" itself).

I very much like the idea of having an explicitly-sRGB-compressed nonlinear gray colorspace in addition to generic gray.

GrayLog sounds like it would be the logarithm of linear luminance, which is useful in itself (especially for HDR grayscale images!) but not the same as an sRGB-gamma-compressed Luminance.

How about sRGBgray (or maybe even sGray for short)? I've seen ICC color profiles called sRGBgray.icm which I assume are meant to describe this grayscale colorspace with the specific sRGB nonlinearity (with the linear base pasted together with gamma 2.4).

If I understand you correctly, you want a new colorspace lineargray or some such thing. But this would only be understood internally by IM. I do not believe any image format would know what to do with that (lineargray named) colorspace. Glennrp can correct me.

It appears that -grayscale rec709luminance is what you want, but you want it to be called something like lineargray. Since it is currently labeled gray with gamma=1, those image formats that can deal with it are fine and internally IM can handle it.

The only issue I see is that IM may not know the difference between gray gamma=1 from rec709luminance and gray gamma=1 from rec609luminance.

Legacy ImageMagick Discussions Archive

[Resolved] possible bug linear gray still has gamma=0.4545

[Resolved] possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545

Re: possible bug linear gray still has gamma=0.4545