This page exists to clarify a few aspects of the DNG specification(s):
- DNG's relationship to standards
- Version control in DNG files
- Sensor areas: active area, crop area, masked pixels
- Fujifilm "SuperCCD" & "SuperCCD SR" sensors
- LinearizationTable
- Storage of Makernote in DNGPrivateData
- Why use JPEG lossless compression?
- Sigma/Foveon X3F images and DNG
- Canon sRAW format and DNG
- New tags and Opcodes in later versions
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". |
Metadata | ||
From the DNG specification: additional metadata may be embedded in DNG in the following ways:
|
||
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 | |
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 5 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. 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. Version 1.4.0.0 appeared with with Lightroom 4 beta in2012. The latest DNG specification is freely available from: Adobe - Digital Negative (DNG).
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. |
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. |
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. |
1.0.0.0 & 1.1.0.0 & 1.2.0.0 |
1.2.0.0, |
From now on, Adobe products write DNG version 1.2.0.0. However, unless certain new tags/values are used, the |
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, |
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:
Masked 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.
&
ImageWidthImageLength
refer to the size of A.
&
DefaultCropOriginDefaultCropSize
refer to C. - DNG version 1.1.0.0
This recognises all of these areas. It retains all raw image data within S.
&
ImageWidthImageLength
refer to the size of S.
refers to M.
MaskedAreas
refers to A.
ActiveArea
&
DefaultCropOriginDefaultCropSize
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 |
||
CFALayout | Staggered layout A: |
||
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:
- 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). - 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.
- 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).
- 2 bytes: the byte-order indicator from the original file (the usual 'MM'/4D4D or 'II'/4949).
- 4 bytes: the original file offset for the MakerNote tag data (stored according to the byte order given above).
- 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
andBitsPerSample
tags. (DNG usesSamplesPerPixel
= 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.
"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 | |
---|---|---|---|
(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 . |
|
(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 |
|||
(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". | ||
(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". | ||
(Initial sighting: |
The first sighting of DNG 1.4 came with Lightroom 4 beta. Here is a summary from Tom Hogarty (private correspondence): |
||
See DNG 1.4 Specification Notes by Tom Hogarty:
|
|||
CinemaDNG (September 2009) |
CinemaDNG uses DNG, but adds 2 extra options. These appear to be new tags. | ||
TimeCodes |
|||
FrameRate |