Has the meaning of -colorspace RGB and colorspace sRGB been swapped recently. Anthony has be saying, if I am not mistaken, that they are backwards and that -colorspace RGB really means sRGB. But I just looked at logo: whose verbose info says sRGB and tried:
convert logo: -colorspace sRGB logo_srgb.jpg
and
convert logo: -colorspace RGB logo_rgb.jpg
logo_srgb.jpg looks like the original logo:, but logo_rgb.jpg looks much darker.
colorspace sRGB vs RGB
- anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
Re: colorspace sRGB vs RGB
Magick did some work on the colorspace in IMv6 (though I wanted to have that pushed to IMv7)
I have no idea of the fall out from this, but I doubt it was good (which was why I wanted it made in IMv7)
My current feelings after reading how other programs handle this, is that RGB should mean 'undefined RGB' and we specifically have a sRGB, gammaRGB, and linearRGB, when it is known, or when an image does become 'known' or declared.
Note this also effects how named colors are 'added' to an image, and posibly how some operations are 'performed'.
I have no idea of the fall out from this, but I doubt it was good (which was why I wanted it made in IMv7)
My current feelings after reading how other programs handle this, is that RGB should mean 'undefined RGB' and we specifically have a sRGB, gammaRGB, and linearRGB, when it is known, or when an image does become 'known' or declared.
Note this also effects how named colors are 'added' to an image, and posibly how some operations are 'performed'.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
Re: colorspace sRGB vs RGB
See http://en.wikipedia.org/wiki/SRGB:
For this reason, one can generally assume, in the absence of embedded profiles or any other information, that any 8-bit-per-channel image file or any 8-bit-per-channel image API or device interface can be treated as being in the sRGB color space.
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: colorspace sRGB vs RGB
Can one of you tell me at what release the switch occurred, so that I can put a version switch in my scripts.
Re: colorspace sRGB vs RGB
6.7.5-5.
Re: colorspace sRGB vs RGB
I think this is related, but I'm not entirely sure how, so I thought I'd plea for help:
I have a png that I'm using IM to convert to grayscale. The png has no colorspace info in it. The info below uses convert, but I'm actually using ExportImagePixels.
pngcheck -vvt bad.png | head
File: bad.png (587755 bytes)
chunk IHDR at offset 0x0000c, length 13
640 x 480 image, 24-bit RGB, non-interlaced
With 6.7.8-6 I get
convert bad.png txt:- | head -2 ; convert bad.png -colorspace gray g.png; convert g.png -colorspace gray txt:- | head -2
# ImageMagick pixel enumeration: 640,480,255,srgb
0,0: ( 35, 37, 52) #232534 srgb(35,37,52)
# ImageMagick pixel enumeration: 640,480,255,gray
0,0: ( 5, 5, 5) #050505 gray(5,5,5)
With 6.7.6-4 I get
convert bad.png txt:- | head -2 ; convert bad.png -colorspace gray g.png; convert g.png txt:- | head -2
# ImageMagick pixel enumeration: 640,480,255,srgb
0,0: ( 35, 37, 52) #232534 srgb(35,37,52)
# ImageMagick pixel enumeration: 640,480,255,gray
0,0: ( 38, 38, 38) #262626 grey15
At this point, I'm a bit confused. I want the second case but I'm not quite sure where the conversions/interpretations between linear and non-linear are happening.
Thanks!
I have a png that I'm using IM to convert to grayscale. The png has no colorspace info in it. The info below uses convert, but I'm actually using ExportImagePixels.
pngcheck -vvt bad.png | head
File: bad.png (587755 bytes)
chunk IHDR at offset 0x0000c, length 13
640 x 480 image, 24-bit RGB, non-interlaced
With 6.7.8-6 I get
convert bad.png txt:- | head -2 ; convert bad.png -colorspace gray g.png; convert g.png -colorspace gray txt:- | head -2
# ImageMagick pixel enumeration: 640,480,255,srgb
0,0: ( 35, 37, 52) #232534 srgb(35,37,52)
# ImageMagick pixel enumeration: 640,480,255,gray
0,0: ( 5, 5, 5) #050505 gray(5,5,5)
With 6.7.6-4 I get
convert bad.png txt:- | head -2 ; convert bad.png -colorspace gray g.png; convert g.png txt:- | head -2
# ImageMagick pixel enumeration: 640,480,255,srgb
0,0: ( 35, 37, 52) #232534 srgb(35,37,52)
# ImageMagick pixel enumeration: 640,480,255,gray
0,0: ( 38, 38, 38) #262626 grey15
At this point, I'm a bit confused. I want the second case but I'm not quite sure where the conversions/interpretations between linear and non-linear are happening.
Thanks!
Re: colorspace sRGB vs RGB
Hmmm ... just realized I'm not spanning 6.7.5-5 so maybe this isn't related?
I'm still unsure if I'm doing something wrong or if it's a bug.
I'm still unsure if I'm doing something wrong or if it's a bug.
- fmw42
- Posts: 25562
- Joined: 2007-07-02T17:14:51-07:00
- Authentication code: 1152
- Location: Sunnyvale, California, USA
Re: colorspace sRGB vs RGB
From my experiments there are about 3 different ranges of IM versions where colorspace (RGB vs sRGb) changed considerably. Also the PNG image format has undergone lots of changes over many releases. You can see much of this in the http://www.imagemagick.org/script/changelog.php
My categories where major changes occured are:
1) Before IM 6.7.6.6
2) Between 6.7.6.6 and 6.7.7.7 (during the time RGB was swapped with sRGB)
3) After 6.7.7.7 and possibly not until 6.7.8.3 (about the time grayscale became linear)
That may be were you are seeing the difference, though I am not totally sure. The changes that I have had to make for my scripts have been combinations of swapping references to -colorspace RGB and -colorspace sRGB and to add -set colorspace RGB before -colorspace gray. That makes the linear gray image be treated as if it were non-linear.
Can you provide a link to your bad.png image?
My categories where major changes occured are:
1) Before IM 6.7.6.6
2) Between 6.7.6.6 and 6.7.7.7 (during the time RGB was swapped with sRGB)
3) After 6.7.7.7 and possibly not until 6.7.8.3 (about the time grayscale became linear)
That may be were you are seeing the difference, though I am not totally sure. The changes that I have had to make for my scripts have been combinations of swapping references to -colorspace RGB and -colorspace sRGB and to add -set colorspace RGB before -colorspace gray. That makes the linear gray image be treated as if it were non-linear.
Can you provide a link to your bad.png image?
Re: colorspace sRGB vs RGB
https://dl.dropbox.com/u/11615635/bad.png
-set colorspace RGB is what I was looking for:
convert bad.png txt:- | head -2 ; convert bad.png -set colorspace RGB -colorspace gray g.png; convert g.png txt:- | head -2
# ImageMagick pixel enumeration: 640,480,255,srgb
0,0: ( 35, 37, 52) #232534 srgb(35,37,52)
# ImageMagick pixel enumeration: 640,480,255,rgb
0,0: ( 38, 38, 38) #262626 rgb(38,38,38)
and I've done the same thing in my app and it's doing exactly what I want. Thanks!
-set colorspace RGB is what I was looking for:
convert bad.png txt:- | head -2 ; convert bad.png -set colorspace RGB -colorspace gray g.png; convert g.png txt:- | head -2
# ImageMagick pixel enumeration: 640,480,255,srgb
0,0: ( 35, 37, 52) #232534 srgb(35,37,52)
# ImageMagick pixel enumeration: 640,480,255,rgb
0,0: ( 38, 38, 38) #262626 rgb(38,38,38)
and I've done the same thing in my app and it's doing exactly what I want. Thanks!