Re: [Pmt-exif] HEX syntax

[Glenn Randers-P. <gl...@ho...>]

At 08:12 PM 8/8/00 +0000, Adam M. Costello wrote:

>HEX is used only for the MakerNote subkeyword.  If the encoder does not
>understand the layout of the data, then it cannot convert the byte order
>of the subfields.  But if it does understand the layout, why stop at
>fixing the byte order?  Why not convert it to a human-readable form like
>all the other data in the textExif chunk?

It's not the encoder that has a problem; it's the decoder that would not
know how to convert that human-readable stuff back to a proper Makernote.

In fact I am proposing that some of the interesting fields in the
Makernote also be converted to human-readable form, for example Digital
Zoom which I already show in draft 0.14, and panorama data, which I think
is also a good candidate.  But those will also have to be retained in the
HEX-coded Makernote for potential reconversion to camera format.

>Another possibility is to put the information in the HEX value itself:
>
>MakerNote=M 04B129C6
>MakerNote=I C629B104
>
>(I took the M/I convention from TIFF.)

Yes, something like that had occurred to me as well, but I was thinking
of B/L/U/N as the flag (Big/Little/Unknown/NotApplicable).  Apps that
convert from camera format to PNG would be required to retain the
camera's byte order and write the proper flag, if known.  This way,
apps that convert back to camera format wouldn't have to do any byte
swapping.  Converting to camera format for loading into a *different*
camera would be interesting; the app would either need to be able to
reconstruct the second camera's Makernote or just discard the stored
Makernote.  I don't know enough about digital cameras to know how
well that would work.  What happens now if you simply upload an Exif
file from one camera into a different brand?

Glenn