Exiv2

Hi Gustavo,

See #574, I suspect this is what's causing the confusion (but would need samples to be sure).

The issue was discussed when Gilles implemented his DNG converter. The conclusion was

>> IMO they make a bad thing worse. I recommend that you boycot it and
>> don't support this tag. Seriously. It is flawed in more than one way.
>
> right. But what can i do with makernote and DNG. i must continue to support
> Exif.Photo.Makernote as well ?

Yes, just write a proper makernote.

[...]
>
> Damned it's the hell... (:=)))
>

Yes, that's why it's easier for me here in Kuala Lumpur to deal with
it - we're already used to the hot climate here :)

Andreas

Damn.... i see the hell as well...
One question, is anyone, any site, any organization, anything out there apart from you both knowing about this "problem"? ;)
Because trying to "boicott" this behaviour is a dead-end if only 2 (now 3) peopele knows about it...

I don't know. There are not many people crazy enough to spend their spare time (and I believe also not many companies paying people to spend time) trying to decode - or worse - encode makernotes. So this call for disobedience doesn't need to reach that many ;)

Andreas

Yeah, i know ;)
My worrie is the posibility of getting a bunch of unuseful files (because of this "unofficial" way of storing exif inside DNG) as the official DNG grows by... or applications rejecting my files cause not being "standard"...
I'will break the meaning of converting to DNG :)

Anyway, i havent studied so deeply the official DNG specifications, so don't know if we are "allowed" to store makernotes this way without breaking compatibility.

How is the approach used by exiftool? It writes it the same way exiv does or the adobe way?

Any Exif reader which knows how to read makernotes should have no problems reading native makernotes in DNG files.
Reading these Adobe makernotes is more difficult though: A reader still needs to be able to read native makernotes, plus it needs to know how to deal with that DNG tag. And extending a reader, which can deal with native makernotes, to also be able to extract them from that DNG tag is not trivial.

AFAICS this standard is meant for applications which can't write makernotes, perhaps not even read them, to allow them to write a DNG file without losing the makernote. But because it's more difficult to read that tag than reading a native makernote, that is of limited use - I would expect very few applications can decode it later.

So applications which can write native makernotes in DNG files, in my opinion should by all means do so, and not resort to that crutch.

For your specific workflow, I would look at it pragmatically and do what works best with the applications that you use. And keep backups of the original RAW files (assuming you have them).

How is the approach used by exiftool? It writes it the same way exiv does or the adobe way?

Give it a try, it would be interesting to know.

Andreas

Well, my workflow, as i intend it to be, is as follows:
1.-Get all my raw files (yeah, the raw, not only the JPGs) tagged/cataloged within digikam.
2.-For those pictures worth the time, edited copies with digikam itself, gimp, maybe lightzone or rawtherapee (tests and time will give me the "one").

It's a simple "workflow" but having raw files in their native orf format, prevents me to fulfill meta information like iptc/xmp using digikam (yeah, i know digikam can handle comments/tags/ratings with every file including raws, but not every other xmp/iptc metadata not being in his database structure).

The way i see it is that all "data" should be associated at first to digital negatives and inherited later to their "manufactured children" (jpgs, pngs, tiffs), so this is where DNG appears to be the "best" solution as digital negative format.

But hey... maybe i'm missing something ;)

Concerning exiftool writing metadata, i did some tests:

1.-Get original file A.orf
2.-Convert to DNG with official Adobe DNG Converter 2 times (B1.dng and B2.dng) to make the tests.
3.-Copy metadata from A.orf to B1.dng with exiftool (-tagsFromFile)
4.-Copy metadata from A.orf to B2.dng with exiv2 (first export to .exv, then write to dng).

Step 1 finished. Results both B1 and B2 are different in size. Now display the info:

5.-Display metadata from B1 and B2 using "exiftool -k -a -u -g1 -w txt". Resulting txt files differs in size and in a lot of contents and/or positions.
6.-Display metadata from B1 and B2 using "exiv2 -pt>file.txt". Resulting txt files differs in size (this time a LOT, cause exiv2 file contained Exif.Image.DNGPrivateData with 2Mb data) and in a lot of contents and/or positions.

Conclussions: i hadn't be able to get conclusions :) There are so many tags, so many data and so many differences i don't know where to start digging ;)

Maybe i need one "god" out there just telling me across the skies "hey you, yo should use This method instead this other", but it won't happen :)

Goose.

I am a bit late to this party, but I thought it would be worthwhile to respond anyway, for the record.

I agree that Adobe's method of reformatting native maker notes when writing to DNG is idiotic. And worse: It is seriously flawed when it comes to Olympus maker notes -- they don't actually parse the Olympus maker notes properly, so information is lost during the conversion. I have talked to a senior developer at Adobe about this, and he has zero sympathy for solving this problem.

ExifTool (and apparently Exiv2) write DNG maker notes in the same location as TIFF and JPEG, which is the only thing that makes sense. Adobe's technique is nonsensical.

- Phil