Yet some DNG comments (from a raw software developer)

[BrianVS]

I was used to working with data sheets from film and later sensors to get the spectral response when converting intensity to "watts/Steradian". For the sensors, we did the spectral response measurements ourselves, stored "calibration files" and such. Such data is was not in the memory used by the digital sensors: spectral response data is not stored in the firmware of the camera. This would require that the manufactures measure the response, store the tables in non-volatile memory, and write the data to each image. I doubt they will do this. If the response curves were published, you could post-process the DNG files and patch the data in. This would require processing every file. I batch process DNG files from my Leica, very easy. The third, and most likely, back to collecting and publishing response curves for various cameras. Software would be written to read the curve and use it for color calibration.

Given the "Camera produces a Pretty Picture!" method of marketing cameras, it will be a miracle if manufacturers continue to provide uncompressed Raw image data (Sony A7 series, Leica M246, lower-end NEF, etc) in the future, let alone self-contained DNG files that have everything required to convert to real imagery.

[torger]

Given the "Camera produces a Pretty Picture!" method of marketing cameras, it will be a miracle if manufacturers continue to provide uncompressed Raw image data (Sony A7 series, Leica M246, lower-end NEF, etc) in the future, let alone self-contained DNG files that have everything required to convert to real imagery.

Yes indeed, things could be worse. That we get raw files at all rather than just JPEGs out of our cameras I would guess is one of those cases when the manufacturers actually listened to a minority of the customers. If the majority's we-don't-care attitude has been the deciding factor I think we'd still have only JPEGs.

Today raws are taken for granted and with user-friendly software like Adobe Lightroom I think even the majority uses raws. Hopefully we get to a time when a standard archival raw format is taken for granted too, but it's still a long way to go.

[amolitor]

'The majority uses raws'?

The majority of whom? Obviously not the majority of people who take photographs. The majority of DSLR owners?

[torger]

'The majority uses raws'?

The majority of whom? Obviously not the majority of people who take photographs. The majority of DSLR owners?

I'm speculating a bit of course as I have no real statistical information on the subject. I was thinking about the majority of professional photographers and enthusiasts.

[madmanchan]

Hi torger and folks,

I'd like to confess that I haven't read the entire thread, but I've read the first couple of pages of posts and would like to help answer questions and clear up any confusion if possible.  I'll start by responding to a couple of items from torger's original post.  Please see inline below.

Thanks,
Eric

The DNG format does not support much camera calibration data, frequently used in medium format camera formats such as IIQ and 3FR, things like flatfield correction.

This is not true.  DNG supports many of these calibrations using an "opcode" mechanism (see Chapter 7 of the DNG 1.4 spec).  These are basic image processing directives that can be used to correct common sensor/lens issues, such as color shading.  The flat field correction you mention, for instance, can be handled using the GainMap opcode (page 94), either in Bayer space (use 4 opcodes, one per Bayer plane, in either opcode list 1 or 2) or in RGB space (after interpolation, in opcode list 3).  There are other opcodes for handling other issues such as per-tile/area scale factors (MapTable or MapPolynomial), fixing bad pixels or entire rows/columns/areas, and the like.

- Can't alter hue/saturation of neutral axis (ICC can)
- LUT can't alter value of neutral axis (not really a problem of the format, but a problem of the ACR pipeline)
- Can't handle hue discontinuity (not really a problem of the format, but a problem of the ACR pipeline)

I don't understand the concern/objection here.  I agree that the LUT as defined does not permit altering the hue/sat of the neutral axis, but I don't see sepia or warming/cooling "looks" or "rendering styles" as something to be covered by the DNG spec anyways.  My understanding and interpretation of DNG (yes, the DNG concept was long before I became involved) is that it's intended to provide enough tags to interpret sensor data, as well as to provide a useful and reproducible baseline rendering -- not to cover/describe how to do all possible renderings.

As you know, the value (brightness) of the neutral axis can be adjusted using other mechanisms, such as the optional tone curve of a profile.

- Baseline exposure split between DNG file and DCP. This means that the camera profile can't specify the exposure offset on its own, but must relate to what tag the DNG converter has set. This is not good design.

Well, I think that depends on the point of view.  If you're a camera vendor or DNG author trying to create a DNG file, you embed the profile into the DNG (so it travels with the file), and you have control over both tags.  For example, if you want no adjustment at all, just set both tags to zero (or omit both tags), and no exposure compensation will be done. 

The two tags are set up this way because it's generally not possible for a profile to "know" under what context it will be used.  For example, the BaselineExposure tag for a given camera model may vary from shot to shot (for instance, it may be ISO dependent).  Having a separate tag for the profile gives an opportunity to bias the default exposure one way or another, without having to "know" what the absolute/underlying BaselineExposure value from the file/negative is.

