incorrect conversion from XPM

[arand]

Hi,

In version 6.7.7.10 (and 6.7.9.3) of imagemagick I've discovered what I assume is a regression:

When converting these xpm files to another format (e.g. png, or -depth 8 gray in my case) they change noticably, something which did not happen in version 6.6.9.7

http://ubuntuone.com/2a4A9na9dPd5coRIYjrw8C
http://ubuntuone.com/4krAuot6YOdpxlHRls6Fok
http://ubuntuone.com/0Sf4YxGWrXixj5YVEjIvlm
(Images copyright 1998 Joosa Riekkinen, WTFPL-licensed)

Is there some kind of bug in the reading of, or conversion from, XPM files?

[anthony]

XPM file codecs are tricky. Colorname can have spaces in them, and also they MUST refer to a X11 colorname and not a SVG color of the same name but different value. This is on both reading and writing.

See Colorname Conflicts...
http://www.imagemagick.org/Usage/color_ ... _conflicts

Can you confirm that this may be the problem?

[arand]

I'm not sure that this is the issue, ot seems more like a general loss of brightness, or truncation of all colours into some lower depth in the process of reading of the XPM file, throughout the whole image.

For example

Code: Select all

convert gfx1.xpm -depth 8 gray:- >> result.bin

results in these raw values:

Code: Select all

(...)
0000330: 0000 0000 0000 0002 0202 0200 0000 0000  ................
0000340: 0000 0000 0000 0202 0302 0202 0000 0000  ................
0000350: 0000 0000 0002 0303 0303 0202 0000 0000  ................
0000360: 0000 0000 0003 0303 0302 0202 0000 0000  ................
0000370: 0000 0000 0303 0303 0302 0202 0000 0000  ................
0000380: 0000 0000 0303 0303 0202 0200 0000 0000  ................
0000390: 0000 0000 0303 0303 0202 0000 0000 0000  ................
00003a0: 0000 0000 0203 0302 0000 0000 0000 0000  ................
(...)

whereas before, Imagemagick would produce (what I'm expecting):

Code: Select all

(...)
0000330: 0000 0000 0000 0016 1817 1400 0000 0000  ................
0000340: 0000 0000 0000 1819 1a18 1614 0000 0000  ................
0000350: 0000 0000 0018 1b1c 1b1a 1715 0000 0000  ................
0000360: 0000 0000 001a 1c1d 1c19 1614 0000 0000  ................
0000370: 0000 0000 1a1c 1d1d 1b17 1514 0000 0000  ................
0000380: 0000 0000 1c1d 1d1c 1815 1400 0000 0000  ................
0000390: 0000 0000 1b1d 1c1b 1715 0000 0000 0000  ................
00003a0: 0000 0000 191b 1c18 0000 0000 0000 0000  ................
(...)

The corresponding values in the XPM file are

Code: Select all

"# c gray8",
"$ c #151515",
"% c #161616",
"& c gray9",
"* c #181818",
"= c #191919",
"- c gray10",
"; c #1B1B1B",
": c gray11",
"> c #1D1D1D",
(...)
"       %*&#     ",
"      *=-*%#    ",
"     *;:;-&$    ",
"     -:>:=%#    ",
"    -:>>;&$#    ",
"    :>>:*$#     ",
"    ;>:;&$      ",
"    =;:*        ",
(...)

The same change is also visible with a simple xpm -> png convert

[glennrp]

It's most likely due to changes in handling sRGB vs RGB.
Try -colorspace RGB or -colorspace sRGB and settle on the
one you like.

[arand]

I tried adding -colorspace sRGB/RGB/Gray without any difference (before input, before output, before both...)

[arand]

It seems like this issue crops up not only when converting from XPM,

I created two PNG files, the first one "bad" is a convert XPM->PNG in GIMP, the "good" one is ImageMagick-extracted from the old "-depth 8 gray" binary file (which was previously generated from the XPM files).

When I open these two files in a viewer (Eye of GNOME) they are identical, (if I use ImageMagick to convert XPM -> PNG there is a visible difference of "less brightness" (some things completely background-colored)).

Code: Select all

identify gfx1*.png
gfx1-bad.png PNG 16x1760 16x1760+0+0 8-bit DirectClass 6.85KB 0.000u 0:00.010
gfx1-good.png[1] PNG 16x1760 16x1760+0+0 8-bit PseudoClass 256c 3.7KB 0.000u 0:00.000

http://ubuntuone.com/1J4ECWueHc32EW8u1trpYQ
http://ubuntuone.com/3JTHu3yZvtxrZgBxG3FG97

If I do

Code: Select all

convert gfx1-bad.png -depth 8 gray:g.bin

this results in the bad binary, whereas using the good PNG file produces a good binary as before, and as expected.

I tried converting this "bad" file into PseudoClass in the belief that this was the issue, but doing

Code: Select all

convert gfx1-bad.png -type Palette g.png

Resulted again in a visibly incorrect PNG image, like when it was converted XPM->PNG via ImageMagick

Since the difference in them seems to lie in "DirectClass" vs "PseudoClass 256c", the (superfluous?) layer id [1], and a whole lot of extra info, Is the complication in there somewhere?

Thanks for helping poking

[magick]

XPM is in the sRGB non-linear colorspace. Gray is linear. See the statistics differentials with these commands:

• convert gfx1.xpm -depth 8 -verbose info:
  convert gfx1.xpm -depth 8 gray:- | identify -verbose -size 16x1760 -depth 8 gray:-

Don't write to the gray: coder if you want non-linear pixels. Instead write to the RGB: coder and just extract the first channel.

[arand]

Ah, using RGB:out seems to make the bits end up with the correct value.
(if I use sRGB: it gives blank output on my version (6.7.7.10))

But, how would I extract one channel and compact that to pixel-per-byte, can I do it in ImageMagick?
I've been trying things back and forth, I'm guessing I'm looking at the wrong place though:

Code: Select all

convert gfx1.xpm -depth 8 RGB:- | convert -depth 8 -size 16x1760 RGB:- -depth 8 -channel R -separate gfx.bin

(doesn't work)

[anthony]

You could try converting to PGM instead. This given raw values (as numbers or binary).
http://www.imagemagick.org/Usage/formats/#pbmplus

You can also fool the various coders in believing the values are already in the expected colorspace (and thus need no auto-conversion) using -set colorspace

[arand]

Ah

Code: Select all

convert gfx1.xpm -set colorspace Gray -depth 8 gfx1.bin

seems to be what I was looking for, thanks
(I tested PNM files, and they're nice, but getting them into nice dimensions wasn't as pretty as I liked, and it inevitably involves changing the file format.)