Exiv2

Hi,

Do you will write an open source DNG conveter or a closed source ?

I'm not starting from scratch but am building on https://github.com/jmue/dngconvert, which I believe is based on your Digikam work.

My goal is just to optimise the code base for my Sony A7's raw files and bring it as close to Adobe's DNG-converter as possible (e.g., decoding the embedded lens profiles, etc). Had only my own use in mind but happy to publish back if anybody is interested.

Thanks for your work btw - wouldn't have been able to start this from scratch! Your old blog-entries were also helpful to get into the topic.

Absolutely. Jens has work on digiKam DNGConverter.

The last code is in kipi tool. Why not to help us to improve this code instead to work on a forked implementation. As I use Sony Camera, i'm interested by this topic...

Gilles Caulier

And to respond to you original question i think yes it's possible. I remember to have played with private TIFF tag in DNGConverter.

Gilles Caulier

Sure. If you're interested in the Sony-format, I have documented my findings on the embedded lens-correction data in 3 postings here: https://variousphotography.wordpress.com/

If anybody could point me to the right entry class to parse the Tiff-file and extract the IFD, would be really helpful. Thanks!

Look in DNG converter core code. It's a low level implementation. You have also a CLI tool to not use GUI :

https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/master/show/dngconverter/dngwriter

In extra sub folder you will found DNG sdk and XMP sdk from Adobe. You can forget these parts. The main class is DNGWriter, and especially here :

https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/master/entry/dngconverter/dngwriter/dngwriter.cpp#L1012

...where Sony markernotes must be migrated from ARW to DNG.

Look also here :

https://projects.kde.org/projects/extragear/graphics/kipi-plugins/repository/revisions/master/entry/dngconverter/dngwriter/dngwriter.cpp#L1055

...where private markernotes TIFF tag is copied from original RAW.

In this code we use KPMetadata class, which is based on libkexiv2, which is a C++ wrapper for Exiv2 library :

https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2/repository

All patches are welcome for DNGWriter

Gilles Caulier

Thanks, I'm reusing that code. My problem is that Sony has proprietary information in 2 places (the MakerNote and another 'SR2'-IFD in the file). Your code copies the MakerNote fine (into the Adobe 'MakN' blob), Adobe's DNG-converter also copies the additional IFD (into an Adobe "SR2 " blob - can also be seen in the DNG SDK - dng_info.cpp). Since, I want to stay close to Adobe's version, I'm trying to add that (you can argue what's the 'right' behaviour, since the DNG-specification doesn't anything about it - but Adobe's process is "standard" when it comes to DNGs).

However, after re-reading the Exiftool (which can read this IFD) code/docs and spending some more time in a hex-editor, I realised that Sony stores the IFD-offset in a non-standard way under the DNGPrivateData tag. To my understanding, Exiv2 can currently not decode that, so will try to develop my own parsing.

Thanks for your help so far!

Thanks, I'm reusing that code. My problem is that Sony has proprietary information in 2 places (the MakerNote and another 'SR2'-IFD in the file). Your code copies the MakerNote fine (into the Adobe 'MakN' blob), Adobe's DNG-converter also copies the >additional IFD (into an Adobe "SR2 " blob - can also be seen in the DNG SDK - dng_info.cpp). Since, I want to stay close to Adobe's version, I'm trying to add that (you can argue what's the 'right' behaviour, since the DNG-specification doesn't anything about it >- but Adobe's process is "standard" when it comes to DNGs).

well, it's a too specifc task for a simple RAW to DNG converter. It out of my mind when i designed this tool.

However, after re-reading the Exiftool (which can read this IFD) code/docs and spending some more time in a hex-editor, I realised that Sony stores the IFD-offset in a non-standard way under the DNGPrivateData tag. To my understanding, Exiv2 can currently >not decode that, so will try to develop my own parsing.

Well, this issue is a specific feature for Exiv2. Or perhaps somebody as Andreas who know better than me Exiv2 code arcane can give some pointer about this problem.

Thanks for your help so far!

In all cases, if you have patch for DNGConverter to improve it, i will be happy to review and include in repository.

Best

Gilles Caulier

Anonymous Poster wrote:

To my understanding, Exiv2 can currently not decode that, so will try to develop my own parsing.

Please contribute your changes back to exiv2 so that everyone can benefit rather then having to re-invent the wheel.

The wiki has details on getting and building the source code: http://dev.exiv2.org/projects/exiv2/wiki

To get started:

  $ svn checkout svn://dev.exiv2.org/svn/trunk 

You are probably best running the latest code from trunk for the type of project you are working on anyway.

Anonymous, how is the parsing going?

Also wondering if you have seen the documentation on TIFF files on the exiv2 wiki?

[[http://dev.exiv2.org/projects/exiv2/wiki/The_Metadata_in_TIFF_files]]

Thanks. Hadn't seen it but I have solved my problem by now with some workarounds.

Basically in Sony ARWs, the DNGPrivateDataTag points to a "SR2"-IFD, containing (amongst other things) offset, length and encryption tags for a SubIFD, which contains the proprietary data I'm after.

I'm reading the SR2-IFD through BasicIO, then create a 'fake' TIFF-header and ending around it, feed the whole thing into TiffParser::decode, extract the relevant tags through ExifData.findKey() and read the final SubIFD again through BasicIO.

Bit complex but works. :-)