[SOLVED] convert from sRGB to linear RGB

[NicolasRobidoux]

The alternative general rule would be that there is an automatic conversion only if the image format standard specifically states that pixel values are to be understood as sRGB.
But then, what happens if you know ahead of time that what you have is sRGB (although it's untagged), and consequently do not want any conversion?
Maybe it's just better to leave things as they are (take pixel values literally, without, say, automatically converting to sRGB if storing to PNG), and let the user do the necessary colourspace conversions.

I do understand that this is a tricky call.

[NicolasRobidoux]

And of course even the PNG situation is not so simple: http://hsivonen.iki.fi/png-gamma/

[NicolasRobidoux]

Ideally all formats would declare their colorspace and gamma, many do not. Without this information we must make assumptions about these attributes. For PNM, we assume sRGB. When you write PNM, ImageMagick converts the colorspace to sRGB. We could easily support writing linear RGB to PNM but then the user has no way of knowing its linear RGB and would assume sRGB. The user must then explicitly set the colorspace to linear RGB. If we always assume sRGB, we get consistent results without user intervention. What's your preference?

I'd rather have the pixel values stored with as little modification as possible given the output format, and having to explicitly specify a colorspace or ICC-based conversion even in cases where almost invariably it would have to be performed to match general expectations.
So, for PNM and TIFF at the least: Don't touch my pixel values unless you absolutely have to.
I actually would be enclined to have this as a policy even for PNG, which would mean that I would sometime have to -colorspace sRGB before storing.
Then, -set colorspace and -colorspace behave in a more predictable manner.
But I am not a typical user.

[NicolasRobidoux]

Ideally all formats would declare their colorspace and gamma, many do not. Without this information we must make assumptions about these attributes. For PNM, we assume sRGB. When you write PNM, ImageMagick converts the colorspace to sRGB. We could easily support writing linear RGB to PNM but then the user has no way of knowing its linear RGB and would assume sRGB. The user must then explicitly set the colorspace to linear RGB. If we always assume sRGB, we get consistent results without user intervention. What's your preference?

I just clicked on the probable origin of this: The current general convention is that a JPEG without a profile is sRGB, so it makes sense to produce sRGB JPEGs by default.
Although it is possible that this choice reflects current usage with PNM and TIFF, I am not aware of it, and I believe that extending this convention in an automated way to PNM is not a good idea.
I'll try to dig.
-----
Again, I may be missing something, but my strong inclination would be that pixel values be left alone as much as possible. Given that IM7 will allow arbitrary number of colour bands, will add colourspaces, and has a revamped -colorspace (with -set colourspace), I believe that it is a sane approach to have colourspace commands direct traffic directly without being silently overridden by format specific expert rulesets.

On the other hand, Cristy, Anthony and Glenn no doubt have thought about this way longer than I, so the above is a strong opinion, no more and no less.

[NicolasRobidoux]

Looking around, it is also my opinion that no automatic conversion to sRGB should be done when producing TIFF files, and that if there is no indication in the production of the TIFF that it belongs to a specific colorspace (sRGB, say) or associated with an ICC, it should simply be untagged.

[NicolasRobidoux]

I am fully aware that designing a sane multi-format/colorspace/ICC system is a non-trivial thing, and that my preference for a system reminiscent of VIPS' may not be the best choice for ImageMagick.

[fmw42]

I was searching around and found this, which indicates that Tiff supports an uncalibrated colorspace. http://www.awaresystems.be/imaging/tiff ... space.html

So I suppose one could use that for and output from -colorspace RGB as long as the user knew what he was doing and then afterwards use -set colorspace RGB -colorspace sRGB if needed to convert to sRGB.

I don't know enough about PBM formats, but the following seems to imply there is a colorpace field in PPM format:
http://reference.wolfram.com/mathematic ... t/PPM.html

But I will leave this to Magick for clarification/decisions.

[magick]

Ok, for PNM and TIFF we'll save the image in linear RGB if the original image is in the linear RGB colorspace. Are there any other image format we should consider?

[anthony]

The ONLY formats that should be sRGB complient, are web image file formats. JPEG, GIF, and PNG.
The PNG however does have good capability (by default without need for profiles) to differential between linear-RGB and sRGB, or even gamma-RGB.

I have no idea about TIFF! A format I regard as having been mucked around too much by every PC image program.

PNG Probably should just save as the data is in memory. It is a working format, (like MIFF), and while it can't save colorspace (except by using comments, whcih is not a good idea), it should be kept as is. Same goes for RAW data formats like 'RGB:' or 'R:'

[NicolasRobidoux]

I persist in thinking that ImageMagick should simplify itself and never do "silent" sRGB conversion at write. Even with GIF, PNG and JPEG.
I'm not 100% solid in this opinion, but it would make the most sense to me.
If you have anything else than sRGB, and you want sRGB, tag -colorspace sRGB at the end, or use a profile.
If you already have sRGB (whether you "declared" it or not, or it was set by the profile), it is a non-issue as far as pixel values go.

[NicolasRobidoux]

I know that my last suggestion is quite radical, but if you're going to support arbitrary numbers of channels and various colourspaces, it makes sense that you require explicit specification of what's being written, unless it's "obvious" or you can be "oblivious". (Again, I realize that this may be less than ideal for some users, but making the API transparent even if it requires being more specific would appear to me to be desirable for all but the most inexperienced users.)

[magick]

Added patches to Subversion to permit linear RGB for most image file formats. Download and test and let us know if it resolves the problem.

[fmw42]

Added patches to Subversion to permit linear RGB for most image file formats. Download and test and let us know if it resolves the problem.

Is this change only for IM 7 or also for IM 6. I am not requesting one way or the other. I just want to know what to expect.

[NicolasRobidoux]

Cristy: As usual, thank you very much.
Adam Turcotte and I will test with HDRI IM7 this week.

[NicolasRobidoux]

With latest svn of IM7 (version and my usual compilation flags that get rid of -g and the frame pointer, and allow for chip specific machine instructions:

Code: Select all

sudo make uninstall
make clean 
CFLAGS="-march=native -O2" CXXFLAGS="-march=native -O2" ./configure --enable-hdri 
make 
sudo make install

, the following

Code: Select all

magick rose: rose.ppm 
magick rose.ppm -colorspace RGB -filter Box -resize 35x23 -colorspace sRGB rose1.ppm 
magick rose.ppm -set colorspace sRGB -colorspace RGB roseRGB.ppm 
magick roseRGB.ppm -filter Box -resize 35x23 roseSMALL.ppm 
magick roseSMALL.ppm -set colorspace RGB -colorspace sRGB rose2.ppm 
magick rose: rose.tif 
magick rose.tif -colorspace RGB -filter Box -resize 35x23 -colorspace sRGB rose1.tif 
magick rose.tif -set colorspace sRGB -colorspace RGB roseRGB.tif 
magick roseRGB.tif -filter Box -resize 35x23 roseSMALL.tif 
magick roseSMALL.tif -set colorspace RGB -colorspace sRGB rose2.tif

produces rose2 images which have a maximum absolute difference of 3 from the rose1 images, which is, I believe, to be expected given that the resampling is done outside of HDRI internal representation with the "three step" approach. (In 8 bit, there is loss going between linear light and sRGB.)

Next, I'll try with a 16-bit sRGB image.