Photoshop and DNG - saving as original

[k-hawinkler]

Advertisement (gone after registration)

Sandy,

 

Thanks. May I assume PS CS5 does the same as LR3?

 

Best, K-H.

[sandymc]

May I assume PS CS5 does the same as LR3?

 

No, I'm afraid not - LR is a non-destructive editor, but PS is not. They do interoperate, but there is no guarantee that if you were to open a "CFA" DNG in PS, edit it, then save as DNG, that you would still have a "CFA" DNG. It may occur under some circumstances (I'm not a PS expert ), but you can't count on it.

 

LR and PS are the same as regards their behavior with JPEGs saved as DNG however, in both cases you'll get a "linear raw" DNG

 

Sandy

[hoppyman]

Sandy, thank you very much for that additional information on the 'why'.

 

II should have clarified that I meant Adobe Camera Raw rather than its host, Photoshop too.

[ho_co]

Sandy--

Interesting information. Could you also consider this question:

 

What does DNG Converter or ACR do when it reduces a compressed M8 file to less than half its original size? That is, where's the wasted space in the original? I'm sure my earlier assumption is wrong (that deleting the LUT saves all that space), but why is the M8 file so bloated compared to what Adobe can do with it? Or is that too general a question to be meaningful?

 

Thanks.

[sandymc]

Sandy--

Interesting information. Could you also consider this question:

 

What does DNG Converter or ACR do when it reduces a compressed M8 file to less than half its original size? That is, where's the wasted space in the original? I'm sure my earlier assumption is wrong (that deleting the LUT saves all that space), but why is the M8 file so bloated compared to what Adobe can do with it? Or is that too general a question to be meaningful?

 

Thanks.

 

Howard,

 

The DNG specification allows for lossless Huffman compression of raw data (emphasis on lossless). This is somewhat similar to the the type of compression used by ZIP files. DNG converter (or LR or ACR) can do this kind of compression. The M8/M9 do not, probably because of the limited processing power available in-camera; it's fairly computationally intensive. So DNG converter can gain about 50% over the native M8/M9 file - made practical by a desktop class processor versus the low-power CPU on the camera

 

Regards,

 

Sandy

[peterv]

Likewise, toDNG (one of my apps), which can convert pretty much an bitmap image to DNG also writes linear raw DNGs.

 

Sandy

 

Hi Sandy,

 

after reading this I bought your app because I like to work in ACR. ToDNG DNG's are more than twice as big as DNG's I get when opening in ACR through Bridge and than save as DNG. Bummer... Why is that?

A 3MB JPG becomes op 40+ DNG... That's a lot.

Doesn't your App use lossless compression?

[sandymc]

Advertisement (gone after registration)

Hi Sandy,

 

after reading this I bought your app because I like to work in ACR. ToDNG DNG's are more than twice as big as DNG's I get when opening in ACR through Bridge and than save as DNG. Bummer... Why is that?

A 3MB JPG becomes op 40+ DNG... That's a lot.

Doesn't your App use lossless compression?

 

Peter,

 

It does, but (a) its 16-bit versus 8-bit for JPEGs (so twice as big right there), and ( jpegs use lossy compression, which is much more efficient than lossless compression.

 

Generally, toDNG is optimized to keep all of the information that is in the original file. That does mean that for highly compressed JPEGs, you can see considerable expansion in size.

 

Regards,

 

Sandy

[peterv]

Peter,

 

It does, but (a) its 16-bit versus 8-bit for JPEGs (so twice as big right there), and ( jpegs use lossy compression, which is much more efficient than lossless compression.

 

Generally, toDNG is optimized to keep all of the information that is in the original file. That does mean that for highly compressed JPEGs, you can see considerable expansion in size.

 

Regards,

 

Sandy

 

Thank you Sandy for taking the time to answer my question.

 

toDNG is optimized to keep all of the information that is in the original file

 

This is the part I don't get, if there's originally only 3 MB in the file, how come the DNG needs 40+ MB to store this information?

 

Thanks

[sandymc]

This is the part I don't get, if there's originally only 3 MB in the file, how come the DNG needs 40+ MB to store this information?

 

Thanks

 

Well, aside from the doubling from 8-bits to 16-bits, the major reason is the lack of JPEG compression. JPEG compression works basically by throwing away high frequency information - edges, etc - that's what gives the JPEG artifacts. But it also allows JPEG to compress very efficiently, because most images are just a set of blobs of approximately the same color. So a JPEG image is more or less a description of a series of blobs of color, covering numbers of pixels.

 

However, the kind of compression that DNG allows is arithmetic - it has no idea of blobs of color, so it describes each and every pixel. It can compress very simplistically, on the basis of a linear sequence of similar pixels, but that's hugely less efficient that a 2-D approach.

 

So, in effect, the DNG file encodes and stores pixel by pixel not just the "image", but also all of the JPEG file's compression artifacts, etc, etc at 100% fidelity.

 

It is hugely wasteful, but given the nature of DNG compression, and that most of the audience for toDNG want 100% fidelity, that's where you end.

 

Regards,

 

Sandy

[peterv]

Thanks again Sandy,

 

I hope you don't mind my questions.

One more:

Than why is the Adobe JPG to DNG conversion two times smaller than your App's DNG's?

[sandymc]

Thanks again Sandy,

 

I hope you don't mind my questions.

One more:

Than why is the Adobe JPG to DNG conversion two times smaller than your App's DNG's?

 

Peter,

 

I haven't tried, but I would guess they are going to 8-bit DNGs when they convert JPEGs. Which you can do - technically you just take the 8-bit JPEG data, and encode the sRGB gamma curve into a LUT.

 

Thinking about it, that might not be a bad option to offer on the next version(!)

 

Regards,

 

Sandy

[peterv]

That would explain it, thanks.

BTW, I think your app is really very useful for batch converting. Glad I bought it.

 

Do you think that the 16 bit DNG's from 8 bit JPG's will behave more robust in ACR? That is, will there be more room for applying adjustments before running into, for example, posterization?

[sandymc]

That would explain it, thanks.

BTW, I think your app is really very useful for batch converting. Glad I bought it.

 

Do you think that the 16 bit DNG's from 8 bit JPG's will behave more robust in ACR? That is, will there be more room for applying adjustments before running into, for example, posterization?

 

Peter,

 

Maybe, but it only only be a very slight effect - ACR will be loading the JPG into its own 16-bit space for processing anyway, so I doubt that you'd notice a practical difference.

 

Regards,

 

Sandy

[peterv]

Sandy, thanks for answering my questions, I'll be using toDNG for batch converting tiffs and jpgs.

 

Kind regards,

 

Peter

[jaapv]

That would explain it, thanks.

BTW, I think your app is really very useful for batch converting. Glad I bought it.

 

Do you think that the 16 bit DNG's from 8 bit JPG's will behave more robust in ACR? That is, will there be more room for applying adjustments before running into, for example, posterization?

 

This is spot-on and essential for good quality post-processing without posterisation. An allegory is:

imagine the respective bits as buckets standing in a row. If you put a 8 bits image into eight buckets, when you start postprocessing, you will shift the data into the next bucket, so when you try to shift them again, they will have been mixed up with the data already in that bucket. If you use 16 bits processing you will be shifting your data into an empty bucket keeping them separate.

Both C1 and ACR offer the option . In ACR it is a bit hidden, the line giving the settings underneath the preview is actually a button.