I was trying to use IM -> Convert to simply add the most trivial possible header to a .raw file without altering the data:
Code: Select all
convert -size "7378x4924" -depth 16 gray:pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm
lsr -s pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw 72658544
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm 72658563
add 72658563 -72658544 =-> 19
Code: Select all
head -n 3 pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm
P5
7378 4924
65535
identify pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm PGM 7378x4924 7378x4924+0+0 16-bit Gray 72.66MB ...
And, Photoshop likes it! Perfect?
NO! The data are altered. It looks like roundoff error from a float -> integer conversion. But, reading 16 bit gray data into a 32 bit float with 23 bits of significand should be an exact copy unless a gamma is being applied or it is being converted to L*ab or ???
If I dump the first 16 bytes of the .RAW file, then fseek past the header of the PGM file and dump the next 16 bytes, the bytes are altered slightly:
Code: Select all
dumpb pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw 0 16 8 [[ Start at byte 0; dump 16 Bytes; uint8 format ]]
II [0] 8 (26) (93) (253) (92)
II [4] 8 (131) (94) (250) (95)
II [8] 8 (215) (92) (132) (89)
II [12] 8 (35) (90) (183) (90)
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm 20 16 8
Seeked 20 bytes from file start
II [20] 8 (26) (92)<<93 (253) (94)<<92
II [24] 8 (131) (95)<<94 (250) (92)
II [28] 8 (215) (89) (132) (90)
II [32] 8 (35) (90) (183) (91)
Code: Select all
convert -size "7378x4924" -depth 16 gray:pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw -compress None pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm
=>
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw 72658544
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm 212467460 << 3X file size
identify pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm PGM 7378x4924+0+0 16-bit Grayscale 212.5MB ...
Why would turning off compression make it create invisible data? Creating new data without changing quanta, resolution or file type looks like an accounting bug.
If I tell it to use no compression AND output a "GRAY:" file, it does just that:
Code: Select all
convert -size "7378x4924" -depth 16 gray:pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw -compress None gray:pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm
lsr -sm pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw 5d6c89c14e31fbfaf9ed9d44ecbf18eb 72658544
pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm 5d6c89c14e31fbfaf9ed9d44ecbf18eb 72658544 << Same MD5
Code: Select all
identify pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm identify: improper image header `pf-249465.dcr.T6Fww.xyz.7378x4924.blu.raw.pgm' @ error/pnm.c/ReadPNMImage/284.
===============
convert -> Version: ImageMagick 6.9.3-8 Q16 x86_64 2016-04-20
Features: Cipher DPC HDRI Modules OpenMP
Delegates (built-in): bzlib fontconfig freetype jng jpeg lcms ltdl lzma openexr pangocairo png tiff x xml zlib
IM-> identify from same source