convert - PICT to TIFF results in 000000 bytes

[camposquinn]

Hi, I'm having some trouble converting PICT images (created circa 1997) into TIFF or really any other format.

Running

Code: Select all

magick convert input.pict output.tif

results in a black file that I can see in a hex editor is a valid TIFF file (Intel magic number) with several MB of 00000000 bytes.

Again in the Hex editor I can see that the input files contain a 512 byte empty header as referenced here https://github.com/ImageMagick/ImageMagick/issues/970.

Here's the output of `identify -verbose`:

Code: Select all

Image: /path/input.pict
  Format: PICT (Apple Macintosh QuickDraw/PICT)
  Class: DirectClass
  Geometry: 3072x2048+0+0
  Resolution: 72x72
  Print size: 42.6667x28.4444
  Units: Undefined
  Colorspace: sRGB
  Type: Bilevel
  Base type: Undefined
  Endianess: Undefined
  Depth: 8/1-bit
  Channel depth:
    Red: 1-bit
    Green: 1-bit
    Blue: 1-bit
  Channel statistics:
    Pixels: 6291456
    Red:
      min: 0  (0)
      max: 0 (0)
      mean: 0 (0)
      standard deviation: 0 (0)
      kurtosis: -3
      skewness: 0
      entropy: 0
    Green:
      min: 0  (0)
      max: 0 (0)
      mean: 0 (0)
      standard deviation: 0 (0)
      kurtosis: -3
      skewness: 0
      entropy: 0
    Blue:
      min: 0  (0)
      max: 0 (0)
      mean: 0 (0)
      standard deviation: 0 (0)
      kurtosis: -3
      skewness: 0
      entropy: 0
  Image statistics:
    Overall:
      min: 0  (0)
      max: 0 (0)
      mean: 0 (0)
      standard deviation: 0 (0)
      kurtosis: -3
      skewness: 0
      entropy: 0
  Colors: 1
  Histogram:
   6291456: (  0,  0,  0) #000000 black
  Rendering intent: Perceptual
  Gamma: 0.454545
  Chromaticity:
    red primary: (0.64,0.33)
    green primary: (0.3,0.6)
    blue primary: (0.15,0.06)
    white point: (0.3127,0.329)
  Matte color: grey74
  Background color: white
  Border color: srgb(223,223,223)
  Transparent color: none
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 3072x2048+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: Undefined
  Orientation: Undefined
  Properties:
    date:create: 2018-12-17T15:15:12-08:00
    date:modify: 1997-03-10T09:30:08-08:00
    signature: 2ca8f698096c926a0ed939656eb5e7a81f2635b99b6889bd815a84ab811eb4f5
  Artifacts:
    verbose: true
  Tainted: False
  Filesize: 4.43681MiB
  Number pixels: 6.29146M
  Pixels per second: 125.829MP
  User time: 0.040u
  Elapsed time: 0:01.049
  Version: ImageMagick 7.0.8-16 Q16 x86_64 2018-12-17 https://imagemagick.org

and `exiftool`:

Code: Select all

ExifTool Version Number         : 11.11
File Name                       : input.pict
Directory                       : /my/path/
File Size                       : 4.4 MB
Resource Fork Size              : 39 kB
File Modification Date/Time     : 1997:03:10 09:30:08-08:00
File Access Date/Time           : 2018:12:18 12:19:35-08:00
File Inode Change Date/Time     : 2018:12:17 15:15:12-08:00
File Permissions                : rwxrwxrwx
File Type                       : PICT
File Type Extension             : pict
MIME Type                       : image/pict
Image Width                     : 12288
Image Height                    : 8192
X Resolution                    : 288
Y Resolution                    : 288
Image Size                      : 12288x8192
Megapixels                      : 100.7

The fact that `convert` is producing non-arbitrary amounts of data in output files when run against files of varying sizes makes me think that the PICT reader in `convert` is really reading something in the resource in terms of maybe the bounding box or... like the file length?? But there's something up when it tries to output the bytestream as a rastered image. I am out of my depth and grasping at straws...

Also, I tried various flags like turning off/removing alpha, tried `-compress none`, and some other flags.

Any ideas? Thanks!

UPDATE: looking at the output of identify, I can see that it registers as 1-bit depth... and Histogram registers as #000000. This seems... incorrect? I can see the image using Preview and clearly there is color information in there beyond 1-bit (black and white). :/

[fmw42]

Post your PICT image to some free hosting service such as dropbox.com that will not change the data and put the URL here so we can test with it.

Also please always provide your IM version and platform/OS

[camposquinn]

Thanks! Here is a sample image: https://bit.ly/2EDWI2l

IM version: Version: ImageMagick 7.0.8-16 Q16 x86_64

OS: Mac OSX 10.11.6

