Changing to DNG saves Space?

asamuel

I always thought the opposite. but:

My CR2 files + XMP files + (caches) previously came to 10.2 GB

DNG (no new bridge chaches created for yet) comes to 5.07 GB

Can this decrease in folder size be down to the removal of XMP sidecars and Bridge Caches?

Its hard to do a file count on account of the original containing XMP side cars but, I searched for CR2 files and it said in the original folder I had 442 CR2 files.

However, I batch converted to DNG to a seperate folder and I have 449 DNG files. Could I have converted 7 PSD files to DNG? Is that possible?

If so then the GB would add up.

search for CR2 in the original folder = 5.01
file count of new DNG convert = 5.07 as previously stated.

Can anyone confirm this sounds reasonable. Thanks Sam.:bow

arodney

DNGs are typically smaller due both to better compression and to removal of proprietary XMP it can't see or use.

Bridge stores its cache outside the documents.

claudermilk

Removal of XMP is negligible in that. It's about 1-2K of text data. SO, compression would be the answer. However, storage sapce is so cheap, that alone isn't enough reason to make the conversion IMHO.

arodney

claudermilk wrote:

Removal of XMP is negligible in that. It's about 1-2K of text data. SO, compression would be the answer. However, storage sapce is so cheap, that alone isn't enough reason to make the conversion IMHO.

True (about XMP). There might me other kinds of metadata that's stripped, don't know if would account for much size wise. There's the JPEG too (I tend to use medium in my DNG's, update to Large if I've done rendering to those files). They still seem to remain a bit smaller than the originals.

BTW, when things start to roll with DNG with respect to the JPEG, its going to be very, very useful! Peter Krogh, author of the DAM book showed me pretty large prints made directly from the embedded JPEGs in the DNG (set to large) and the same file printed from the DNG data (same rendering of course). I couldn't really see a difference. For lots of printing use, taking the existing JPEG (if updated to the current rendering) is fast, doesn't require one to use the Raw converter and allows you to share the rendering while keeping the Raw untouched by others.

Rhuarc

arodney wrote:

For lots of printing use, taking the existing JPEG (if updated to the current rendering) is fast, doesn't require one to use the Raw converter and allows you to share the rendering while keeping the Raw untouched by others.

This is exactly what I do in IDImager. It uses the embedded JPEG for almost everything. Makes the program just as responsive as if it was using JPEGS, and cuts the number of files I have to deal with to 1/3 since I don't have to deal with seperate XMP sidecar or JPEG files. I've been really happy having switched.