[Proposed docs for "-intensity" now in thread for approval.] When converting a grayscale image to color...

[Dabrosny]

I'm not sure whether this is by design (perhaps undocumented?) or a bug.
The documentation for "-intensity" says that it determines how a grayscale image is calculated from a color image, and in some other cases when a single intensity needs to be calculated internally from three channel intensities.

But it seems that the result of converting a grayscale image to a color image (using -colorspace ...) can be different depending on the "-intensity" setting that happens to be in effect at the time of this conversion.

Just for example, here's a grayscale test image:
== myrosesgray.jpg

Now I'm reading it in, converting it to RGB, and then making a nearly-unnoticeable change to the blue channel:

Code: Select all

magick -intensity rec709luma myrosesgray.jpg -colorspace RGB -channel B -evaluate multiply 0.99 {rec709luma}myrosesgray.jpg_RGB_Bx0.99.jpg

== {rec709luma}myrosesgray.jpg_RGB_Bx0.99.jpg .
The result above looks essentially unchanged, as expected. (The result is the same for both rec601luma and rec709luma.)

Now doing the same thing except while a different intensity setting is in effect:

Code: Select all

magick -intensity rec709luminance myrosesgray.jpg -colorspace RGB -channel B -evaluate multiply 0.99 {rec709luminance}myrosesgray.jpg_RGB_Bx0.99.jpg

== {rec709luminance}myrosesgray.jpg_RGB_Bx0.99.jpg .
This time the result is lighter. This unexpected change to the image is the same for for both -intensity rec601luminance as well as rec709luminance settings.. The same result also occurs if I move the "-intensity ......luminance" from before the input filename to just after the input filename.

The above can be repeated with essentially the same results if we replace "-colorspace RGB" by "-colorspace sRGB", or even "-colorspace cielab":

Code: Select all

Geom  CSpc A Dep Gam     Fmt  Siz   Min       Mx Avg     Name
70x46 Gray - 8   .454545 JPEG 1495B .137255   1  .429729 myrosesgray.jpg
70x46 sRGB - 8   .454545 JPEG 1669B .137255   1  .428359 {rec709luma}myrosesgray.jpg_RGB_Bx0.99.jpg
70x46 sRGB - 8   .454545 JPEG 1664B .137255   1  .427216 {rec709luma}myrosesgray.jpg_sRGB_Bx0.99.jpg
70x46 sRGB - 8   .454545 JPEG 1522B .403922   1  .668556 {rec709luminance}myrosesgray.jpg_RGB_Bx0.99.jpg
70x46 sRGB - 8   .454545 JPEG 1524B .403922   1  .668341 {rec709luminance}myrosesgray.jpg_sRGB_Bx0.99.jpg
70x46 sRGB - 8   .454545 JPEG 1522B .407843   1  .672689 {rec709luminance}myrosesgray.jpg_cielab_Bx0.99.jpg

Notice that the avg (nonlinear) value increases from 43% to 67%, corresponding to the incorrect (lighter) appearance.
This is approximately the ratio that would be expected from a transformation of the original grayscale image from gamma=.454545 to gamma=1.

One might describe the result this way: rec*luma and rec*luminance act as if they were two different colorspaces for grayscale images, quietly affecting whether the grayscale values are interpreted as linear vs nonlinear and thus the transformation that IM uses when transforming it to any other colorspace. Like a regular colorspace, the intensity setting is stored as a property of the image rather than merely a general session preference. With this intensity property, just as with a regular colorspace, intermediate colorspace transformations (like RGB or CIELab above) don't necessarily have an effect so long as in any case they all end up getting converted to sRGB in order to write the JPG file.

Is this a bug?

Or is this the expected behavior, and why?

[snibgo]

Your first and third images don't show for me. You don't say how you made the first, myrosesgray.jpg, so I can't reproduce your results.

You convert to linear RGB, but then store the image in format JPG which can't record RGB so the data is converted to sRGB.

[Dabrosny]

Your first and third images don't show for me. You don't say how you made the first, myrosesgray.jpg, so I can't reproduce your results.

Sorry, can you see those images now? (The phenomenon *should* occur with almost any true grayscale jpg as input, like any grayscale version of rose: saved by IM7, although perhaps not IM6 which I guess might write a color jpg.)
(Edit: the reason for the channel operation is to ensure that the color result cannot be automatically saved as a single-channel grayscale jpeg, which can affect the result.)

