Page 1 of 1
incorrect conversion from XPM
Posted: 2012-09-25T21:49:58-07:00
by 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?
Re: incorrect conversion from XPM
Posted: 2012-09-25T23:28:13-07:00
by 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?
Re: incorrect conversion from XPM
Posted: 2012-09-26T05:44:10-07:00
by 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
Re: incorrect conversion from XPM
Posted: 2012-09-26T12:40:07-07:00
by 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.
Re: incorrect conversion from XPM
Posted: 2012-09-26T13:15:32-07:00
by arand
I tried adding -colorspace sRGB/RGB/Gray without any difference (before input, before output, before both...)
Re: incorrect conversion from XPM
Posted: 2012-09-26T13:59:25-07:00
by 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
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
Re: incorrect conversion from XPM
Posted: 2012-09-26T14:10:04-07:00
by 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.
Re: incorrect conversion from XPM
Posted: 2012-09-26T17:20:12-07:00
by 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)
Re: incorrect conversion from XPM
Posted: 2012-09-26T17:47:47-07:00
by 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
Re: incorrect conversion from XPM
Posted: 2012-10-01T12:29:46-07:00
by 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.)