Legacy ImageMagick Discussions Archive

snibgo wrote: ↑2017-07-29T12:26:11-07:00 Am I missing something? Wasn't there an issue about IM not doing a round trip correctly? Not reading linear PNG files correctly? Has that been resolved, or is someone investigating?

It's still open as far as I am concerned. Incidentally, the one.hdr.png file from my demo does happen to be 16-bit (48-bit RGB).

Snigbo, thanks for your thoughtful analysis.

snibgo wrote: ↑2017-07-29T12:26:11-07:00 This would be IM saying, "I could do what you have asked for, save linear as PNG, but that's unwise so I'll do something else instead."

A user hasn't necessarily "asked for" linear output at all. In fact many people may be unaware that hdr is a linear format and so wouldn't be aware that the resulting png might be written as linear in this conversion: In my opinion the user shouldn't have to know the colorspace of their input file just in order to manually prevent IM from making a poor choice of output format. They should be able to read in anything, and when they write something IM should first of all try not to lose image quality (to the extent possible) and try to write a version of the target format that is compatible with most other software. Preserving the colorspace of the input (or of the previous operation within IM) for its own sake when going from float to 16-bit integer, or 16-bit integer to 8-bit integer, is simply introducing unnecessary loss for a hollow benefit that is "philosophical" at best.

And yes, I hope someone is investigating making IM read in a linear png (GAMA=1) as linear RGB colorspace rather than as sRGB. This should be uncontroversial, right?

Yes, if there is a bug, it should be addressed. Perhaps we should separate the discussion about linear vs non-linear from the bug. Dabrosny , would you post a new bug report simply describing the bug and a test image to show what is happening. This topic has drifted more towards the linear vs non-linear. That way the bug can be addressed separately from this discussion.

P.S. I would second snibgo's comments about no hard feelings one way or the other with respect to writing non-linear PNG so long as it is documented and does not upset the PNG guidelines such that non-Imagemagick users would be affected by any potential PNG changes.

Dabrosny wrote:And yes, I hope someone is investigating making IM read in a linear png (GAMA=1) as linear RGB colorspace rather than as sRGB. This should be uncontroversial, right?

Certainly. Thanks for doing the bug report.

Ideally, I'd like IM to be colorspace-neutral. It should work equally well in any colorspace: sRGB, linear, AdobeRGB, YUV or whatever. But it doesn't. In my own work, I often... ...then continue working with the three or four channels, knowing that IM won't sneakily and silently revert my image back to sRGB. I keep track of the real colorspace, and convert back or whatever I want later.

Anyhow, this experience makes me wary of software that assumes it knows best about colorspaces. If a linear image should be automatically made non-linear, why sRGB? Why not AdobeRGB, or another wide-gamut colorspace?

And this is before the complications of the dual systems: "-colorspace" or "-profile".

Dabrosny wrote:In my opinion the user shouldn't have to know the colorspace of their input file just in order to manually prevent IM from making a poor choice of output format.

Well, it's the user who says they want the file saved as PNG, which I agree is a poor choice for linear. I can see your point about the user needing to know the input colorspace. It's a frequent question on these forums: "How can I automatically convert any image that might be in any colorspace to sRGB?" The answer is more complex than simply "magick input.ext output.ext". It can be done in a script, or it could be done as a process module.

IM is a complex system. It's not easy to use. We have enough problems when IM makes decisions about bit-depth. If IM also makes decisions about colorspaces, it becomes harder to control.

In my view, the best place for such decisions is outside IM. Write a script that reads HDR files and writes them to PNG as you want them written.

Dabrosny wrote:... and try to write a version of the target format that is compatible with most other software.

I think that's a persuasive argument for sRGB (as opposed to AdobeRGB or whatever), as an output format for anyone creating a wrapper for IM to standardise on.

snibgo wrote: ↑2017-07-29T17:44:41-07:00 Ideally, I'd like IM to be colorspace-neutral. It should work equally well in any colorspace: sRGB, linear, AdobeRGB, YUV or whatever. But it doesn't. In my own work, I often...

Code: Select all

-colorspace {whatever} -set colorspace sRGB

...then continue working with the three or four channels, knowing that IM won't sneakily and silently revert my image back to sRGB. I keep track of the real colorspace, and convert back or whatever I want later.

Wow.

Would a new discussion be helpful about whether there may be ways to achieve more colorspace neutrality/transparency, or to increase predictability or consistency with respect to which colorspace is appropriate for, or silently converted to by, various actions?

Sure, but it's a massive topic. I'll mention a couple of aspects.

1. When I'm editing interactively, I chop and change the image between colorspaces as the need arises, but the main edit window shows a sRGB version of the image. So the knobs and sliders are labelled L,a,b or L,u,v or whatever, but I see the effect on the sRGB image. At the end of the session, the editor gives me the exact sequence of IM commands that do my actions.