I was asking around and someone else said they thought it could be Kodak PhotoCD format rather than PICT, though every tool says PICT. I see in `exiftool -v` and also in the ANSI view in my hex editor there's a message "QuickTime and a Photo CD Decompressor are needed to use this picture."

I also see references to "Photo YCC RGB Standard," which I read a bit more about being a colorspace developed by Kodak for this particular 35mm film to CD format. Also, there's a bit about "Kodak FilmScanner" which makes sense since these are frame enlargements from motion picture film. Also also, there's a reference to PCD_IPI, which appears to be the PhotoCD magic number, at offset 0x2048, but in my files it's at offset 0xCB2. Moving that around just makes things worse....

So I think I have some "weird files" that we will find some other means to extract the data from, but I would really like to see if there's some way to get IM to convert the image information. The Ted Felix site I link to below mentions some problems when transferring files from a PhotoCD to Mac. The copy I had in our library was from a CD-R burned at an unknown date, probably on a Mac, possibly as a copy from the original PhotoCD, if that is what the real history here is. Evidently the PhotoCD system required a specialized drive to render the images on a TV monitor (!). So... an interesting history lesson? I will see if I can extract the data and if anyone has info/help I would appreciate it!

Some reading on PhotoCD:
http://tedfelix.com/PhotoCD/PCDAdvanced.html
http://printwiki.org/Photo_CD

`exiftool -v` output:

Code: Select all

  ExifToolVersion = 11.11
  FileName = myInputFile
  Directory = /path/
  FileSize = 4900140
  ResourceForkSize = 39931
  FileModifyDate = 1545180381
  FileAccessDate = 1545181486
  FileInodeChangeDate = 1545180406
  FilePermissions = 33279
  FileType = PICT
  FileTypeExtension = PICT
  MIMEType = image/pict
  ImageWidth = 12288
  ImageHeight = 8192
  XResolution = 288
  YResolution = 288
PICT version 2 extended
Tag 0x0001, ClipRgn (Rgn):
  rgnSize (int16u) = 10
  rgnBBox (Rect):
    topLeft (Point):
      v (int16s) = 0
      h (int16s) = 0
    botRight (Point):
      v (int16s) = 2048
      h (int16s) = 3072
  data (int8u[0])
Tag 0x00a0, ShortComment (int16u) = 222
Tag 0x00a1, LongComment (LongComment):
  kind (int16u) = 220
  size (int16u) = 468
  data (binary[468]) = <binary data>
Tag 0x8200, CompressedQuickTime (CompressedQuickTime):
  size (int32u) = 4898970
  version (int16u) = 0
  matrix (int32u[9]) = 65536 0 0 0 65536 0 0 0 1073741824
  matteSize (int32u) = 0
  matteRect (Rect):
    topLeft (Point):
      v (int16s) = 0
      h (int16s) = 0
    botRight (Point):
      v (int16s) = 0
      h (int16s) = 0
  mode (int16u) = 64
  srcRect (Rect):
    topLeft (Point):
      v (int16s) = 0
      h (int16s) = 0
    botRight (Point):
      v (int16s) = 2048
      h (int16s) = 3072
  accuracy (int32u) = 768
  maskSize (int32u) = 0
  matteDescr (Int32uData[0])
  matteData (int8u[0])
  maskRgn (int8u[0])
  imageDescr (ImageDescription):
    size (int32u) = 86
    cType (string[4]) = kpcd
    res1 (int32u) = 0
    res2 (int16u) = 0
    dataRefIndex (int16u) = 0
    version (int16u) = 0
    revision (int16u) = 0
    vendor (string[4]) = 
    temporalQuality (int32u) = 0
    quality (int32u) = 768
    width (int16u) = 3072
    height (int16u) = 2048
    hRes (fixed32u) = 72
    vRes (fixed32u) = 72
    dataSize (int32u) = 4898816
    frameCount (int16u) = 1
    nameLen (int8u) = 8
    compressor (string[31]) = Photo CD
    depth (int16u) = 32
    clutID (int16u) = 65535
    clutData (binary[0])
  imageData (binary[4898816]) = <binary data>
Tag 0x0007, PnSize (Point):
  v (int16s) = 174
  h (int16s) = 110
Tag 0x0007, PnSize (Point):
  v (int16s) = 1
  h (int16s) = 1
Tag 0x0003, TxFont (int16u) = 0
Tag 0x0004, TxFace (int8u) = 0
Tag 0x000d, TxSize (int16u) = 12
Tag 0x0028, LongText (PointText):
  txLoc (Point):
    v (int16s) = 40
    h (int16s) = 35
  count (int8u) = 16
  text (string[16]) = QuickTime? and a
Tag 0x0028, LongText (PointText):
  txLoc (Point):
    v (int16s) = 64
    h (int16s) = 20
  count (int8u) = 21
  text (string[21]) = Photo CD Decompressor
