DNG specification

This page exists to clarify a few aspects of the DNG specification(s):

DNG's relationship to standards

DNG isn't (yet) an ISO standard, nor a standard of any other standards development organization (SDO). But it is compatible with an ISO standard, and nearly all aspects of DNG are based on ISO or other standards. Here are the main ones. (This table will evolve to provide more links and information).

DNG SDO De Jure Standard
File format generally ISO - International Organization for Standardization

ISO 12234-2, "TIFF/EP". (Draft). From the DNG specification: "DNG ... is compatible with the TIFF-EP standard".
(This is based on TIFF 6.0, a de facto standard owned by Adobe).
At October 2008, the working group (WG18) revising TIFF/EP said about the revised version: "... the document currently includes two "interoperability-profiles," "IP 1" for processed image data, using ".TIF" extension, and "IP 2" for "raw" image data, ".DNG" extension."
(From OpenRAW mailing list) Dietmar Wueller: we just had a meeting discussing the current working draft for the upcoming standard.... In October 2010 we hope to reach the so called CD (committee draft) state which means that the technological content is ready to move to a standard. The document then get a final technical review and two editorial reviews before publication.... Typically it will take 6 month to 1 year from CD to publication.

Metadata

From the DNG specification: additional metadata may be embedded in DNG in the following ways:

  • Using TIFF-EP metadata tags
  • Using Exif and GPS-Exif metadata tags
  • Using the IPTC metadata tag
  • Using the XMP metadata tag.
TIFF-EP metadata ISO - International Organization for Standardization (TIFF-EP stores the metadata tags in IFD 0).
Exif  metadata JEITIA - Japan Electronics and Information Technology Industries Association (Exif and GPS-Exif store the tags in separate IFDs). "Exchangeable image file format for digital still cameras: Exif Version 2.2".
XMP metadata (tag 700)

(ISO - International Organization for Standardization)

 XMP was developed by, and is owned by, Adobe. But it is used in various ISO standards, and hence has credibility within ISO:
XMP mandated by ISO standards
Adobe have proposed that XMP should become an ISO standard. The core would be under the control of TC130, while specific parts would be under the control of other parts of ISO. (PDF - see section 6)
IPTC metadata (tag 33723) IPTC - International Press Telecommunications Council

IPTC Metadata for XMP (IPTC4XMP)
Others
Colour matrices CIE - International Commission on Illumination CIE XYZ coordinates.
Colour profiles ICC - International Color Consortium ICC profiles.
Previews JPEG - Joint Photographic Experts Group JPEG (lossy) compression.
Compression of raw image data JPEG - Joint Photographic Experts Group JPEG lossless compression.
Compression of embedded original raw files (None?) ZIP compression, a de facto standard. Used for optional embedded original raw files.

Version control in DNG files

DNG is designed to evolve. It has a version scheme built into it that allows the DNG specification, DNG writers, and DNG readers, to evolve at their own paces.

So far, there have been 4 versions of the DNG specification. Version 1.0.0.0 was published when DNG was launched in September 2004, with the simultaneous release of "2.3" (ACR and DNG Converter). Version 1.1.0.0 was published in February 2005, but was used in "2.4" released in January 2005. Version 1.2.0.0 was published in May 2008, but was used in "4.4" released in March/April 2008. The latest DNG specification is freely available from: Adobe - Digital Negative (DNG). Version 1.3.0.0 was first written by beta versions of "5.4" (ACR and DNG Converter) in May 2009, and published in June 2009.