It's not an easy way of working, but it has taught me about colorspaces.

2. Large portions of IM are colorspace neutral. It just does arithmetic on pixel values, without caring what the values represent. But I need to understand this. For example, the docs on sigmoidal contrast says:

Increase the contrast of the image using a sigmoidal transfer function without saturating highlights or shadows.

Well, that's true when the image is RGB. But applying sigmoidal-contrast to the a or b channel of LAB affects the colour saturation, not the contrast, of the image.

3. We can (and often do) design our own colorspaces, and use these during interactive or batch processing. For example (Windows BAT syntax) everything between %INFILE% and %OUTFILE% defines a new grayscale colorspace, based on two channels of YCbCr. After converting to YCbCr, I tell IM it is really in sRGB because I don't want IM to do any automatic conversions.

In the related bug report I've fixed coders/png.c so that pixels survive multiple round trips between HDR and PNG formats.

snibgo wrote: ↑2017-07-29T21:16:39-07:00 1. When I'm editing interactively,

I'm curious, what IM-based interactive editing software are you using?

snibgo wrote: ↑2017-07-29T21:16:39-07:00 I chop and change the image between colorspaces as the need arises, but the main edit window shows a sRGB version of the image. So the knobs and sliders are labelled L,a,b or L,u,v or whatever, but I see the effect on the sRGB image. At the end of the session, the editor gives me the exact sequence of IM commands that do my actions.

Maybe a helpful way of thinking about it is that there is a thing called an "image" which itself ultimately represents either "the (human-vision-)relevant aspects of the physical light entering a (hypothetical) camera from the represented (hypothetical) scene" (scene-referred) or "what it should look like to a human when viewed" (observer-referred), but in either case irrespective of how it is represented or stored at the moment.

Let's assume observer-referred for the moment for simplicity (even though HDRI images often can't really be considered observer-referred since they may exceed the dynamic range of human vision, or at least the dynamic range of any practical viewing device, until after some processing like tonemapping).

Ideally there should be no such thing as "viewing an sRGB image", but rather "viewing an image", because no matter what colorspace the image might be stored in (or other technical aspects of how it is stored), there should be a well-defined way of ultimately displaying it on any device so that it appears as intended -- that is the purpose of using a well-defined colorspace, so that there is a well-defined way of transforming it for the output device (via a well-understood wide-gamut standardized intermediate colorspace, typically XYZ in ICC profile color management but perhaps sometimes Lab for explicitly observer-referred images).

So I would say that what you are doing is seeing the effect on the image itself, not merely on the "sRGB image". Of course if you were to display a non-sRGB image as if it were an sRGB image then you would not be viewing the represented image correctly. So, really, any editing software should transform the image (stored in what ever colorspace) for viewing it correctly. When you change the colorspace or "working colorspace" of the image in an image editor, it should *not* appear different on the screen, aside from any technical limitations such as loss of image information from going through a colorspace that is not able to represent the full fidelity of the image (like a linear colorspace stored in 8-bit or even 16-bit integer format, or too narrow a gamut or dynamic range for the source image).

This is why when we save an image to a file, we should think of it as saving the underlying image, not as saving "the linear image" or saving "the image in sRGB colorspace". The colorspace in which it's actually stored in the file should only be subject to "technical" and pragmatic considerations like minimizing loss of fidelity, maintaining compatibility with other software that might read it, and keeping the file size in bytes low enough. So long as we have effectively stored the image, it should look the same when we decode and display it properly, and it can be transformed into other colorspaces for purposes like applying particular image processing algorithms.

And, when reading an image from a file, we should *by default* convert it into a consistent default colorspace for further operations, unless the user explicitly chooses one. This way, the colorspace in which the image happens to have been *stored* does not affect all the operations we may perform on it.

[+EDIT:] And perhaps the user could optionally define a working colorspace, to which the image is implicitly re-transformed after every operation. With floating-point this shouldn't produce much loss of fidelity.
(Although even better in terms of fidelity and processing time would be if there were some lazy evaluation for colorspace transformations, so that if the logical colorspace is transformed, but then immediately transformed back by the next operation for its own purposes before the image was actually read for processing, the two transformations would cancel and there would be no transformation calculation physically performed.)