Tag 0x0028, LongText (PointText):
  txLoc (Point):
    v (int16s) = 88
    h (int16s) = 2
  count (int8u) = 30
  text (string[30]) = are needed to use this picture
Tag 0x0000, Nop (null)
Tag 0x00a0, ShortComment (int16u) = 221
End of picture

[fmw42]

magick identify -verbose says your image is 3k x 2k pixels. The format page at https://imagemagick.org/script/formats.php says that if your image is actually PCD, then your image is too large and thus is huffman encoded, which ImageMagick does not support currently.

PCD RW Photo CD The maximum resolution written is 768x512 pixels since larger images require huffman compression (which is not supported). Use -bordercolor to specify the border color (e.g. -bordercolor black).

However, IM identifies the image as quickdraw/pict. But when I try to convert it, I just get black. So I will have to defer to the IM developers on this one.

Note that Photoshop won't open it as it says the image contains data in a format that is no longer supported.

Mac Preview will open it for me. So will Mac GraphicConverter.

[camposquinn]

Whew. OK, thanks for taking the time to dive in to this! Yes, Mac preview can view the files but we're interested in converting them to a better format for preservation, and this has been a wild ride.

All of what you said makes sense, and there are some additional elements I read about, plus some context for how we got the images. The CD-R that we received included two folders, one marked 3072x2048 (the default PhotoCD dimensions) and the other marked 384x256 (one of the derivative sizes included by default on a PhotoCD).

From the PCD documentation I can find, the default 3072x2048 image uses Huffman compression. I didn't realize that wasn't supported by IM, but that's life.

This Corel Draw thread from 1998 describes files very similar to mine, where Mac OS wrapped PCD files in a pseudo-PICT wrapper. They don't appear to have solved the issue, but it's some interesting corroborating evidence:
https://groups.google.com/forum/m/#!top ... btwY7AoWAo

Jason Scott's file format wiki was also incredibly helpful:
http://fileformats.archiveteam.org/wiki/Photo_CD
http://fileformats.archiveteam.org/wiki/PICT

I reached out on Twitter and one of the FFmpeg developers (apparently ffmpeg used to support PICT?) recommended I move the PCD_IPI string (the PCD magic number/file signature) to offset 2000 and perhaps try to get around the false PICT signatures.

I may be reaching the limit of how much time I can spend on these in particular, but I'm a librarian interested in this kind of weird file format mystery...

Thanks again!

[Jason S]

Your file is a PICT file by all rights, though it's being used as a thin wrapper around a Photo CD (PCD) file. Probably, everything you care about is in the PCD part.

It should be safe to delete the correct number of bytes (1202 in this case) from the beginning of the file, and use it as a PCD file. I don't know what your options are for converting the full-resolution PCD image, though.

I don't know if Exiftool can extract the PCD file. Sorry for the self promotion, but I know that my Deark utility can do it. It understands the PICT "CompressedQuickTime" opcode well enough to reconstitute it into a QTIF file, from which it can extract the PCD file.

Code: Select all

$ deark Painleve_Love-Life-of-the-Octopus_048.pict
Module: pict
Format: PICT v2
Writing output.000.qtif
$ deark output.000.qtif
Module: qtif
Writing output.000.pcd
$ magick convert output.000.pcd Painleve.png
$

[Hmm... I'm seeing strange colors when IM converts (the low-res image in) this PCD file directly to TIFF format. It works okay with PNG and other formats. There may be another problem here.]

[camposquinn]

Thanks Jason! I also got some weird color shifts when converting to TIFF. I also tried GraphicsMagick convert and got the same result, but inverted (R->G->B). Interesting, but not what I was after.

I will check out your utility!

[fmw42]

Those kinds of color shifts that can be inverted are likely due to the image being CMYK rather than RGB.

[camposquinn]

Woah! Deark is sooooo cool! All those incredible file formats!

So, following some recommendations on the file formats wiki linked above, and following your deark example I did:

Code: Select all

$ deark /path/Painleve_Acera-or-the-Witches-Dance_053 
Module: pict
Format: PICT v2
Writing output.000.qtif
$ deark /path/output.000.qtif 
Module: qtif
Writing output.000.pcd
$ magick convert /Users/michael/Desktop/painleve/output.000.pcd[6] out5.png

Specifying the 6th indexed element in the PCD gets the highest resolution version that was included with the PhotoCD (which stored several levels of the image (or maybe instructions to recreate the levels? not clear)).

Now I need to figure out how to run this programmatically. Thank you thank you!

[fmw42]

Note that for IM 7, use magick, not convert and not magick convert. Otherwise, you may get IM 6 behavior

[camposquinn]

Thank you Fred!