txt image file format has changed

[PeterDHPet]

I'm building a program to measure luminance from images generated by a DSLR
camera. One step is using the 'convert' command to create a text formatted
image file from a .tiff image file. The behaviour has changed between
versions. Here is a sample of first few lines of the .txt file.

Version: ImageMagick 6.7.7-10 2016-06-01
# ImageMagick pixel enumeration: 574,432,65535,srgb
0,0: (65526,65534,65535) #FFF6FFFEFFFF srgb(99.9863%,99.9985%,100%)
1,0: (65534,65534,65535) #FFFEFFFEFFFF srgb(99.9985%,99.9985%,100%)
2,0: (65535,65534,65535) #FFFFFFFEFFFF srgb(100%,99.9985%,100%)
3,0: (65535,65534,65535) #FFFFFFFEFFFF srgb(100%,99.9985%,100%)
4,0: (65535,65534,65535) #FFFFFFFEFFFF srgb(100%,99.9985%,100%)

Version: ImageMagick 6.8.9-9 Q16 x86_64 2016-04-18
0,0: (100%,100%,100%) #FFFFFFFEFFFF srgb(100%,100%,100%)
1,0: (100%,100%,100%) #FFFEFFFEFFFF srgb(100%,100%,100%)
2,0: (100%,100%,100%) #FFFFFFFEFFFF srgb(100%,100%,100%)
3,0: (100%,100%,100%) #FFFFFFFEFFFF srgb(100%,100%,100%)
4,0: (100%,100%,100%) #FFFFFFFEFFFF srgb(100%,100%,100%)

There are two issues with this latest version:
- The values in brackets round off the actual value, as given by the hex
numbers after the hash mark.
- The values in brackets are repeats, which doesn't seem to be all
that useful.

The solution of course is to use the hexadecimal values in both cases,
which is what I have done. I just hope that doesn't go away.

ImageMagick is a fabulous resource. I document this in case no one
else has spotted it.

Peter

[magick]

Try the latest release of ImageMagick 6.9.6-6. If you still get unexpected results, let us know and we'll investigate further.

[fmw42]

This is not a bug. The txt image format (and color specifications, esp for HSL/HSB) have had at least 3 fomats. The most recent rgb version now looks like the following.

Code: Select all

convert rose: -depth 16 txt:
# ImageMagick pixel enumeration: 70,46,65535,srgb
0,0: (12336,12079,11565)  #30302F2F2D2D  srgb(48,47,45)
1,0: (12850,12336,11822)  #323230302E2E  srgb(50,48,46)
2,0: (13878,12850,12079)  #363632322F2F  srgb(54,50,47)
3,0: (14392,13107,11822)  #383833332E2E  srgb(56,51,46)
4,0: (14906,13107,11565)  #3A3A33332D2D  srgb(58,51,45)
5,0: (14649,12850,11565)  #393932322D2D  srgb(57,50,45)
6,0: (14392,12336,11565)  #383830302D2D  srgb(56,48,45)
7,0: (14649,12593,11822)  #393931312E2E  srgb(57,49,46)
8,0: (14392,12336,11565)  #383830302D2D  srgb(56,48,45)
9,0: (14392,12336,11565)  #383830302D2D  srgb(56,48,45)
10,0: (14135,12079,11308)  #37372F2F2C2C  srgb(55,47,44)
11,0: (13621,11565,10794)  #35352D2D2A2A  srgb(53,45,42)
12,0: (13364,11308,10537)  #34342C2C2929  srgb(52,44,41)

The percents have been rolled back to integers to avoid decimals.

The raw values are now back to integers and the srgb values are now 0 to 255 integers. Grayscale image will report gray(X) with x=0 to 255 and bilevel images will report either white or black or possibly just gray(0) or gray(255). I think that depends upon the image format.

There were reasons for the change, but that is too long to explain. Suffice it to say, you may need to do version traps if you are scripting to get values you need.

[PeterDHPet]

Thanks for the update. The format of the latest version looks fine.

As long as there continues to be an entry of hexadecimal values following a hash mark,
my code should work fine.

Nice work, folks.

Peter