You convert to linear RGB, but then store the image in format JPG which can't record RGB so the data is converted to sRGB.

Correct, but that's true regardless of which intensity setting I use, so it doesn't explain the unexpected difference due to luma vs luminance intensity settings.

In any case, you should be able to replace "-colorspace RGB" by "-colorspace sRGB" throughout my examples and the phenomenon still occurs. In this case the conversion to sRGB is explicit for both intensity settings. I list the sRGB results in the table at the bottom but didn't include the images. There are just some very small numeric differences from not going through RGB as intermediate. I wouldn't have used linear RGB at all to begin with if I'd realized it would happen with sRGB as well, but it was getting late by the time I discovered this and I'd already spent too much time on it...

[snibgo]

I don't know why you have the "-intensity" setting in your command. What do you want it to do?

"-intensity" is a setting that affects the behaviour of many operators, including those that change colorspaces. A partial list is given at http://www.imagemagick.org/script/comma ... #intensity

The setting is stored in some filetypes (eg miff), so could affect a command on that file given many days later. I suggest that good practice is to use "+intensity" to turn it off after the operation we want it for.

[fmw42]

If all you want to do is change (color to) grayscale types from input to output, you can use -grayscale. See http://www.imagemagick.org/script/comma ... #grayscale

[Dabrosny]

I don't know why you have the "-intensity" setting in your command. What do you want it to do?

I just want to manipulate both linear and nonlinear grayscale images, so I need to know the basics of how IM decides whether a given grayscale image contains linear or nonlinear values!

I believe I've discovered the answer as follows, and my examples are part of the evidence for this:

The data in any Gray image (no matter how it was created inside or outside IM) is treated by IM as nonlinear if the intensity property IM finds in that image is Rec709Luma or Rec601Luma or Undefined.
It is treated as linear if the intensity property in the image is Rec709Luminance or Rec601Luminance.

(By "treated as nonlinear" I mean just like the channels of an sRGB image are treated as nonlinear. By "treated as linear" I mean just like the channels of an RGB image are treated as linear. The main effect of this distinction is that different operations are performed on the data when converting to another given colorspace, perhaps to export the image.)

If the statement in that quote box is true, it's a crucial piece of information that should be added to the documentation for the "-intensity" option.
It is completely separate from the documented effects of the -intensity option, which are all related to the way in which the channels of an existing color image are combined to create a Gray image (or to calculate a gray-like value inside algorithms).

If the grayscale image was originally created from a color image by -colorspace gray or by -grayscale, the resulting grayscale image would automatically have the correct intensity property so that IM would treat it correctly as linear or nonlinear grayscale during further processing. But that is not the only way to get a grayscale image, so we need to understand how we should set the intensity property for linear grayscale image data that might not already have this property.

If the statement in the quote box is not true, and my examples are just accidents or bugs, then I'd like to know that.
And I'd like to know the correct way to tag a grayscale image as linear for IM processing, because if there is no way, then basically IM doesn't support linear grayscale as such, and we would have to make sure to always use three-channel RGB for linear data.

When I convert the Gray image to sRGB, if it were nonlinear grayscale then IM would simply replicate the data values to three channels, but if it were linear grayscale then it would have to apply the nonlinearity as well as replicating the channels.
I see that IM 7 does indeed do the right thing in both cases, so long as the image's intensity setting correctly labels it as linear (rec___luminance) or nonlinear (almost anything else).

I suggest that good practice is to use "+intensity" to turn it off after the operation we want it for.

The "+intensity" undefines the intensity property, which in effect makes IM assume Rec709Luma by default.
Applying this after converting a color image to linear grayscale (i.e. using rec___luminance) would be a mistake because it would remove the rec___luminance intensity property from the grayscale image and then IM would treat the image's data as nonlinear when in fact it is still linear, so the results would generally become incorrect.

[snibgo]

Is the "-intensity" setting a good way of flagging that data is linear? No, I don't think so. For one thing, when changing colorspaces, the "-intensity" setting is only used when the colorspace was Gray, Rec601Luma or Rec709Luma. Even then, only two intensity settings are important: Rec601Luminance and Rec709Luminance. And "-intensity" has many other possible values that are not related to linearity.

I think the best way of flagging that data is linear is to declare it as "-set colorspace RGB".

Sadly, not all file formats have colorspace metadata. They do often have "gamma" metadata, which is often used as flag meaning "linear RGB or non-linear sRGB".

