This content has been marked as final. Show 11 replies
> If there is no simple workaround to achieve this, is there any chance for future SDK versions to support nonpower of 2 pixel bit depth?
Neither 12 nor 14 are powers of 2; these are the two most common bit depths of current digital cameras. The data is stored in 16bit format and WhiteLevel specifies the top of the actual value range.
Thank you for your quick response.
Yes, I know you can have 10/12/14 bit data stored on 16bit and use WhiteLevel to specify the maximum possible value.
Unfortunately, it so happens that I have "non power of two" bit depth data (10 bit or 12 bit or 14 bit) actually stored on 10 or 12 or 14 bps. Hence, doing a DNG export as you suggested would require some processing (to store each sample on 16 bit) and more space (e.g., approx. 60% more space would be necessary when saving actually 10bit data as 16bit data). This could become unpleasant when you have lots of large resolution images.
That's not a DNG SDK issue as such - the issue is that the DNG specification only allows for data types that have integral numbers of 8-bit bytes. So you could not create a valid DNG file with the kind of data that you would like to use.
You can however compress image data, which will get you down to as good (or better) file sizes.
Thank you for your suggestion. I will take a look at writing compressed data.
I have also reread DNG specification. It says:
Supported values are from 8 to 32 bits/sample. The depth must be the same for each sample if SamplesPerPixel is not equal to 1. If BitsPerSample is not equal to 8 or 16 or 32, then the bits must be packed into bytes using the TIFF default FillOrder of 1 (big-endian), even if the TIFF file itself uses little-endian byte order.
As I can understand from the above lines 10, 12, 14 bps should be supported. What am I missing?
Thank you very much.
Hmmm, interesting. I think you might be right, and it is possible. While TIFF/EP does only provide for byte sized data, it does allow for packing of data, which would do what you want. I took a look at the DNG SDK reader side, and there is support for reading packed data in dng_read_image::ReadUncompressed. But there's no corresponding support in image writer; bits per sample is set by tag size, which is always an integral number of bytes.
Send the Adobe folks a feature request, who knows.....
But I'd still think that using compression will be the best short term solution.
> If BitsPerSample is not equal to 8 or 16 or 32, then the bits must be packed into bytes using the TIFF default FillOrder of 1 (big-endian), even if the TIFF file itself uses little-endian byte order
One has to note here, that the above "definition" is none. There is no specification for when the filling stops and restarts. What is if the bit depth is 13? Will the last byte be padded at the end of a row of pixels, or only at the end of the image?
This is one sign of the many of the amateurish "standard" of DNG.
The DNG specification says:
"DNG is an extension of TIFF 6.0 and is compatible with the TIFF-EP standard. See these specifications for more information on TIFF and TIFF-EP"
And taking a look over TIFF 6.0 specification one can read that for compression 1 (uncompressed data) "Each scan line (row) is padded to the next BYTE boundary." This should answer your question.:)
Thank you for your help and suggestions. In the end, I will probably have to write my own module for DNG support. Still, I'm curious if CR will open 10bit DNG....
> See these specifications for more information on TIFF and TIFF-EP
I do know that specification. However, DNG deviates from the normal TIFF in enough points to warrant explicite specifications, particularly because several cameras' raw data is compressed in like but not identical ways.
> I'm curious if CR will open 10bit DNG....
The Pentax K10D creates 12bit, uncompressed DNG in this packed format and that will be processed by ACR correctly, so I guess you won't have any problem.
On the other hand, it is interesting, that the DNG converter stores 12 and 14bit data in 16bit form, thereby avoiding the issue; a huge waste of space.
> DNG converter stores 12 and 14bit data in 16bit form, thereby avoiding the issue; a huge waste of space.
That also explains, at least partially, why DNG files take so much longer to open and save on my machine. :/ The main reason I don't DNGs, apart from the fact that I don't see a need for them at this point.
> That also explains, at least partially, why DNG files take so much longer to open and save on my machine
I don't think that is the explanation. I am pretty sure the long reading and saving time relates to the compression. While testing, I often change between compressed and uncompressed DNGs; the uncompressed ones can be created and processed much faster. Multiprocessors are of no use for the decompression: the JPEG compressed data is a single byte stream, there is no way of parallel processing (the *lossy* JPEG data could be decoded by multiple processors).
>I am pretty sure the long reading and saving time relates to the compression.
Well, that too, of course. It's a moot point for me.