- Blackrender not clearly defined how it affects rendering. A camera profile format that has tags of undefined meaning, and this is a central one -- not acceptable for a standard format.

Point taken.

- Matrices must be white-point preserving (generally what you want, but there are other ways to optimize a matrix)

I don't see this as a limitation.  Preserving the white point is a useful constraint, which simply says that white has to map to white (and more generally the neutral axis should map to itself).  This leaves 6 degrees of freedom for optimizing a 3x3 matrix, and there's no restriction on how those remaining DOF can be optimized -- various samples, color metrics, etc. can be used.

Color space cropped to ProPhoto primaries, which clips some of the human gamut (can be issue for scientific applications)

True, though in practice, if it's important for an application, it can also be easily worked around (by specifying a ForwardMatrix that effectively makes the color matrix transform step a no-op, in other words preserving the native color primaries of the capture, rather than transforming it into another space).

- White balance model built into the profile format, it's not a bad model but it's not so wise if you want others to adopt the format (which of course already have their own white balance models)

I think that comes down to which aspects of the WB model you're referring to.  Certainly dealing with multiple illuminants leaves a lot of room for different methods.  Dealing with a single illuminant, with a single set of WB scale factors, is much more straightforward. 

[amolitor]

If people spent as much time actually gathering up the known data about DNG and writing a standard around that, as they spent bitching and complaining in these threads, the standard would be done, reviewed, revised, and published.

It doesn't take an eternity to make something a Standard, unless you're in love with the idea of the CCITT or ISO or whomever owning it. It requires a small group of people to commit to doing a bit of work, and committing to sticking with it and forming a little committee with some rules and stuff. Set it up in a weekend. Writing the document would be a lot more work.

It won't make the many excellent reasons the majors have for not supporting it go away, but it would at least advance the cause slightly, which arguing on the internet won't.

[Schewe]

I'd like to confess that I haven't read the entire thread, but I've read the first couple of pages of posts and would like to help answer questions and clear up any confusion if possible.  I'll start by responding to a couple of items from torger's original post.

Eric,

Thanks for chiming in. To date, I think this is the best DNG File Format thread I've ever seen...some really good data has been exchanged and I hope it ends up being useful. In the grands scheme of things, arriving at a well documented raw file format will help the photo industry not retard it. Most of the FUD only muddies the waters and doesn't solve any issues. Kudos to all in the thread that kept it technical not political...this has been greatly needed (even if most of the tech is over my head–which I freely admit)!

[torger]

Thanks for the feedback Eric, I really appreciate it.

A few comments follows;

If the DNG format does support calibration data I would suggest to change the implementation of your DNG converter so that it embeds calibration data rather than applying it for formats like 3FR and IIQ. Users generally don't like "cooked" raws, and the only reason people haven't complained in this case is probably because they don't know it's happening.

One reason to change the neutral axis which is not related to look is if you want to use DNG profiles for reproduction photography and want to calibrate a fixed white balance setting. I also find the mix between "colorimetric scene-referred" and "subjective output-referred" a bit strange. These limitations are said to be because the format is intended to be scene-referred, but the look table, tone curve and indeed Adobe's own profiles says otherwise -- it's output-referred. When the actual use is output-referred with subjective tunings I find it odd to limit the neutral axis. With the neutral axis limited I also find it odd why these entries are included in the LUT at all, as their values must be set to 1,1,0. Adobe Camera Raw actually ignores those entries, I've tried to set them to other values but it has no effect.

You didn't comment on the hue discontinuity point. I did not explain that in detail either, here it comes. Hue is described as a circular value in the range 0-360 degrees, which means that 0 is the same as 360, +180 is the same as -180 etc. This makes the math a little tricky you need to take special care to make those additions right so you get the right result. In the DNG pipeline there is no such care taken. This means that if you have two neighboring entries in the LUT which differ more than 180 degrees, there will be an error in the calculation. Since RGB-HSV hue gets unstable when saturation is low it's not that unlikely you hit this when designing a profile, for example if the profile is designed in a CIECAM02 coordinate system. It's not too hard to work around though so it's not a huge deal, but the profile format would be easier to work with if the pipeline would have proper circular math when adding hues. If you don't want to fix this (you might not want to as it will potentially slow down the code), it should be a documented part of the standard. Now it just looks suspiciously similar to a bug

I have indeed noted that some Adobe profiles use the forward matrix as a no-op, and that you essentially make all color correction in the LUT. The output space is still ProphotoRGB though so you're still limited by its boundaries. Of course you could make some own non-standard translation on top with other primaries, but it would not be the standard. So I still think it's just fair to say that DNG in its standard mode is limited to ProPhoto and is not intended to cover the full human gamut. If that's a problem or not is debatable of course. Personally I don't think it's a big problem, but I find it unlikely that a standard organization would choose this type of limitation today.