As you probably know, the RGB<->sRGB conversion isn't simply a gamma adjustment. By contrast, the linearRGB<->AdobeRGB conversion is a simple gamma adjustment.

In my view, the major issue is the way the file formats don't handle colorspaces well. There isn't a clean well-defined flag that defines colorspace, or says what process should be used to make the data linear, or that it is already linear.

And I'd like to know the correct way to tag a grayscale image as linear for IM processing ...

I've never understood IM's obsession with "grayscale" as a colorspace. As far as I'm concerned, "gray" is simply a special case of RGB, sRGB, AdobeRGB or whatever colorspace. (True, for some specialist purposes like TV transmission, "gray" might be something different. But for general image processing, I want to treat gray images just like colour images.)
For v7, I use v7.0.3-5, which has a multitude of colorspaces for colour but only "Gray" for grayscale images. Probably because file metadata often has a flag for "gray", assumed to act like sRGB.

Code: Select all

magick rose: -colorspace RGB -modulate 100,0,100 -verbose info:

This has only one channel, and says:

Code: Select all

  Colorspace: RGB
  Gamma: 1

... which is what I would hope. But all bets are off when saving the image to a file, and reading it back, hoping to find the same thing.

[Dabrosny]

Is the "-intensity" setting a good way of flagging that data is linear? No, I don't think so. For one thing, when changing colorspaces, the "-intensity" setting is only used when the colorspace was Gray, Rec601Luma or Rec709Luma.

I agree that -intensity isn't a good way (in fact, having a linear and a nonlinear grayscale colorspace is the way other software does it and this would make everything "just work" like it used to when there were several such colorspaces in IM), but the fact is that IM does currently use "-intensity" in this way when using one of those four "-intensity" settings.

In fact, IM sets rec709luminance (for example) as the intensity property on the resulting grayscale image (just as much so when -grayscale rec709luminance is used, btw, seemingly contrary to the documentation) and then IM also reads this setting back and respects it when converting this grayscale image back to a color image. This is unlikely by accident -- it is designed so that, for example, it makes everything work correctly in round-trips back and forth between linear grayscale images and linear RGB without changing the data more and more every time!

But there are other cases where this usage of the intensity is not implemented, and I can't submit a bug report on these unless it is recognized that the intensity is or should be used in this manner, rather than just de facto.

Even then, only two intensity settings are important: Rec601Luminance and Rec709Luminance. And "-intensity" has many other possible values that are not related to linearity.

I haven't tested other values of -intensity but the four luma/luminance ones are the most basic (frankly, primarily rec709luminance since the luma ones are already the default, and rec601luminance doesn't actually make photometric sense as it is inconsistent with the very definition of RGB and sRGB in terms of Linear Luminance Y in XYZ colorspace, which specifically use the "rec709" coefficients, which, btw, for linear RGB, pre-date Recommendation 709 by decades).

I'm okay with saying "all bets are off" for now on the others intensities. (Although in fact it seems clear from the formulas in the documentation that Lightness and Brightness always use the nonlinear (sRGB) values (the primed R', G', B') so these should probably be marked as nonlinear as well; and Average apparently doesn't change anything between linear and nonlinear, so it should probably preserve the current linearity/nonlinearity. For MS and RMS I would say all bets are truly off.)

I think the best way of flagging that data is linear is to declare it as "-set colorspace RGB".

Okay, if that's the best we can do, then would you be willing to propose that the IM documentation state something along the lines of

The RGB colorspace can also be used for single-channel images (instead of using the Gray colorspace), to indicate the linearity of the data values and ensure that operations such as transformations to color images will correctly take this linearity into account.

If it were proposed by me I'm almost certain that this idea wouldn't go anywhere

Using RGB colorspace could be either instead of, or in addition to, the current ways of indicating linear gray (which is mainly rec*luminance intensity setting on gray image, but sometimes/inconsistently instead the gamma setting when it comes to reading & writing certain specific file formats & some other operations).

Currently, everything "just works" with linear RGB color images, but then the situation becomes unclear (and inconsistently implemented) when we try to use linear grayscale. There has to be some recognized way of doing this rather than just an undocumented workaround that everyone has to find out for themselves.

Sometimes I don't use ImageMagick for awhile and then when I come back I always have to figure out all over again how to work around the issues in order to make linear grayscale work without mangling the image data!

