Differences between revisions 1 and 2
Revision 1 as of 2008-06-26 12:26:07
Size: 3510
Editor: kfc
Comment: Created by the PackagePages action.
Revision 2 as of 2010-03-17 13:08:50
Size: 3510
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Please see ["DOMS images proposal"] for the proposal that will be sent to the proper people at SB. Please see [[DOMS images proposal]] for the proposal that will be sent to the proper people at SB.

De facto standard for SB is TIFF. Under consideration is PNG and JPEG.

Please see DOMS images proposal for the proposal that will be sent to the proper people at SB.

TIFF

TIFF is a flexible container format. Baseline TIFF defines a subset of TIFF which is fairly easy to parse and which can only contain

  • Bilevel (black and white) images
  • 4 or 8 bit grayscale images
  • 4 or 8 bit indexed color images
  • 24 bit RGB images
  • 1, 4 or 8 bit transparency mask

A Baseline TIFF consists of a tagged list of markers, followed by tables and pixel data.

  • The pixel data is normally in sequential order, but doesn't need to be.
  • The data can be stored RAW or compressed. RAW data can be padded by extra bytes.
  • Baseline TIFF can contain arbitrary data blocks, normally used for thumbnails.

See http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

Problems:

  • No direct support for 16 bit grayscale or 48 bit RGB
  • No direct support for CMYK
  • No direct support for non-quadratic pixels, although this can be simulated by XResolution and YResolution
  • No direct support for images with alpha channel
  • Maximum filesize of a baseline TIFF is 4 GB. Examples of limits because of this:
    • 16bit grayscale, scanned at 1200DPI: 100x100 cm.
    • 24bit RGB, scanned at 600 DPI: 80x80 cm.
    • 48bit RGB, scanned at 1200 DPI: 56x57 cm.

Recommendation: Uncompressed baseline TIFF with image data in sequential order + 16 bit grayscale + 8 bit RGB + color profile. No CMYK support, as it is very device-specific.

PNG

PNG is by design not flexible, it is therefore possible to claim full PNG compliance. Parts of PNGs is always compressed (this needs to be verified). Points about PNG:

  • Build-in checksums for different parts of the bytestream
  • 1, 2, 4, 8, 24 and 48 bit images, palette-based up to 8 bit and full-color beyond
  • Bi-level, grayscale and RGB only, no CMYK
  • Supports transparency, ICC profiles and gamma
  • Support text-blocks embedded in the datastream
  • Supports pixel aspect ratios
  • Maximum image dimensions of 231-1 x 231-1 pixels, maximum stream size of a little more than 2^61 bytes.

  • Patent free

See http://www.w3.org/TR/2003/REC-PNG-20031110/

Recommendation: PNG is all-or-nothing for the core data and there are no obvious extensions to recommend.

JPEG

JPEG's are normally considered a presentation-format, but most digital cameras anno 2006 uses JPEG's for storage. Therefore it it worth considering to support this as master format. Transformation to TIFF is lossless, but it is not possible to convert JPEG => TIFF => JPEG without introducing compression artefacts.

Caveats: Standard JPEG only supports 8bit / color channel.

Note 1: A subset of JPEG is JFIF, which is the de facto standard. Support for non-JFIF JPEG's in programs claiming to support JPEG's are not to be expected.

Recommendation: JFIF.

JPEG 2000

As with TIFF, JPEG 2000 is an extensible format with a core coding system, that is royalty and license-fee free. This core can be extended by various components, some of which requires royalty- or license-fee-payment.

  • Both lossless and lossy encoding
  • Multipage images with a mix of lossless and lossy images
  • Tile support

The selling point for JPEG 2000 over TIFF or PNG is the ease of which the master image data, tile based zooming data, presentational image data and meta data can be embedded in the same file.

DOMS images (last edited 2010-03-17 13:08:50 by localhost)