Get IM to stop changing colorspace for simple copy operations

[digitalis99]

I'm working more with IM and trying to get it to crop output files from render applications prior to appending them together. In this example, the render application is outputting an RGBA PNG with 8 bits per channel. Some tiles are all black, but others contain non-black color and alpha data in some portion of the image. I have to run a crop command similar to this:

Code: Select all

convert "allblack.png" -copy 192x108 +0+0 test_a_cropped.png

or this:

Code: Select all

convert "allblack.png" +repage -crop '192x108+0+0' test_a_cropped.png

When run against a file that has color and alpha data, the output is fine (RGBA with 8bits per channel). When run against a tile that is all black, the result is a greyscale PNG. IM is driving me crazy with this ridiculous automatic stuff that doesn't seem to be documented anywhere.

An example of a tile file that produces a greyscale output when either of the above commands are run against it:
http://www.kostov.com/IM/allblack.png

Those commands should, logically, output the upper left corner of that image as an RGBA PNG, but they don't. What "magick" incantation do I have to use to tell IM to stop messing with the colorspace when no colorspace options are defined?

[snibgo]

Your "+repage" does nothing. You should put it after the "-crop".

It messes with the "color type", which is merely a storage mechanism, not the "colorspace".

Write the output to "PNG00:x.png".

[digitalis99]

I don't want to have to specify the color type, then. I just want IM to carry it through from source to output.

[snibgo]

Yes. Use "PNG00:". See http://www.imagemagick.org/script/comma ... s.php#copy

Value = png00 causes the image to inherit its color-type and bit-depth from the input image, if the input was also a PNG.

[digitalis99]

Groan...this has to be done per-format? Seriously, why is this not the default?

[snibgo]

As a general rule, and certainly for PNG, IM sees that images saved as grayscale are smaller, sometimes far smaller. Most software will read grayscale PNG as identical to the equivalent RGB image. This saves disk space, network time and so on, so it seems reasonable behaviour. If you prefer to inherit the color-type, use "PNG00:".

What don't you like about the gray color-type? Does it cause problems?

[fmw42]

see http://www.imagemagick.org/script/comma ... php#define for colorspace:auto-grayscale=on|off, but also see the comments for that -define, since it is not universal.

[digitalis99]

...What don't you like about the gray color-type? Does it cause problems?

Yes. When stitching together many tiles into the same final image, with some tiles being all black, IM seems to key off of the first tile in the append operation to determine what the output image will be. If the first tile was converted to greyscale by the crop operation, then all of the stitched tiles are assumed (incorrectly) to be greyscale. The output is then also incorrectly greyscale.

I hold to the notion that this default (convert to greyscale) is NOT constructive. That's completely fine if you want to make this an option that is available if defined, but to make it a default is foolish.

see http://www.imagemagick.org/script/comma ... php#define for colorspace:auto-grayscale=on|off, but also see the comments for that -define, since it is not universal.

Thanks, but this is something else that pretty much drives me crazy about the way IM works (or doesn't). Why does the documentation state that PNG doesn't need this? Clearly it does, at least in my case. Why doesn't the documentation state that this defaults to "on" if not specified? I seem to keep running in to more and more junk like this that is 1) illogical and 2) not documented or contrary to documentation. The stuff that should be simple is a crapshoot, at best.

I do appreciate your help, guys, I just think it's a crying shame that it's so needed due to fundamental design flaws.

[snibgo]

Why does the documentation state that PNG doesn't need this? Clearly it does, at least in my case.

That documentation is unclear. It means that "colorspace:auto-grayscale" does not need to be defined because you can use "PNG24:" (or "PNG48:").

FWIW, I agree about IM's awkward handling of grayscale. I want command-line processing of images that happen to be entirely gray to be equivalent to processing of images that happen to have some colour. Sadly, this isn't the case.

[fmw42]

Use PNG24: or PNG32: