To whom it may concern,
Prelude: For simplicity I'll only talk about Windows in the following, we have not established the status of this on the Mac. We may but I will not update this forum post on that. It will stay what it is and we'll hope for the best. I wish there was a more suitable bug reporting channel but I found none.
We use Adobe DNG converter's conversion routines to "linear" DNGs, that is to readily demosaiced DNGs.
Like this: <dngConverterApp> -u -l -p0 -d <output> <input>
Of course you could get the according settings in place using the graphical user interface if you wanted to.
Now, the problem we located exists in the demosaicing of over exposed input. Why would it be over exposed? Because it is being used in assembling high dynamic range imagery. The problem is that in such over exposed areas pixels show up that should not. We have established that this behavior started with DNG converter 5.7 and has been in effect ever since. It was not exhibited at all by DNG converter 5.6 and below.
The following is plain Gamma 1.0 encoded data as resides in the demosaiced DNG that has been subjected to a crude Levels adjustment in PS so that the problem becomes plainly visible on this forum. In reality it is much more subtle but it is causing trouble in the HDR image creation I mentioned.
Of course there is a sample image to go along with this, that is really a junk photo by itself from a recent hardware test:
http://oldendorf.net/boards/DNG_bug_sample.dng
Just to clarify, this is a repro photo of a color negative and yes it has been deliberately over exposed.
The crop you are seeing above is from the tree trunks and we are viewing it at 200% zoom.
An 8 year old bug, alright. It would be nice if it could be fixed now that the two DNG Converter versions to diff have been conveniently pointed out.