Of course, this is not the way that IM works currently, and I think this is part of what makes the results unpredictable unless the user delves into the gory details of which colorspace the image is being stored, processed, and saved in at each step and each time we read, process, or save an image. (Or they give up and disable colorspaces completely and do their own colorspace management as you do, which probably isn't practical for most users.)

snibgo wrote: ↑2017-07-29T21:16:39-07:00 Increase the contrast of the image using a sigmoidal transfer function without saturating highlights or shadows.
Well, that's true when the image is RGB. But applying sigmoidal-contrast to the a or b channel of LAB affects the colour saturation, not the contrast, of the image.

Right, and this makes me think that we should, for each colorspace, label which channels increase with the intensity, i.e. those related (although not always linearly) to the amount of light from the scene. For example L in Lab, V or B in HSV or HSB, but all three channels in RGB or sRGB, are intensity-dependent, while a,b,S,V,B aren't.

An operation intended to change the contrast of the image intensity should, by default, act on these channels only, although the user should of course be able to choose explicitly which channel(s) it should act on.

snibgo wrote: ↑2017-07-29T21:16:39-07:00 I tell IM it is really in sRGB because I don't want IM to do any automatic conversions.

What about -set colorspace None instead of -set colorspace sRGB? Same idea but it seems less sneaky

[EDIT: I had a "-set" present that shouldn't have been.]
P.S. -- I suppose one could simulate a consistent "working colorspace" e.g. by inserting $c or %c% after every operation (including reading in a file), where c is a shell variable defined as '-colorspace sRGB' or '-colorspace RGB' or whatever colorspace you want.

My editor is called "Swim", it works on Windows, and I haven't published it.

snibgo wrote:... but the main edit window shows a sRGB version of the image.

As you correctly point out, what I meant was that my output device is sRGB, and the software creates a version of the image for the device. When I change the colorspace of the image, no change is visible to the image on the screen, of course.

(Which brings me to yesterday's point about editing with colorspaces: we are accustomed to having a defined transformation in both directions from a standard, but sometimes we don't; eg we might explicitly drop a lightness channel, so we can't do a round-trip. )

I approve of the concept of "saving the image", not needing to fuss about the colorspace or HDRI or whatever. The closest I get to that is the miff format, which of course is IM-only. Miff, not MPC, because MPC is also version dependent. Alas, when we save the image, we need to know the limitations of the file format.

Dabrosny wrote: And, when reading an image from a file, we should *by default* convert it into a consistent default colorspace for further operations, unless the user explicitly chooses one. [...] And perhaps the user could optionally define a working colorspace, to which the image is implicitly re-transformed after every operation.

That's one way of doing things. For Swim, I have kept things simple. There is no default or working colorspace. There is only the colorspace the image (as stored in memory) happens to be in at any particular moment in time.

I don't claim my method is ideal. It means that Swim has no controls for "lightness", "saturation" and so on, just controls for tweaking values in colour channels, via sliders or spline curves or whatever, and the impact of that tweaking will depend on the colorspace of the underlying image. That's one reason I haven't published it: it needs some expertise to use.

More intelligent editors have controls for "lightness", "hue", "redness" or whatever, and hide the gory technical details under the hood. But I'm a techie. I need to know what's under the hood, and I need to add gizmos.

Lazy evaluation, oh, yes please. Have you seen VIPS and nip2? I wrote an interface from nip2 to IM, and it shows the value of lazy evaluation to interactive editing. Push a slider, and the system does the minimum work required to show the result.

"-set colorspace None" had never occurred to me. Sadly, it seems to have no effect:

snibgo wrote: ↑2017-07-30T16:05:09-07:00 My editor is called "Swim", it works on Windows, and I haven't published it.

Sounds interesting -- maybe it's worth distributing even if it's with the understanding that it's "as-is" and "for techies".

snibgo wrote: ↑2017-07-30T16:05:09-07:00 Lazy evaluation, oh, yes please. Have you seen VIPS and nip2? I wrote an interface from nip2 to IM, and it shows the value of lazy evaluation to interactive editing. Push a slider, and the system does the minimum work required to show the result.

Is that interface available? Sounds useful.

snibgo wrote: ↑2017-07-30T16:05:09-07:00 "-set colorspace None" had never occurred to me. Sadly, it seems to have no effect:

Code: Select all

f:\web\im>%IM%convert rose: -colorspace Lab -set colorspace None info:
rose: PPM 70x46 70x46+0+0 8-bit CIELab 9.67KB 0.016u 0:00.015

There's an "Undefined" colorspace mentioned on www.imagemagick.org/script/command-line-options.php but it isn't listed in my IM 7.0.6-2 Q16 HDRI.
I noticed there's a "Transparent" colorspace but I have no idea what it's supposed to do.

The nip2-IM interface was included with nip2, as a (long) menu option. Perhaps it still is, though I see IM is now included in the VIPS binary.

snibgo wrote: ↑2017-07-30T16:05:09-07:00 "-set colorspace None" had never occurred to me. Sadly, it seems to have no effect:

Oh, look, "Undefined" seems to work (even though it isn't listed in -list colorspace):
But presumably that won't keep some operations from changing it back to sRGB.

snibgo wrote: ↑2017-07-30T17:02:27-07:00 The nip2-IM interface was included with nip2, as a (long) menu option. Perhaps it still is, though I see IM is now included in the VIPS binary.

BTW, I just noticed that there's also a VIPS-based wysiwyg non-destructive (operation-accumulating) image editor called PhotoFlow.