tags 471651 + wontfix severity 471651 wishlist thanks "A. Costa" <agco...@gis.net> writes:
> % convert SM2000.bmp SM2000.png > % file SM2000.* > SM2000.bmp: PC bitmap data, Windows 3.x format, 640 x 480 x 24 > SM2000.png: PNG image data, 640 x 480, 8-bit/color RGB, non-interlaced > > The BMP says 24 bits, and the PNG says '8-bit/color RGB' -- which > means 8 bits per color times 3 = 24? but it's still confusing having > two different numbering systems. 'x 24' is what was expected. Well, take a look at the PNG magic(5): ,---- | # PNG [Portable Network Graphics, or "PNG's Not GIF"] images | # (Greg Roelofs, n...@uchicago.edu) | # (Albert Cahalan, acaha...@cs.uml.edu) | # | # 137 P N G \r \n ^Z \n [4-byte length] H E A D [HEAD data] [HEAD crc] ... | # | 0 string \x89PNG\x0d\x0a\x1a\x0a PNG image data | !:mime image/png | >16 belong x \b, %ld x | >20 belong x %ld, | >24 byte x %d-bit | >25 byte 0 grayscale, | >25 byte 2 \b/color RGB, | >25 byte 3 colormap, | >25 byte 4 gray+alpha, | >25 byte 6 \b/color RGBA, | #>26 byte 0 deflate/32K, | >28 byte 0 non-interlaced | >28 byte 1 interlaced `---- It may not be immediately apparent, but "8-bit" and "/color" are not added to the output as a result of the same computation. First, the "Bit depth" field is read, and " 8-bit" gets appended to the output as a result: ,---- | >24 byte x %d-bit `---- Next, the "Color type" field is checked for several values in turn, and "/color RGB," gets added by the succesful check: ,---- | >25 byte 2 \b/color RGB, `---- It would be possible to check "Color type" field first, but there does not appear to be any way to do arithmatic on a value read from the file before printing it, so I don't see any practical way to get the behavior that you want. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
