The Scitex CT file (.sct, .ct)

A Scitex CT file is a picture made for print, stored the way a printing press needs it: as separate amounts of cyan, magenta, yellow and black ink for every pixel. CT stands for continuous tone, the printing term for photographs and other images with smooth gradations, as opposed to line work such as text and logos.

The format comes from Scitex Corporation, founded in Israel in 1968 by Efi Arazi. Scitex made systems and equipment for graphic design, printing and publishing, and Scitex CT was the image format of its equipment, used for colour-intensive work such as magazine adverts and newspapers. Scitex documented it for exchanging files with other systems in a manual called the HandShake Foreign File Transfer Protocol, and ImageMagick lists the format as Scitex HandShake.

Scitex sold its graphic arts business to Creo in 2000, and in 2005 sold its Scitex Vision business, with the rights to the Scitex name, to Hewlett-Packard; the remaining company became Scailex. CMYK print images today are usually TIFF, PSD and PDF. A .sct file you meet now is most likely from an archive: old scans, ad material or a publisher's back catalogue.

The pixel data is line interleaved: line 1 holds all its cyan bytes, then its magenta, yellow and black; then line 2 does the same. That suited a press workflow, where each ink is a separate plate, and it means a reader has to gather four separate runs of bytes to build one pixel. There's no compression and no checksum, so a file's size is easy to predict: 2,048 bytes of header plus lines × separations × pixels per line (rounded up to even). A 2,000 × 3,000 pixel CMYK image is about 24 MB.

• Separations. The format allows up to 16, but only the first four, cyan, magenta, yellow and black, are defined; the rest were reserved for later use. Only the separations named in the mask are stored.
• Greyscale and RGB. File registries list greyscale and RGB colour models as well as CMYK, and ImageMagick reads one or three separations as grey or RGB. LEADTOOLS' documentation says the format is used primarily for CMY and CMYK images.
• Inverted values. In CMYK files, 00 is 100% ink and FF none. PCI's writer sets cyan to the red value of an RGB image, and ImageMagick's reader subtracts each CMYK byte from the maximum: both treat the bytes as the amount of light, not ink.
• No colour profile. The file says nothing about which press, paper or ink set the separations were made for.

Because the specification was never published, some details can't be checked against an authoritative source:

• How numbers are written in the text fields. Readers parse them as text, but whether Scitex systems padded them with spaces or zeros, or used a particular decimal format, isn't documented. Our example uses plain numbers padded with spaces.
• Unit codes other than 0. 0 means millimetres. Codes for other units, if any, aren't documented.
• Scan direction codes. The parameter block has a scan direction byte, but no public source lists its values, and ImageMagick ignores it.
• The other HandShake file types. LW, BM, PG and TX are recognised by ImageMagick but not decoded, and their layouts aren't described in any source we found.
• When the format appeared. No source we found gives a date or a version history.

If you are writing a reader, be generous: accept the CT type at byte 80, parse the numbers as text with surrounding spaces or zeros, and check the separation mask rather than assuming four channels.

For anything new, use TIFF for a CMYK image with a colour profile, PSD if it needs layers, or a PDF/X file for a finished page. Converting a Scitex CT file to CMYK TIFF loses nothing: same channels, same 8-bit values.

• ImageMagick (Windows, macOS, Linux) reads Scitex CT and writes almost anything else. It can't write SCT.
• GraphicsMagick also lists Scitex CT as read-only.
• Commercial libraries: Accusoft's ImageGear reads and writes uncompressed 32-bit CMYK Scitex CT, and LEADTOOLS lists read and write support. The Wolfram Language imports and exports SCT.
• Desktop publishing software: Photoshop, InDesign and QuarkXPress have supported Scitex CT. Check whether your version still lists it.
• Browsers, Windows Photos and macOS Preview don't open it.

# Scitex CT to CMYK TIFF: same channels, same values
convert scan.sct -depth 8 scan.tif   # ImageMagick 6
magick scan.sct -depth 8 scan.tif    # ImageMagick 7

# to an RGB PNG for viewing (colours are an approximation)
convert scan.sct -colorspace sRGB scan.png

# a folder of them
mogrify -format tif -depth 8 *.sct

If the file has a .ct extension or none, ImageMagick may not recognise it from the name. Rename it to .sct, or prefix the file name with sct: (convert sct:scan.ct scan.tif). Without -depth 8, ImageMagick's usual build writes a 16-bit TIFF: correct, but twice the size.

• The image looks like a negative. The reader didn't invert the CMYK values. In Scitex CT, 00 is full ink; subtract each byte from 255.
• The image is skewed or striped diagonally. The line has an odd number of pixels and the reader ignored the pad byte at the end of each separation.
• Colours look wrong or dull. The CMYK values were converted to RGB with a generic profile. Convert to CMYK TIFF first and assign the profile the job was separated for, if you know it.
• "Only continuous tone picture supported". ImageMagick found LW, BM, PG or TX at byte 80: another kind of Scitex file, which it can't decode.
• Not recognised at all. Check bytes 80 and 81 with a hex viewer. If they aren't CT, the file isn't Scitex CT: other programs also use .ct for unrelated files.

A Scitex CT file holds a header and pixels, nothing that runs. The risk is in readers that trust the header: the pixel counts are text, so a damaged or crafted file can claim any size. Readers of rare formats get little testing, and GraphicsMagick 1.3.25's Scitex CT reader had an out-of-bounds read that a crafted header could trigger (CVE-2016-8682). If you process uploaded images with ImageMagick or GraphicsMagick, keep them up to date, and consider disabling coders for formats you don't need in the security policy.