Re: Maker data

Hello, Phil.


21.02.2017 21:29, Phil Harvey пишет:
> 1. The "Maker" string by itself is not useful.  Decoding of maker notes depends not only the maker, but also on the specific camera model, the camera firmware version, and perhaps other information contained in the Exif (such as the Exif byte ordering, which may be different from the maker notes).
Table from exiv2 site (or see 
http://www.ozhiker.com/electronics/pjmt/jpeg_info/makernotes.html ) show 
that if MakerNote of same maker is different it have difference in it's 
own header.
Anyway there is "Source" and "Software" keywords which could help in 
such cases.
> 2. Makernote data may begin with any byte value, not just "II" or "MM", so the eXIf definition of the Mode byte doesn't make sense for the maker notes.
Yes, that was my mistake. I forgot to replace this part after copy from 
eXIf proposal.

Mode: 1 byte

               73: (ASCII "I") uncompressed data, original EXIF was in
                   little-endian ("Intel", LSB first) byte order.

               77: (ASCII "M") uncompressed data, original EXIF was in
                   big-endian ("Motorola", MSB first) byte order.

               105: (ASCII "i") compressed data, original EXIF was in
                   little-endian ("Intel", LSB first) byte order.

               109: (ASCII "m") compressed data, original EXIF was in
                   big-endian ("Motorola", MSB first) byte order.

Compression method: 1 byte
               The only compression method defined for now is 0
               (zlib datastream with deflate compression,
               see PNG specification 10.3: Other uses of compression 
<https://www.w3.org/TR/PNG/#10CompressionOtherUses>).
               For uncompressed data, encoders shall set the compression
               method to 0, and decoders shall ignore it.

> But aside from these minor problems, the biggest issue is with breaking out Exif into separate chunks.  This would impose a significant burden on the encoding software and make preserving the original Exif information very difficult.  On the other hand, existing Exif implementations could easily read/write the eXIf chunk intact (although admittedly makernote data is not handled properly by many implementations).
Well, for now I don't suppose using mKRd for stripping MakerNote from 
EXIF data if EXIF data kept in eXIf chunk.
I suppose using (at least for now) it in scenarios  like:
*recoding software need to modify eXIf chunk and have no possibility to 
keep MakerNote offset (e.g. using external library for 
serialize/de-serialize EXIF).
*writing unsafe-to-copy eXIF chunk (proposal still not accepted, so eXIF 
is not impossible scenario) keep extra copy of MakerNote as mKRd to keep 
it after eXIF-unaware recoding.
*encoder(not from JPEG/TIFF, but from camera) that could save all 
metadata except MakerNote in PNG chunks could get rid of EXIF-handling code.

Beyond Jpeg(TIFF)-to-PNG scenarios extra metadata which usually saved in 
EXIF could be generated by camera or even user. As I wrote before there 
is great amount of metadata that can't be saved in EXIF, so I wish 
someday chunks for keeping this metadata will be designed. Of course 
these new metadata could rely on EXIF metadata and so new chunks should 
include EXIF metadata as well.
Example: EXIF have no information about extension tube, telecompressor, 
telecoverter etc.. only about main lens. But this information is useless 
without information about main lens, so new chunk about all optical 
system should include them all. For some cameras such chunk will make 
eXIf (with just lens information) obsolete, for some - not.

I wrote Maker data concept not to try to replace eXIf with separate 
chunks right now, but to show it's possible someday. And I want to note 
once more: because each new chunk should provide some benefits over EXIF.
mKRd provide very small benefit: allow to keep MakerNote less 
dependent(in theory - independent) on other EXIF. But a journey of 
thousand miles begins with a single step.

> The DNGPrivateData may contain makernotes that are very similar to Exif makernotes, but the DNG specification avoids some of the Exif pitfalls by including an identification string, by specifying that the byte ordering is independent of the containing file, and by madating that offsets are relative to the data start and must not point outside the data.  (Note that the DNG MakerNoteSafety tag is unnecessary because the DNGPrivateData is always safe to copy if these rules are followed.)
That's not very clear:  MakerNoteSafety about EXIF MakerNote (and 
DNGPrivateData always safe to copy) or about DNGPrivateData.

-- 
Pavel Zlatovratskii scondo-JGs/[email protected]; [email protected]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
png-mng-misc mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/png-mng-misc