If using the forward-matrix as no-op becomes a de-facto standard to avoid clipping, maybe one should do like the ICC Lab LUT profile case, specify in the standard that the matrix should be a no-op when a LUT is available? At least it would be helpful for profile designers to present this option and why it's useful in the DNG spec.

Interesting note about baseline exposure that it's used for compensating changes caused by ISO settings. I think it should then be thoroughly documented in the DNG spec that baseline exposure should be used for that and nothing else, otherwise there's a risk that the tag is used for the wrong purpose. A wrong use would be if it's the same over the whole ISO range, or if there is a base offset that is the same (that is if it varies between 0.2 and 0.5, it should instead vary between 0.0 and 0.3 and the profile should add the 0.2). In the current specification there is nothing mentioned about variation over ISO.

I have a strong view that letting the baseline exposure be "anything" is bad, so I'm certainly not satisfied with the current status, and I think I have quite strong arguments for my view. To make it a standard you need to think more about third parties so it not just becomes an internal Adobe Camera Raw format. Breaking the dependency between the DNG raw file itself and and the DCP is an important aspect of that, and to do that the baseline exposure can't work as it does now, oh well maybe it can (I haven't checked in detail how DNG converter uses it), but the documentation must state how it should be used that is only as an ISO-correcting offset (or any other factors that make exposure vary) with 0.0 as base. My point is that it should definitely not be used as a fixed offset, that should be part of the profile. Otherwise you break interoperability.

There's another aspect that probably should be documented similar to the BlackRender part, namely how the exposure offset is converted to a tone curve, which is a good idea as far as I can see especially for negative offsets (otherwise clipped data would be brought into view). There's code for that in the DNG reference SDK, perhaps it should be documented in the spec?

I can certainly live with the white-point preserving thing, I optimize my matrices with that constraint. I'm just mentioning it because ICC doesn't have this limitation and others might have a problem with that.

Considering the white balance model it's true that you can just ignore it. It just feels like one of those things that is more like an internal Adobe thing that exists in the standard for the convenience of Adobe rather than it's useful for the standard. If it's only there for Adobe to use, I don't think it should be there. I need to think more about it though, I haven't a 100% complete view on the subject of white balance / whitepoint modeling.

One particular aspect that gives me a bit of a headache when designing profiles that people use with Adobe Lightroom is that when the user has set a custom white balance Lightroom remembers the temp/tint setting and then run it backwards through the profile to calculate the multipliers. This means that if my color matrices are not exactly the same as Adobe's profiles there will be a white balance shift (that is when you switch to my profile the tint of the image changes). So I just had to add the option to copy the color matrices from existing profiles for those users that didn't want this to happen. The problem is that estimating temp/tint with a camera matrices cannot be very exact so even if Adobe and I have the most exact methods it's likely that the result will differ several hundred degrees anyway. I haven't analyzed this in depth yet to suggest how it should be done, but I think that there is a problem currently. Any aspect that makes interoperability difficult is not good for a standard.

[rdonson]

Eric,

Thanks for chiming in. To date, I think this is the best DNG File Format thread I've ever seen...some really good data has been exchanged and I hope it ends up being useful. In the grands scheme of things, arriving at a well documented raw file format will help the photo industry not retard it. Most of the FUD only muddies the waters and doesn't solve any issues. Kudos to all in the thread that kept it technical not political...this has been greatly needed (even if most of the tech is over my head–which I freely admit)!

Does this excellent thread point to the need for a public forum for the DNG community to exchange thoughts?

[sandymc]

One particular aspect that gives me a bit of a headache when designing profiles that people use with Adobe Lightroom is that when the user has set a custom white balance Lightroom remembers the temp/tint setting and then run it backwards through the profile to calculate the multipliers. This means that if my color matrices are not exactly the same as Adobe's profiles there will be a white balance shift (that is when you switch to my profile the tint of the image changes). So I just had to add the option to copy the color matrices from existing profiles for those users that didn't want this to happen. The problem is that estimating temp/tint with a camera matrices cannot be very exact so even if Adobe and I have the most exact methods it's likely that the result will differ several hundred degrees anyway. I haven't analyzed this in depth yet to suggest how it should be done, but I think that there is a problem currently. Any aspect that makes interoperability difficult is not good for a standard.

I don't think that there's a good solution to this. As soon as you change matrixes, either the tint of the image as rendered changes, or the user's saved temp/tint will have to be changed to preserve appearance. So from the perspective of someone writing a raw developer, either way someone's going to be unhappy.

Sandy

[AlterEgo]

So from the perspective of someone writing a raw developer, either way someone's going to be unhappy.

or as some people suggesting - just allow an option in UI in raw converter for people to switch from K/tint to "RGB" (pre/post demosaick) multipliers ... Iridient does that, no ?

[sandymc]

Does this excellent thread point to the need for a public forum for the DNG community to exchange thoughts?

It would certainly aid in the adoption of DNG if the spec were to become both better specified, and less Adobe centric, as laid out earlier in this thread. But Adobe own the spec. Unless they're up for changes to both to the spec, and more important to the governance of the spec, there won't be much point to exchanging thoughts.

Sandy

[sandymc]

or as some people suggesting - just allow an option in UI in raw converter for people to switch from K/tint to "RGB" (pre/post demosaick) multipliers ... Iridient does that, no ?

Yes, you could do that. The issues are, it's (a) yet another option, and more and more options is how you end up with a product like RPP (no insult to them, but RPP isn't a a mainstream product). And (b), it's a really exotic option that most average users won't understand. Also, (c) it's not just the matrixes - in the Adobe model, you could change color temp in the LUTs if you wanted. And makes implementing the option really tricky.

