Processing DNG

How is a JPEG generated from a DNG image file?

DNG is the standard raw format. I have been using it for many years.

Even though it adds a conversion step, I think it is worthwhile.

I load my camera raw photos onto my machine, convert them to DNG using Adobe’s raw converter, then I delete the original raws.

Like the old 35mm negative film I save DNG files forever so I can make new images and get the best quality output. In the old days you would go to your darkroom or drugstore to have the negative made into a print. This process of enlarging, cropping and color adjustment is called processing or developing the image.

In the digital world JPEG is the like the old print. It is the final result for photos. There are other formats but none come close to JPEGs.

The DNG to JPEG processing step is mostly ignored by the articles on raw and DNG files.

I haven’t thought much about the full ramifications of the processing step until recently even though I have been using DNG for over a decade.

My raw files contain a small preview, I set it to 1024 x 768 to save storage space.

I do not store JPEGs for my raw files. I don’t want to maintain two files for the same image. When I edit the image, it would be a pain to keep the JPEG synced. I would have to come up with a scheme so two duplicate images do not show when viewing among other things.

Instead the raw files are processed on the fly when looking at them. I use an old version of Adobe Bridge as my viewer. The processing takes about two seconds on my machine the first time. After the first time it is fast because the processed data is cached.

I make JPEGs whenever I want to share my images. When posting to my or other websites or when transferring to friends.

In the old days you would write down cropping, sizing and exposure information for the developer to follow.

The equivalent with the digital negative is the embedded raw metadata. It holds the developer information.

The raw pixel data does not change when you edit in Camera Raw or Adobe Lightroom, just the embedded metadata changes. It contains data for the exposure, cropping etc. as text and numbers, for example:

Exposure .90
Cropping 1,2,3,4

There is no standard way to process the DNG to make a JPEG. The software to read the raw pixel data and apply the metadata to process it is proprietary. Adobe does this in their apps like Bridge and Lightroom seamlessly. It is easy to miss this important processing step.

You do notice it if you don’t have any Adobe applications. Try viewing without. For long term storage this is an issue.

There is a great open source command line program called dcraw that can process raw. It is used internally by a lot of apps that say they handle DNG.

Irfan viewer a popular free Windows image viewer uses dcraw. So does ImageMagik, a popular open source image library. Raw editing apps on Linux like Ufraw use it too.

The required processing metadata is documented by the DNG specification but how to interpret it is not specified.

The JPEG you get from dcraw does not look like the JPEG generated by Bridge. The exposure, cropping and rotation specified in the metadata is not honored. There are a lot of parameters to control dcraw, but none that control these options.

ImageMagik supports rotation and cropping, so if you were writing the processing code yourself you could figure out how to do this. At least these two seem straight forward. But what about exposure and shadow adjustment, color and the others? You need to be an imaging processing expert.

Adobe provides an SDK for dealing with DNG . I used it about seven years ago to produce JPEGs. It did not support cropping and rotation then. I’m not sure what it supports now. It was similar to dcraw and it took about the same two seconds to process.

I wonder how the cameras generate their JPEGs? My new camera can take ten frames a second. These frames are made from the raw pixel data. My guess is that the JPEG processing takes place later with a parallel process. I’ve never noticed any delay to the monitor which needs similar processing to create the image shown.

I have been thinking about this because I am writing a photo website to handle my raw workflow.

I was planning to upload my DNGs and generate JPEGs from them as needed on the server running on Linux. There doesn’t seem to be any way to do this without rolling my own code and reverse engineering what Adobe has done. This is more than I want to do.

Google+ and Google Picasa say they support DNG. I not sure whether they do more than dcraw on the processing side.

Flickr doesn’t support DNG. Interesting ideas thread:

flickrideas

You can make edits in Adobe Lightroom and see them in Adobe Photoshop. It gives the illusion that there exists a well known way to process the raw data. Can you make edits in Lightroom and see them in Aperture? Adobe can share the processing software between Adobe apps but do they share this code with other companies?

I found interesting information on Apple Aperture.

https://thephotosexpert.com/forum/raw-vs-dng/8766#.VIJHAAAgLA

From Walter Rowe
http://www.walterrowe.com/

Hi Joseph,

Let me see if I can be more clear.