Sadly, not all file formats have colorspace metadata. They do often have "gamma" metadata, which is often used as flag meaning "linear RGB or non-linear sRGB".

Understand, and gamma is the best we can do in those file formats. But when gamma=1 or gamma~0.4545 the best we can do is convert to and from what ever flag (or multiple flags) IM uses internally to identify linear vs nonlinear(sRGB-like) images. Some formats have exactly one colorspace (jpeg, hdr, etc.) so there's no ambiguity. And for formats that have no specified colorspace or gamma whatsoever, we always assume sRGB, which is fine as a default.

In my view, the major issue is the way the file formats don't handle colorspaces well. There isn't a clean well-defined flag that defines colorspace, or says what process should be used to make the data linear, or that it is already linear.

I understand. But once we decide that the input image is to be treated as sRGB, then there is only one correct way to linearize it (to either RGB or XYZ), which is given in the sRGB specification. If we decide that it's linear RGB or another supported colorspace, then there's one correct way to transform it to any other given colorspace, and IM already does this mostly correctly for multichannel color images.

As you probably know, the RGB<->sRGB conversion isn't simply a gamma adjustment. By contrast, the linearRGB<->AdobeRGB conversion is a simple gamma adjustment.

I understand, but if IM would just work consistently with sRGB (not necessarily pure gamma=1/2.2 since this is very rare) and linear, including grayscale sRGB (as found in all grayscale jpeg files and most grayscale png files) and linear "grayscale RGB", that would be a great start -- just the basics!
I wouldn't want to try to get too ambitious about other colorspaces before then

And I'd like to know the correct way to tag a grayscale image as linear for IM processing ...

I've never understood IM's obsession with "grayscale" as a colorspace. As far as I'm concerned, "gray" is simply a special case of RGB, sRGB, AdobeRGB or whatever colorspace. (True, for some specialist purposes like TV transmission, "gray" might be something different. But for general image processing, I want to treat gray images just like colour images.)

Exactly! Any homogeneous red-blue-green colorspace (where all three channels behave similarly) can have a single-channel version of itself, which is equivalent to when the color version "just happens" to have all three channels equal! (There are some heterogeneous colorspaces like Lab that don't behave this way, but I'm happy to ignore them for now and stick to the basics.)

For v7, I use v7.0.3-5, which has a multitude of colorspaces for colour but only "Gray" for grayscale images. Probably because file metadata often has a flag for "gray", assumed to act like sRGB.

Code: Select all

magick rose: -colorspace RGB -modulate 100,0,100 -verbose info:

This has only one channel, and says:

Code: Select all

  Colorspace: RGB
  Gamma: 1

... which is what I would hope. But all bets are off when saving the image to a file, and reading it back, hoping to find the same thing.

I think it would be a reasonable goal for the bets to be back "on" some day for it to behave predictably and consistently even when saving and reading images (to the extent possible for the format).

[fmw42]

But you can use -grayscale to convert to linear or non-linear grayscale using rec709luminance or rec709luma as well as rmse and average. So there are many different forms of grayscale. Not just one from -colorspace RGB.

[snibgo]

Although in fact it seems clear from the formulas in the documentation that Lightness and Brightness always use the nonlinear (sRGB) values ...

The documentation is misleading (or simply wrong).

Consider the "-grayscale XX" command, where XX is one of the intensity settings. If XX is one of the four lum* settings, IM may effectively do a conversion from sRGB to RGB (or RGB to sRGB), and then calculate the weighted average of the 3 channels. But if the setting is Brightness, RMS, etc then IM does no sRGB<->RGB conversion. It only does the weighted average calculation.

To see this, make a sRGB or RGB grayscale image, "-grayscale XX", and find the mean.

Code: Select all

f:\web\im>%IM%convert rose: -colorspace sRGB -grayscale rec709luma -format "%[fx:mean]\n" info:
0.394629

f:\web\im>%IM%convert rose: -colorspace RGB -grayscale rec709luma -format "%[fx:mean]\n" info:
0.394629

We get the same numbers, because "-grayscale" has first converted both inputs to the same colorspace.

Code: Select all

f:\web\im>%IM%convert rose: -colorspace sRGB -grayscale Brightness -format "%[fx:mean]\n" info:
0.596205

f:\web\im>%IM%convert rose: -colorspace RGB -grayscale Brightness -format "%[fx:mean]\n" info:
0.403119