Sandy

[torger]

Regarding the temp/tint issue;

The problem is that the model is really unstable. If two separate design processes would lead up to almost exactly the same temp/tint estimation it would be fine, but it can be quite vast differences, ie it's almost impossible to get two different profiles agree on what temp/tint it is.

ACR should have stored RGB multipliers instead and let the temp/tint change if you alter profile, but keep the actual white balance the same. This is what happens already today when you leave the white balance at "as shot". So I think it's easy. Just let the "as shot" behavior be the behavior for all temperature settings -- just let temp/tint be a user-friendly front-end to change RGB multipliers, but store the multipliers, not temp/tint.

Temp/tint can't be trusted anyway and therefore I think there is little value in keeping them constant when changing profile. Say if you could measure a light source in a room to "5000K tint 0", and then just dial in "5000K tint 0" on any camera to match that so you have the right white balance for that room, then I would understand the value of storing temp/tint instead of RGB multipliers. However the temp/tint model is not and cannot be that stable and reliable to provide that sort of function.

This is actually not a problem with the DNG standard itself, but how Adobe have implemented it. As Adobe is so dominant their implementation will serve as a key reference, and therefore I think it's important that it's done "right" by them.

Now when it is the way it is they can't change it for existing ACR, but they could change the behavior for a future revision.

[Lightsmith]

Two standards for digital image formats have existed for decades, JPEG and TIFF. I can send a TIFF file anywhere in the world and it can be opened with any image editor or web press print software. DNG was developed by Adobe to save engineering labor and the delay in reverse engineering a new camera's RAW file. I spent time with someone who did the reverse engineering for Adobe and they would buy a camera to use to make the RAW files that would be reverse engineered. They chose not to use the camera manufacturer's API.

[Jeremy Roussak]

Why are you re-opening a thread which has been dormant for three and a half years?

Jeremy

[digitaldog]

Why are you re-opening a thread which has been dormant for three and a half years?

Jeremy

Good question, especially since the premise of the post is mostly false.    Didn't see any reason to go there but maybe that's why it was posted.
But is there any forum rules that forbid replying to a 'dormant' and old post?

[Jeremy Roussak]

Good question, especially since the premise of the post is mostly false.    Didn't see any reason to go there but maybe that's why it was posted.
But is there any forum rules that forbid replying to a 'dormant' and old post?

No. But that doesn't invalidate my question.

Jeremy

[BrianVS]

Too funny. Since the last response to this thread, I wrote my own DNG processor for the M8, M9, and M Monochrom.

TIFF- Most "manufacturer Raw" formats are a variation of TIFF with manufacturer specific tags. NEF is a variation of TIFF, DNG is a variation of TIFF. Not too hard to reverse engineer.

Don't know where adobe moved the spec- used the wayback machine to get to the link on the Library of Congress page regarding DNG format. Used this to write my code.

https://web.archive.org/web/20170115213607/http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/products/photoshop/pdfs/dng_spec.pdf

I had to write a TIFF processor for my wife over 20 years ago. TIFF allows multiple full digital images to be stored in one TIFF file. Their digital camera for the microscope, 1MPixel- a big deal in the 90s, stored all the images in a session in one TIFF file. Most software could only process the first image. Had to write code to read in the big TIFF and separate all images into separate TIFF files, with corrected header information. My "Honey-Do" list is always interesting. The hyper-spectral data that she works with now is a huge 3-D array of stacked images, no header information at all. No one told her the dimensions of the array.

[Bart_van_der_Wolf]

Good question, especially since the premise of the post is mostly false. 

Care to elaborate?

Cheers,
Bart