The way the version scheme works is that each DNG file holds its own version (the version of the specification it was written to) in itself. It can also hold the oldest version it is compatible with, (and if it doesn't there is a rule that defines that by default). So even after a new feature is added to the specification, if a DNG writer doesn't use that new feature, the version range in the DNG file would include previous versions. Then a DNG reader checks these numbers, and tells the user that an upgrade is needed if it can't handle this version. Perhaps some raw converters would decide not to handle that new feature. They would still be able to handle DNGs for cameras that didn't use it.

Ideally, DNG readers will continue to accept all versions from 1.0.0.0 up to the latest they are able to support. After all, many photographs are held in version 1.0.0.0 DNG files. But it is also expected that converters will always be available to create later versions from earlier versions. For example, Adobe's DNG Converters from "3.2" to "4.3.1" can read version 1.0.0.0 files and create version 1.1.0.0 DNG files from them. (Equally, some products before "3.2" can read version 1.1.0.0 files and create version 1.0.0.0 DNG files from them, but this has limited use!)

Product Versions read Versions written Commentary
ACR 2.3 1.0.0.0 (No) Supplied at the launch. Obsolete.
DNG Converter 2.3 1.0.0.0 1.0.0.0
ACR 2.4 1.0.0.0 & 1.1.0.0 (No) This is the ACR to use with Photoshop CS. From now on, Adobe products can read DNG version 1.1.0.0 as well as version 1.0.0.0.

DNG Converter 2.4 to 3.1.
ACR 3.0 to 3.1.

 1.0.0.0 & 1.1.0.0 1.0.0.0 In the unlikely event that it is desired to convert files from DNG version 1.1.0.0 to version 1.0.0.0, these are the products to use.

DNG Converter 3.2 to 4.3.1.
ACR 3.2 to 4.3.1.
Lightroom 1.0 to 1.3.1.

 1.0.0.0 & 1.1.0.0 1.1.0.0 From now on, until "1.4" and "4.4" (see below) Adobe products write DNG version 1.1.0.0.

DNG Converter 4.4 onwards.
ACR 4.4 onwards.
Lightroom 1.4 onwards.

1.0.0.0 & 1.1.0.0 & 1.2.0.0

1.2.0.0,
but typically compatible with 1.1.0.0.

From now on, Adobe products write DNG version 1.2.0.0.

However, unless certain new tags/values are used, the DNGBackwardVersion should be 1.1.0.0 to enable existing DNG readers to render the images.

DNG Converter 5.4.
ACR 5.4.
Lightroom 2.4.		 1.0.0.0 & 1.1.0.0 & 1.2.0.0 & 1.3.0.0

Optional, including: 1.3.0.0,
but typically compatible with 1.1.0.0, where this works within the constraints of the raw file.

From now on, Adobe products by default write DNG version 1.3.0.0. The DNG Converter has a backward-compatibility option, which in some circumstances may result in Linear DNG. See "New DNG Specification".

Sensor areas: active area, crop area, masked pixels

What are the "black masked pixels" that are catered for in the 2nd version of the DNG specification, but not the first? What does "DNG Recover Edges" do? Do these questions overlap? (Not really!)

DNG treats areas of raw image data as shown in the following image:

  • S:
    The maximum Sensor area from which raw data is contained in any DNG files.
  • A:
    The Active Area, which is the largest area from which a useful image can be formed. For some cameras, this is exactly the same as S. For other cameras, especially some Canons, this is a (majority) subset of S.
  • C:
    The Crop Area, which is the subset of the Active Area which many raw converters convert into a useful image. The main reason why C is smaller than A is to provide some extra pixels all around for a raw converter's demosaicing algorithm to use. (There are other reasons too, for example to cater for different aspect ratios). Although there is typically a default crop area, probably as quoted in the published specifications about the camera, some raw converters make a larger image available.
  • M:
    M    asked Areas, (there can be more than one), used by some cameras, especially Canons, to fine-tune the image quality.

DNG changes from version 1.0.0.0 to 1.1.0.0

  • DNG version 1.0.0.0
    This only recognises A and C. It discards raw image data outside A.
    ImageWidth     & ImageLength refer to the size of A.
    DefaultCropOrigin     & DefaultCropSize refer to C.
  • DNG version 1.1.0.0
    This recognises all of these areas. It retains all raw image data within S.
    ImageWidth     & ImageLength refer to the size of S.
    MaskedAreas     refers to M.
    ActiveArea     refers to A.
    DefaultCropOrigin     & DefaultCropSize refer to C.

DNG Recover Edges

(Thomas Knoll's DNG Recover Edges).

This simply makes C equal to A. DefaultCropOrigin becomes (0,0) and DefaultCropSize becomes the same as that of ActiveArea. (This may cause problems for some raw converters, because those extra edge-pixels are used by demosaicing algorithms).

Example - Canon 5D

The Canon 5D was first supported in "3.3", so normally DNG conversions are to version 1.1.0.0. But those DNGs can be converted to version 1.0.0.0, for example by using the 3.1 DNG Converter, and the following table shows some differences between version 1.0.0.0 and version 1.1.0.0 for this camera.

DNG tag DNG version 1.0.0.0 DNG version 1.1.0.0
  Default Recovered edges Default Recovered edges
ImageWidth

4386

4476
ImageLength

2920

2954
MaskedAreas This tag is not in the specification. Masked areas not included in the raw image data of the DNG file. Relative to sensor area: Top = 34, Left = 0, Bottom = 2954, Right = 88
ActiveArea This tag is not in the specification, so this is not specified explicitly, because it is all that is recorded. Implicitly treated as equal to ImageWidth & ImageLength. Relative to sensor area: Top = 34, Left = 90, Bottom = 2954, Right = 4476
The following are relative to ActiveArea, (A), whether that is specified explicitly (1.1.0.0) or implicitly (1.0.0.0). ActiveArea is the one fixed size throughout all of this discussion. In summary, the following is the same whether 1.0.0.0 or 1.1.0.0 is used.
DefaultCropOrigin Horizontal = 10, Vertical = 5 Horizontal = 0, Vertical = 0 Horizontal = 10, Vertical = 5 Horizontal = 0, Vertical = 0
DefaultCropSize Horizontal = 4368, Vertical = 2912 Horizontal = 4386, Vertical = 2920 Horizontal = 4368, Vertical = 2912 Horizontal = 4386, Vertical = 2920

Fujifilm "SuperCCD" & "SuperCCD SR" sensors

The DNG camera profile treats the Fujifilm sensors a bit like a Bayer-sensor with a zig-zag, then changes the aspect ratio afterwards. The table below shows part of the camera profile for various Fujifilm cameras, extracted from DNGs created from RAFs. For interest, DNGs from the S3 Pro are the only ones I have seen where the DNG file has 2 samples per pixel - the separate S & R values.

DNG tag S9000/S9500 S2 Pro S3 Pro
  (SuperCCD) (SuperCCD SR)
CFARepeatPatternDim

Rows = 2, Cols = 4
CFAPattern

Red Green Blue Green
Blue Green Red Green
CFALayout

Staggered layout A:
even columns are offset down by 1/2 row
SamplesPerPixel

1

1

2
DefaultScale

H = 0.7171 V = 1.4342

H = 0.7105 V = 1.4211

H = 0.7149 V = 1.4298
BestQualityScale

1.0000

1.4074

1.3988

A source of frustration for Fujifilm camera users

Fewer raw converters can process raw image data from Fujifilm "SuperCCD" & "SuperCCD SR" sensors than from Bayer sensors. Some users of Fujifilm cameras wonder why a "common raw file format" like DNG doesn't solve this problem.

But no true raw file format can solve this problem! The photographer's use of "raw" postpones the processing of the raw image data to the raw converter, so that is where the necessary code must exist. Once that raw image data is in the memory of the raw converter, it doesn't make a difference to the code whether it came from a DNG file or a native raw file.

Here is a fuller discussion.

LinearizationTable

This enables considerable compression of a DNG file. Whether this is lossless or lossy compression depends on whether the DNG-writer discarded information in order to exploit it. It applies to both "Raw DNG" and "Linear DNG".

Consider an 8-bit TIFF file. Only 256 discrete values per channnel are present. Such a file can be converted to "Linear DNG". But the latter (being linear) does not have the gamma-conversion of the original TIFF file, therefore those 256 values are spread over a much greater range, for example the range 0 to 65535. Without special treatment, each channel then needs 16-bits to represent it, even though the vast majority of the values of the those 16-bits are never used. (Only 256 out of 65536 values would be used). Instead, the channels can be represented by 8-bit values, acccompanied by a LinearizationTable that applies across all the channels. If such a table is provided within the DNG file, it is a look-up table that enables the 8-bit value to be converted into (say) a 16-bit value, assuming that the LinearizationTable comprises 256 16-bit entries.

That was a simple example. A LinearizationTable held within a DNG file may have a different number of entries. If 16-bit values are held per channel, the LinearizationTable (if present) may have 65536 entries. (There are rules to govern what happens if there are fewer entries in the table).

The Leica M8 camera uses DNG as its raw file format. It stores 8-bits (1 byte) per pixel in its raw files. It also stores a LinearizationTable of 256 16-bit entries in the DNG file to convert those value into 16-bit values. It can have useful dynamic range, while still having only 256 discrete levels. (The way the Leica M8 derives its 8-bit values from its original larger values is not constrained by the DNG specification. In fact, it converts its original values to 16-bit values, then takes the square-root, making it an 8-bit value. The LinearizationTable happens to square the 8-bit value, but that has nothing to do with the DNG specification).

Storage of Makernote in DNGPrivateData

This information was posted by John Francis (8 January 2007) . A response from Thomas Knoll was "The best documentation for this is the source code in the DNG SDK". (See: dng_info.cpp).

The DNGPrivateData generated by the DNG Converter, hence containing the original EXIF Makernote, is:

  1. Six bytes containing the zero-terminated string "Adobe". (The DNG specification calls for the DNGPrivateData tag to start with an ASCII string identifying the creator/format).
  2. 4 bytes: an ASCII string ("MakN" for a Makernote),  indicating what sort of data is being stored here. Note that this is not zero-terminated.
  3. A four-byte count (number of data bytes following); this is the length of the original MakerNote data. (This is always in "most significant byte first" format).
  4. 2 bytes: the byte-order indicator from the original file (the usual 'MM'/4D4D or 'II'/4949).
  5. 4 bytes: the original file offset for the MakerNote tag data (stored according to the byte order given above).
  6. The contents of the MakerNote tag. This is a simple byte-for-byte copy, with no modification.

There was a lot of discussion (in fact, argument!) about this topic in the Adobe DNG forum. It terminated with:
Thomas Knoll: "My summary of this thread: Barry is correct ...."

This information is found in the "Adobe" DNGPrivateData. (From ExifTool by Phil Harvey).

Why use JPEG lossless compression?

Thomas Knoll: "PNG uses ZIP compression, which does poorly on data deeper than 8 bits/channel, which most raw formats contain. I actually tried ZIP compression in prototype versions of DNG, but the compression ratio was much better using lossless JPEG."

(For information, optional embedded original raw files - OriginalRawFileData - are compressed with ZIP compression. It is the main raw image data that is - optionally - compressed with JPEG lossless compression).

And which type of lossless JPEG does that mean? In response to:

"The DNG specification states ... the JPEG variant must be lossless Huffman JPEG. However, there are TWO lossless compressions for JPEG (apart from JPEG 2000). There was the original method, defined around 1995, which was not very successful, but it worked; this was called LJPEG. Then, in 2004 a new method was adopted, called JPEG-LS or LOCO-I. Both methods use Huffmann encoding"

Thomas Knoll responded: "The DNG spec (and Canon CR2 format, plus several Kodak raw formats) uses the old original lossless JPEG standard. I suggest you download the DNG SDK and read the source code yourself if you want all the details".

Sigma/Foveon X3F images and DNG

Adobe's Zalman Stern:
"There is no way to support Foveon X3 data in DNG without publishing intimate details of the off-sensor data, which is Foveon's intellectual property. (It would be pointless for us to define a DNG format that is not documented well enough that other raw converters can convert the data into a displayable image)". X3F files are always converted to Linear DNG format.

Adobe's Zalman Stern:
"For X3 sensors the raw sample data is not stored in the DNG unless the embed original option is chosen as DNG cannot specify how to process the X3 data. (We take enough heat for allowing undocumented vendor specific maker notes to be moved over into DNG, which is absolutely necessary. Allowing image data which no one can do anything with short of major feats of reverse engineering would be very bad.) Linear DNG is used instead. For almost all other sensors, the raw data is stored fairly directly with no material data loss".

What would have to be done for a future specification to support Foveon sensors? Here are the sorts of topics that the people evolving the specification for layered data would have to resolve:

  • There is no problem with holding the raw image data itself. DNG (in fact ISO 12234-2 that is was based on) has SamplesPerPixel and BitsPerSample tags. (DNG uses SamplesPerPixel = 2 for Fujifilm SuperCCD sensors).
  • A harder task is to decide what extra tags would be needed, and to specify them in such a way that a raw converter could render the raw image data by feeding the values of those tags into some algorithm. In effect, those tags would identify the relationship between the raw image data and the image at the plane of the sensor.
  • Part of this relationship, the mapping between the raw image data and the coordinates of the image, may not need extra tags. (I believe Foveon sensors don't pose challenges such as unsquare pixels or offset pixels. Anyway, DNG has tags to handle those cases, for Nikon D1X, Fujifilm sensors, etc).
  • Probably the main challenge is to define tags to describe the tonal responses and colour mapping. These tags would then be present in each Raw DNG for a Foveon image, providing different values for different sensors. Given the number and complexity of related tags for CFA sensors, there would probably be several such tags, and their definition would be complicated. Foveon would probably have to be involved in their definition. There would need to be extensive descriptions of how to use those tags, just as there is in the DNG specification for how to do some of the mathematics to exploit the existing tags.

Canon sRAW format and DNG

Canon sRAW files get much larger when converted to DNG. Here are explanations: short thread and long version.

From Gabor:

"The RAW image contains a single pixel value for each pixel; this is 21 Mpix x 14bits, losslessly compressed.

" The SRAW image is in a hybrid format; it is not truly raw any more. It is raw only in the sense, that the colors are in the camera's color space and WB has not been applied yet, but otherwise it has nothing common with the original raw format. It is demosaiced, i.e. the pixels have three color components. However, not each pixel has three separate color component: adjacent pixel pairs are sharing two of the three color components."

New tags and Opcodes in later versions

The original version was 1.0.0.0. This shows later changes. (Quotes in the "Commentary" mostly come from the DNG specification versions 1.1.0.0, 1.2.0.0, and 1.3.0.0).

DNG version DNG tag Commentary

1.0.0.0

(September 2004)

AnalogGain This appeared once as a typo in 1.0.0.0, and should have been AnalogBalance. That appearance has since been replaced by AnalogBalance.

1.1.0.0

(February 2005)

 ShadowScale "This tag is used by Adobe Camera Raw to control the sensitivity of its "Shadows" slider".
RawDataUniqueID "This tag contains a 16-byte unique identifier for the raw image data in the DNG file".
OriginalRawFileName "If the DNG file was converted from a non-DNG raw file, then this tag contains the file name of that original raw file".
OriginalRawFileData "If the DNG file was converted from a non-DNG raw file, then this tag contains the compressed contents of that original raw file".
ActiveArea "This rectangle defines the active (non-masked) pixels of the sensor. The order of the rectangle coordinates is: top, left, bottom, right".
MaskedAreas "This tag contains a list of non-overlapping rectangle coordinates of fully masked pixels, which can be optionally used by DNG readers to measure the black encoding level".
AsShotICCProfile "This tag contains an ICC profile that, in conjunction with the AsShotPreProfileMatrix tag, provides the camera manufacturer with a way to specify a default color rendering from camera color space coordinates (linear reference values) into the ICC profile connection space".
AsShotPreProfileMatrix
CurrentICCProfile "The CurrentICCProfile and CurrentPreProfileMatrix tags have the same purpose and usage as the AsShotICCProfile and AsShotPreProfileMatrix tag pair, except they are for use by raw file editors rather than camera manufacturers".
CurrentPreProfileMatrix

1.2.0.0

(May 2008)

There are changes in addition to extra tags, especially: NewSubFileType now allows for multiple renderings of alternative or non-primary rendered previews (not just multiple sizes of a single rendering) to be stored in a DNG file; the concept of a "camera profile" is formalised and allows multiple camera profiles to be embedded in a single DNG file.
ColorimetricReference "The DNG color model documents a transform between camera colors and CIE XYZ values. This tag describes the colorimetric reference for the CIE XYZ values".
CameraCalibrationSignature "A UTF-8 encoded string associated with the CameraCalibration1 and CameraCalibration2 tags".
ProfileCalibrationSignature "A UTF-8 encoded string associated with the camera profile tags".
ExtraCameraProfiles "A list of file offsets to extra Camera Profile IFDs".
AsShotProfileName "A UTF-8 encoded string containing the name of the "as shot" camera profile, if any".
NoiseReductionApplied "This tag indicates how much noise reduction has been applied to the raw data on a scale of 0.0 to 1.0".
ProfileName "A UTF-8 encoded string containing the name of the camera profile".
ProfileHueSatMapDims "This tag specifies the number of input samples in each dimension of the hue/saturation/value mapping tables. The data for these tables are stored in ProfileHueSatMapData1 and ProfileHueSatMapData2 tags".
ProfileHueSatMapData1 "This tag contains the data for the first hue/saturation/value mapping table".
ProfileHueSatMapData2 "This tag contains the data for the second hue/saturation/value mapping table".
ProfileToneCurve "This tag contains a default tone curve that can be applied while processing the image as a starting point for user adjustments".
ProfileEmbedPolicy "This tag contains information about the usage rules for the associated camera profile".
ProfileCopyright "A UTF-8 encoded string containing the copyright information for the camera profile".
ForwardMatrix1 "This tag defines a matrix that maps white balanced camera colors to XYZ D50 colors".
ForwardMatrix2 "This tag defines a matrix that maps white balanced camera colors to XYZ D50 colors".
PreviewApplicationName "A UTF-8 encoded string containing the name of the application that created the preview stored in the IFD".
PreviewApplicationVersion "A UTF-8 encoded string containing the version number of the application that created the preview stored in the IFD".
PreviewSettingsName "A UTF-8 encoded string containing the name of the conversion settings (for example, snapshot name) used for the preview stored in the IFD".
PreviewSettingsDigest "A unique ID of the conversion settings (for example, MD5 digest) used to render the preview stored in the IFD".
PreviewColorSpace "This tag specifies the color space in which the rendered preview in this IFD is stored.... DNG writers should set the DNGBackwardVersion tag to a minimum of 1.2.0.0 if non-default values are used for this tag".
PreviewDateTime "This tag is an ASCII string containing the name of the date/time at which the preview stored in the IFD was rendered".
RawImageDigest "This tag is an MD5 digest of the raw image data".
OriginalRawFileDigest "This tag is an MD5 digest of the data stored in the OriginalRawFileData tag".
SubTileBlockSize "Normally, the pixels within a tile are stored in simple row-scan order. This tag specifies that the pixels within a tile should be grouped first into rectangular blocks of the specified size.... The use of a non-default value for this tag requires setting the DNGBackwardVersion tag to at least 1.2.0.0."
RowInterleaveFactor "This tag specifies that rows of the image are stored in interleaved order... The use of a non-default value for this tag requires setting the DNGBackwardVersion tag to at least 1.2.0.0."
ProfileLookTableDims "This tag specifies the number of input samples in each dimension of a default "look" table".
ProfileLookTableData "This tag contains a default "look" table that can be applied while processing the image as a starting point for user adjustment".

1.3.0.0

(June 2009)

The release of ACR 5.2 and DNG Converter 5.2 revealed a limitation with the current version of DNG for some Panasonic and Leica cameras, which needs a new version of DNG. Here is a DPReview summary of extra flexibility added in 1.3.0.0. Here is Adobe's Tom Hogarty describing the background to Opcodes.
OpcodeList1 "Specifies the list of opcodes that should be applied to the raw image, as read directly from the file".
OpcodeList2 "Specifies the list of opcodes that should be applied to the raw image, just after it has been mapped to linear reference values".
OpcodeList3 "Specifies the list of opcodes that should be applied to the raw image, just after it has been demosaiced".
NoiseProfile "NoiseProfile describes the amount of noise in a raw image".
Opcodes Opcode Summary
WarpRectilinear "This opcode applies a warp to an image and can be used to correct geometric distortion and lateral (transverse) chromatic aberration for rectilinear lenses".
WarpFisheye "This opcode applies a warp to an image and can be used to “unwrap” an image captured with a fisheye lens and map it instead to a perspective projection".
FixVignetteRadial "This opcode applies a gain function to an image and can be used to correct vignetting".
FixBadPixelsConstant "This opcode patches (interpolates over) bad pixels in a Bayer pattern CFA image".
FixBadPixelsList "This opcode patches (interpolates over) bad pixels and rectangles in a Bayer pattern CFA image".
TrimBounds "This opcode trims the image to the rectangle specified by Top, Left, Bottom, and Right".
MapTable "This opcode maps a specified area and plane range of an image through a 16-bit LUT".
MapPolynomial "This opcode maps a specified area and plane range of an image through a polynomial function".
GainMap "This opcode multiplies a specified area and plane range of an image by a gain map".
DeltaPerRow "This opcode applies a per-row delta (constant offset) to a specified area and plane range of an image".
DeltaPerColumn "This opcode applies a per-column delta (constant offset) to a specified area and plane range of an image".
ScalePerRow "This opcode applies a per-row scale to a specified area and plane range of an image".
ScalePerColumn "This opcode applies a per-column scale to a specified area and plane range of an image".

1.4.0.0

(January 2012)

The first sighting of DNG 1.4 comes with Lightroom 4 beta. Here is a summary from Tom Hogarty (private correspondence):

The ability to embed "Fast Load Data" that Adobe clients like Lightroom and Camera Raw will be using to load and display raw data much, much faster than waiting to read the entire file off of disk.
Lossy Compression. The linear DNG data will be compressed providing the flexibility of raw with a significant reduction in file size. (Canon 7D files compress from 24MB to 6MB at full resolution).
Lossy Compression with Downsampling. Lossy compressed DNG files can be reduced in resolution through a Lightroom export process. (There are a number of resolution decreasing options in the export dialog).

CinemaDNG

(September 2009)

CinemaDNG uses DNG, but adds 2 extra options. These appear to be new tags.
TimeCodes  
FrameRate