We get different numbers, because "-grayscale" has ignored the input colorspace, and simply done the arithmetic.

[Dabrosny]

But you can use -grayscale to convert to linear or non-linear grayscale using rec709luminance or rec709luma as well as rmse and average. So there are many different forms of grayscale. Not just one from -colorspace RGB.

Just because a different formula (different coefficients) might have been used to *create* a grayscale image from a color one does not mean that it is in a different colorspace. The colorspace just means how the numeric values in the grayscale image are to be interpreted and ultimately displayed. They may be *linear* in which case for example if they are replicated into three identical channels they would be linear RGB. They can be *nonlinear* in the sense that if they are replicated into three identical channels they would be sRGB -- this type of grayscale is *exactly* what is stored in every true Grayscale Jpeg file (single-channel jpeg) and you can obtain an ICC color profile for this colorspace called sGray.icc. This is true regardless of whether the grayscale image was calculated using rec601 vs rec709 vs Average or any other coefficients. (Of course there can be other grayscale colorspaces that are unrelated to sRGB or to RGB, like the "L" in Lab, but these are more "advanced" and nobody is expecting IM to support them directly in the near future.)

And not all grayscale images are necessarily derived from a color image. If you scan an old "black & white" photo, what "form of grayscale" would the resulting image be? For example, "rec709", "rec601", or "Average"? Of course it is a nonsensical question. The raw output of the scanner is in a colorspace described by an ICC hardware profile, and the scanner or your software would transform it to single-channel sRGB (like we find in grayscale jpeg) or perhaps single-channel linear, or perhaps a more obscure colorspace which would still need to be described by an ICC profile rather than being directly supported by its name in IM. The question "is it rec709 or rec601" would never arise. But the question "is it nonlinear like sRGB or is it linear" is crucial -- the numeric values in the image are meaningless unless you can answer this.

IM needs to have at least two colorspaces for single-channel images: one for nonlinear (in the sRGB-like sense) and one for linear grayscale images, whether we simply use "sRGB" and "RGB" as Snibgo suggests, or whether they have separate names like "sGray" and "LinearGray".

At the moment there is only one colorspace "Gray", and the Intensity setting stored in the grayscale image identifies whether it is nonlinear (rec*luma) or linear (rec*luminance). If your grayscale image was created by IM from a color image by -colorspace gray or -grayscale, these opertors themselves will set the intensity property of the image so that it will be identified correctly as linear or nonlinear later, for example when it needs to be converted to a three-channel sRGB or RGB image in order to combine it with another image or perform color-channel operations on it.

But if we are going to continue to use this "intensity" scheme (instead of at least two real colorspaces) to identify linear and nonlinear grayscale, this needs to be documented so that we can manually set an appropriate Intensity setting on a grayscale image that was *not* created by IM from a color image.

[Dabrosny]

Although in fact it seems clear from the formulas in the documentation that Lightness and Brightness always use the nonlinear (sRGB) values ...

The documentation is misleading (or simply wrong).