Yes, Aperture can import a raw file in DNG format. And it knows the camera make and model and provides unique raw file processing based on that information. Aperture also consumes all of the meta data embedded in the DNG file like IPTC, keywords, contact info, ratings, labels, etc. All is well and good on the import side. The export side is where Aperture is incomplete regarding DNG.

Aperture can export a DNG master (eg. “Export master..”), provided it was imported as a DNG. It appears to only spit out the original DNG file you imported and any meta data you have written back to the master DNG file inside Aperture.

There seem to be two things missing from Aperture’s “Export master..” process for DNG files. The first is including an embedded, fully-rendered preview. This is an sRGB JPG that is fully baked with all your Aperture adjustments. Second is all of the adjustment settings themselves. I think Apple could add both of these easily enough if they chose.

The Adobe products include these pieces of data. I can “edit” a DNG in Lightroom, save everything back to the DNG file, open it in Photoshop, and see all of my adjustments from Lightroom. Likewise, I can make adjustments to a DNG file in Adobe Camera Raw, save them, and see these adjustments in Lightroom. And both products will embed the updated, baked preview inside the DNG file.

The embedded preview can be consumed by image management tools like MediaOnePro (formerly iView Media Pro). This frees image mgmt tools from needing to know how to interpret and render raw sensor data from different camera makers, and lets these tools include color-accurate thumbnails and previews in the image management database.

The DNG file format is nice. It retains all of the manufacturer’s original raw file data, can include the original raw file itself, can incorporate a “baked” preview with all your adjustments, can include all of the raw adjustments, and can include all of your meta data. It is a nicely packaged file format with everything you need for long term image management.

It would be nice to see Apple fully support all the features of the DNG file format in the “Export master..” process.

More information about DNG can be found on Adobe’s DNG page.

Does that help?
Walter

From a practical point of view I can get JPEGS by creating them using Adobe apps and uploading them to my website. But this adds manual steps I would rather not have.

What I am beginning to think that the best solution for my website is to change the raw preview setting so the full resolution JPEG is embedded in my DNG files.

When you edit a raw file the preview needs to be updated to match. This is the case with Adobe applications.

I need to figure out an easy way to update all my DNG files to have full resolution previews. Once that is done all my website needs to do is extract the embedded previews.

Words for Rain

They say that Eskimos have a 100 words for snow. As a native of Seattle, I wonder how many words for rain I know. This is the list I came up with.

Rain
Showers
Mist
Drizzle
Downpour
Cloudburst
Sleet
Torrential downpour
Monsoon
Pouring
Cats and dogs
Pineapple Express
Freezing rain
Sprinkle
Liquid sunshine
Deluge
Drencher
Flood
Flurry
Precipitation
Raindrops
Rainfall
Rainstorm
Sheets
Wet weather
Squall

Git Grep and Open File

Git grep is a search command built around the Git ls-files command.

git ls-files | grep -v -f ignore.txt | xargs grep -n

The command line takes all the files checked into version control, strips out the unwanted files, then searches the remaining for a text string or regular expression.

The result is a list of matching lines with their filename and line numbers.

I wrote an Emacs command called slf-git-grep to run it. You select some text then press a key (ctrl+space) to find the selected text in all your source files. It opens a buffer for the results and the matching text is colored red.

This allows you to navigate your source with just a few keystrokes.

If there is no selection, it prompts you for the search string (or regular expression).

It works with multiple repositories on the same machine. Each one has its own results buffer that’s appended to.

The Git root folder is found mostly automatically by searching relative to the current file. If it cannot find it that way, it uses the Git root found last. If it still isn’t found, you are prompt for it.

You may have source checked in that you don’t want to look at. For example third party libs. You can exclude these files using ignore.txt.
The grep command looks for the ignore.txt file in the Git root directory and if not found it looks in your home folder.

The results buffer shows the relative filename and line number. This allows you to go to the found line with one keystoke (ctrl+o). That’s done using another command I wrote called slf-open-file-under-cursor.

slf-open-file-under-cursor is an emacs command which opens the file under the cursor and goes to the specified line number.

The command parses the current line to extract the filename and line number. Then it opens the file and goes to the line.

The command supports common file/line formats generated by grep, a couple stack traces and logging.

Filename is either a full path or a filename relative to the current directory.

Download from github at:

https://github.com/flenniken