Legacy ImageMagick Discussions Archive

IM 6.5.8-7 Q16 Mac OSX Tiger (Version: ImageMagick 6.5.8-7 2009-12-18 Q16 http://www.imagemagick.org)

One of my scripts is failing and I believe I have tracked it to -colorspace not working with PNG or GIF or TIF. Here is a simple example:

convert rose: rose.png


convert rose.png -colorspace hsl rose_hsl.png


convert rose.png -colorspace hsl rose_hsl.gif


convert rose.png -colorspace hsl rose_hsl.tif


convert rose.png -colorspace hsl rose_hsl.jpg


No change between either rose_hsl.png or rose_hsl.gif or rose_hsl.tif and the original rose.png!!! I don't think this is correct as rose_hsl.jpg seems to work correctly. Am I missing something? Can you verify please. Thanks.

Fred

We can reproduce the problem you posted and have a patch in ImageMagick 6.5.8-8 Beta available sometime tomorrow. Thanks.

magick wrote:We can reproduce the problem you posted and have a patch in ImageMagick 6.5.8-8 Beta available sometime tomorrow. Thanks.

Testing ImageMagick 6.5.8-8:
I think you misunderstood the problem. The correct solution for -colorspace HSL was the jpg. You have now made the jpg behave like the PNG, TIF and GIF and none of them are correct. When converting from RGB rose to HSL, the new channels should NOT look like the original when displayed, but should look the jpg result above.

The following still works correctly using MIFF:

convert rose.png -colorspace hsl rose_hsl.miff
display rose_hsl.miff

All other image types (PNG, TIF, GIF, JPG, etc) need to look the same as rose_hsl.miff and should not look like the original rose.png image.

Thanks.

Fred

The image format specification for JPEG, TIFF, GIF, and PNG do not support a colorspace of HSL. If the image is in the HSL colorspace, it is automatically converted to RGB to write an image that conforms to the specification. Possible paths forward would be to show us where in the image specification it permits support for the HSL colorspace, use a format that supports HSL (e.g. MIFF), or we can add an expert option that when set stops the color conversion from HSL to RGB. What is your preference?

magick wrote:The image format specification for JPEG, TIFF, GIF, and PNG do not support a colorspace of HSL. If the image is in the HSL colorspace, it is automatically converted to RGB to write an image that conforms to the specification. Possible paths forward would be to show us where in the image specification it permits support for the HSL colorspace, use a format that supports HSL (e.g. MIFF), or we can add an expert option that when set stops the color conversion from HSL to RGB. What is your preference?

Sorry, I am not being clear.

convert rose: -colorspace HSL rose_hsl.png (or any other output image format)

should change the way the channels display. They should look different from the original rose: image. It is not a case of storing the HSL channels info in the header. It is just that the RGB image that is displayed when the channels are converted to HSL and displayed as if RGB should be different from the original RGB image channels. They go through a change of grayscale values according to the RGB->HSL conversion. When those channels are are composed as a 3 channel image and displayed as is if they were RGB, then the colors should be totally different from the original image.

The correct way that the channels should display for any image format (PNG,GIF,TIF,JPG) should look just like you get when you do

convert rose: -colorspace HSL rose_hsl.miff
display rose_hsl.miff

That image displays the HSL channels (as if RGB) looking like they have been changed correctly. Something is not working for -colorspace HSL (and HSB) when one uses these other image types for the output and then displays them. (The miff displayed result looks correct, though). All the other image types used to display the result just like the miff result.

This displays correctly (it looks the same as the miff result):

convert rose: -colorspace hsl -separate -combine rose_hsl_sep_comb.png


Shouldn't the following (which is not correct as there is no change in the output image from the input) look the same as the above (which I think is correct)?

convert rose: -colorspace hsl rose_hsl.png

I assume you would expect to display the original rose image with this command:

• convert rose: -colorspace hsl -colorspace rgb x:

That is essentially what you are doing with this command:

• convert rose: -colorspace hsl rose.png

There is an implicit -colorspace rgb option since PNG does not support the HSL colorspace so we would expect

• display rose.png

to display the standard RGB colorspace whereas with

• convert rose: -colorspace hsl rose.miff
  display rose.miff

We would expect a funky color rose since it remains in the HSL colorspace.

I may be mistaken, but PNG used to display just as MIFF (and JPG before you changed it) did! The reason that I say that, is that my script used to work with a png for a temp file. I had to change it recently to use miff for the temp to make it work.

I have never seen this recent behavior for either PNG, TIF or JPG where you know to convert implicitly back to RGB for HSL or HSB. They used to just display as if I had used -colorspace hsl -separate -combine. This seems to be an undocumented new feature.

I don't see why -colorspace hsl -separate -combine works if what you say is that HSL is not supported in PNG and is converted back via -colorspace RGB. What is different about using

convert rgbimage.png -colorspace hsl -separate -combine hslimage.png

compared to

convert rgbimage.png -colorspace hsl hslimage.png


These both used to produce the same result as the -separate -combine result.

I have to assume that you have changed the behavior of -colorspace in some recent release from what it was and this is how you want it to work. But I don't think this behavior is desired. I don't think that

convert rgbimage.png -colorspace hsl result.png

should include an implicit -colorspace rgb in it if not miff, that is like

convert rgbimage.png -colorspace hsl -colorspace rgb result.png

when using PNG, TIF, JPG, GIF for the output. That is I don't like the implicit -colorspace rgb.

In other words, if one converts to hsl, then the channels produced in the resulting image should be hsl data no matter what image type is used for the output.


Any way that is my opinion. But if this is what is desired, I can live with it. I will just have to use -separate -combine to get what I want or use MIFF. But please document this behavior of -colorspace with regard to output image type.

I will have to review my scripts to see which ones have now changed in this regard.

It would be nice to hear from other users on this issue!

Fred

when using PNG, TIF, JPG, GIF for the output. That is I don't like the implicit -colorspace rgb.

By default, we must conform to the image specification and none of these formats support the HSL colorspace. We suspect the best path forward is an expert option to override the default behavior. Something like

• convert rose: -colorspace hsl -define colorspace:override=true rose.png

We'll get a patch in ImageMagick for the next point release.

By default, we must conform to the image specification and none of these formats support the HSL colorspace.

I don't really understand what these image specifications have to do with it other than noting in the header that it is in that colorspace. If one desires the image data in some colorspace (HSL, HSB, YUV, OHTA, CMYK etc), then -colorspace should convert the image channels to those colorspaces, even if the colorspace is not included in the header and the image displays with odd looking colors (as if RGB channels even though they are not). The output image data should change no matter what when one specifies -colorpace.

Perhaps the display process should take care of the implicit conversion back to RGB if and only if the header knows the colorspace is is other than RGB. But other display devices other than IM might not know about this or honor it, such as the browsers.

The real issue is what data is in the output image. That should honor the colorspace. It is the display process that should convert back to RGB if it know that it is HSL data. In otherwords, -colorspace should produce an image always with those channels.

Can you clarify where the image specifications tell you that you should ignore the colorspace and convert the image data back to rgb. I really don't understand why they would do that. Essentially it becomes a null operation.

When did this change as it used to not be this way and used to convert the output data to whatever colorspace was requested no matter what the output image type was.

Nevertheless, if this override is what you think best, then go ahead although I don't think it is necessary as it won't be any different from using -colorspace HSL -separate -combine. I don't know if you can get in touch with Anthony or not about this. I would love to hear his point of view or understanding. However, it needs to be consistent for all colorspaces as some others don't work the way they used to either. It is not just an issue with HSL and HSB only.

Sorry for the long discussions, but I am just puzzled by this and trying to get a handle on understanding this all. Perhaps I am missing some key point here or misunderstanding what is happening. Please clarify if you can, if this is the case.

Thanks.

Fred

Here is what Glenn says about PNG, for example:

PNG only permits RGB and grayscale. sRGB is a particular RGB colorspace, which is allowed, as are other RGB colorspaces with different gammas. PNG does not provide for non-rgb colorspaces such as HSL or CMYK.

However, nothing prevents you from designing a critical private chunk that identifies the file as containing something different in the channels, as long as the channels adhere to the PNG depth and color_type requirements.

This is highly frowned upon, though. Apple has done it with their CgBI chunk (which they happened to misplace ahead of IHDR), and it only led to confusion.

Given the above, do you want a private chunk to support the HSL colorspace in PNG images?

No, lets not change anything just yet without a clear understanding of what should happen.

Let me see if I get this straight. Just because an image type does not support some colorspace, IM will NOT convert the pixel data to that colorspace. So one gets a null operation. The output remains the same as the input. Is that correct? Or am I misunderstanding something?


This does not seem reasonable behavior to me. Seems to me that whether an image supports a colorspace (in the header or specification) or not, the data should be converted to that colorspace and the channels just treated blindly for display as if they were rgb even though they are in some other colorspace (whether the user or IM can tell that from the header or not). The data is just 3 channels of pixels. So when it is displayed, it is always treated as rgb even though not. (However, if the format supports that colorspace, then the display could then convert it back to rgb so that when displayed it looked the same as the input. But if there were no information about the colorspace in the header, then it would display with odd looking colors, because those channels are in some other colorspace, but the display does not know that and so just treats it as normal rgb channels) . This is what it used to do and I do not know when this behavior was changed. Seems to me -colorspace always used to change the pixel data to that colorspace no matter what the image type was, since my script used to work when the temp file was PNG format. Am I mistaken about this?

To my point of view, -colorspace, should always convert the pixel data in the image to that colorspace. The display system is what needs to recognize whether it knows from the header what the colorspace is and then convert that colorspace back to rgb; otherwise just display it as if it were rgb even though not.

However, since I can always just do -colorspace ... -separate -combine to get that behavior, I guess it is not worth any effort to change things other than some clear documentation of what is going on, unless others are dismayed about this new behavior, too.

My understanding of -colorspace, and the internal 'colorspace' image meta-data tag, is that it defines and converts the images in-memory data to correspond to that color space scheme. The color each pixel represents has not changed, just the data representation. As such to me all the original forms, PNG, GIF, etc was correct. Those file formats can not store the color as HSL, so it converts the HSL data representation of the color back to RGB form (with some posible slight quantum rounding effects).

-colorspace does NOT change the color, only the data representation of the color in memory.

If you want to change the what the in-memory data representation is then you can change the color space without coventing the data (so the actual color remains uneffected), by using -set colorspace.

Of course some formats can save colors in a HSL color format, For example MIFF and TXT.
Though for JPG it also requires a color profile for it to work correctly.


NOW it seems you want to output a PNG file where the data in the file is HSL, even though that file format does not support HSL!
You have two solutions. COnvert the image to HSL: colorspace in memory, then tell it is really RGB (for saving purposes).
convert rose: -colorspace HSL -set colorspace RGB save.png

This to me however is a bit of a hack, but then PNG has no flags to tell IM its stores dat is HSL and not RGB.

The other suggestion that Cristy made, as to sepcify an expert option to either set a 'output colorspace'. OR 'use the colorspace meta-data setting'. Again this is a hack as PNG format does not aloos non-RGB color representations.

Basically I think you should back track and define WHAT YOU WANT.



ASIDE: -set colorspace was created to allow you to specify the colorspace color data representation that you are generating with -combine. See IM Examples, Channels, Combining to non-RGB channel images
http://www.imagemagick.org/Usage/channe ... bine_other

What I really want is to convert the image from one colorspace representation of the data to the other, whether the header knows about it or not.

But there are ways to do that, so this is really not an issue.

First, if I just want to use it in a script as a temp file, then miff will do the trick.

Second, if I want to output the data in that format, I can do that with

convert image -colorspace -separate -combine result

So, although this behavior has changed somewhere along the line so that some of my scripts do not work the way they used to, I can modify them to work correctly without any new coding.

My only request is that the documentation be clear on what -colorspace can and cannot do. I will try to help on this.