Okay, the documentation should be updated to move Lightness and Brightness into the "mathematical" group along with Average etc.
So Lightness, Brightness, and Average all maintain the linearity or nonlinearity of the color source image they operate on.
If they operate on an sRGB image then they should set Rec709Luma (or 601 -- it doesn't matter), and if they operate on an RGB image they should set Rec709Luminance (or 601).

But I'd much rather ignore those "mathematical" intensity settings for the moment in the hopes that we could just have a recognized or documented way to identify linear vs nonlinear grayscale images, whether it is currently implemented consistently or not.
This would be a bare minimum before there's any possibility that IM could work consistently with linear and nonlinear grayscale like it does with color RGB and sRGB today.

Fred or Snibgo, would you be willing to propose that the current de facto usage by IM of the intensity setting (*luma vs *luminance) on Gray images to flag their linearity/nonlinearity be documented as such? Who can change the documentation?

Or to propose that there should eventually be two grayscale colorspaces like sGray and LinearGray, as in other colorspace-aware image software?

Or, Snibgo, would you like to propose using RGB and sRGB colorspaces, or documenting this as one possible way, to identify the linearity of grayscale images, and use a different method to identify whether they have one vs three channels? (In fact I've noticed that there is nothing in identify -verbose that reliably tells you how many channels there are, other than to manually count how many sets of statistics it calculates. The colorspace like sRGB or RGB is not reliable because, as you pointed out, IM can have a single-channel image that is labeled as sRGB or RGB.)

Or perhaps to propose that we should instead consistently use the gamma property of grayscale images (1 vs .4545) to identify linear vs sRGB?

The critical thing is that there be some documented way to write and read some property of a single-channel image that can identify whether it is linear or nonlinear within IM. The numeric data values mean nothing until this is flagged.

In my opinion the cleanest way is by using two colorspaces (either sRGB and RGB, or sGray and LinearGray or similar), but in the meantime at an absolute minimum the current de facto method should be documented, so every user doesn't have to try to figure this out on their own.

[fmw42]

There is only one colorspace in IM for gray. But you can achieve many different forms of grayscale. I thought that was the real issue. To get linear gray and keep it linear when doing -separate and -combine. I showed that worked for me.

[Dabrosny]

There is only one colorspace in IM for gray. But you can achieve many different forms of grayscale. I thought that was the real issue. To get linear gray and keep it linear when doing -separate and -combine. I showed that worked for me.

The issue is to document the criteria by which a Gray image (created or imported by any means at all!) is (or could be) flagged and treated within IM as nonlinear vs linear, for example as it affects a further -colorspace sRGB or -colorspace RGB or other colorspace transformations. This is critical in order to not get a much darker or much lighter result than the original. Until these criteria are stated clearly, it is difficult to establish potential "bugs" related to this, because it is not always clear whether a (single-channel) image having certain properties (intensity, gamma, colorspace, or others that show up in identify -verbose) *should* be treated as linear or nonlinear, so it isn't clear whether the results of various operations on it are "correct" or not.

Right now, the thing that determines whether IM treats a Gray image as linear or nonlinear when converting to a color colorspace is the intensity setting on the image (*luma vs *luminance only, since 601 vs 709 no longer has any affect on how the grayscale image itself is treated once it already exists) as shows up in identify -verbose (regardless of whether the image was created by -grayscale or -colorspace gray or neither), so let's at least document that. Unless that behavior itself is a bug, but I don't think so as this is what in fact lets -grayscale or -colorspace gray flag the image as nonlinear or linear for further operations (like -colorspace sRGB) so that they come out correctly!

[snibgo]

Storing the same data, or metadata, in multiple places isn't a good idea. What happens when the multiple values disagree with each other?

Pixel values may represent linear data, or not. This information is currently represented by metadata (a) colorspace, (b) gamma and (c) profile. Fairly recently we now have (d) intensity. Yikes. Four places!

Dabrosny asks: How should I flag a grayscale image as linear? It's a fair question.

I would add the converse question: When IM has an image in memory, what metadata tells me whether it is linear?

I'll add an important condition: the answer to the questions should not depend on whether the image happens to be grayscale. The image might have come from anywhere, or it might have been created as part of an IM command or program. Colourfullness is independent of linearity. Whether an image has one channel or three, and whether the three RGB channels happen to contain the same values or not, the data can be linear or non-linear.

If the answers do depend on whether the image happens to be grayscale, that raises difficulties about when the metadata is updated. Does this happen automatically, internally within IM? Whenever a pixel is updated in memory, does IM have to check whether the gray/colour status has changed so it can update the linear flag? That would be absurd. Or do we have to add this to all our scripts, to check whether each created file happens to be grayscale so we can set the metadata correctly? Also absurd.

So I conclude that a four-valued colorspace ("linear-colour", "non-linear-colour", "linear-gray", "non-linear-gray") is a bad idea, and would be a bad answer to either question. (If other colorspace-aware image software uses this scheme, I'd like to know how it is managed. What software sets the value of the colorspace?)

I don't claim IM's current scheme is good. It isn't. But I don't want to make a bad situation worse.

I should deal with profiles. When a workflow manages colours (or tones) with profiles, that's the answer to both questions. Set linearity or non-linearity with the appropriate profile. To enquire whether an image is linear, examine the profile.

Okay. How about when profiles are not used?

"How should I flag a grayscale image as linear?" Answer: the same way as for a colour image, use "-set colorspace RGB". I advise not to use "-intensity" except for specific operations, and unset it afterwards.

"When IM has an image in memory, what metadata tells me whether it is linear?" Check the colorspace. If it is RGB or sRGB, that answers the question. If it is "gray", then examine the gamma. If it is or isn't 1.0, that answers the question.

As far as I know, these methods work. If they don't, that's a bug.