[Libexif-devel] Re: MakerNote corrupted... and output file smaller than the input

[Lutz <lu...@us...>]

On Mon, 2003-08-25 at 21:57, Roberto Costa wrote:
> Only two behaviors are acceptable to my eyes for files written by
> libexif:
> a) libexif drops the entire MakerNote entry and warns the user that it
>    has done so;
> b) libexif successfully reproduces MakerNote entry, even without knowin=
g
>    what its contents means.
> I don't like the first, so I'm trying to come out with an idea to get
> the second. I already have something in mind.
>=20
> Suppose that libexif:
> -) builds a sort of map of the apparently unused regions of the exif
>    section of the original file;
> -) keeps all those regions unchanged in the output file (for unchanged =
I
>    mean same values at the same offsets).
> Shouldn't this work out?

(1) (drop): Not very nice.
(2) (keeping memory regions): This could work. You would save an array
of buffers together with the original offsets in the ExifData and try to
rearrange those buffers on exif_data_save_to_data at their original
offsets.=20

I have just (seconds before receiving your e-mail) committed some
changes to libmnote to make it possible to pass EXIF data (instead of
only MakerNote data) to mnote_data_new_from_data. I had in mind that

 - mnote_data_new_from_data reads all interesting bytes into=20
   memory (like libexif does with EXIF data)
 - mnote_data_save_to_data writes all MakerNote data into one ExifEntry.

That is, if you=20
 - read the EXIF data,=20
 - then the MakerNote data,=20
 - save the MakerNote data and=20
 - store the buffer in the corresponding entry in the EXIF data and
 - finally save the EXIF data,=20
this would be like a defragmentation.

But we can do both: Adding an array of memory regions and (optionally)
giving the user the possibility of defragmentation through libmnote.

How about that? Do you have time to work on implementing the detection
of unused buffers?

Regards
--=20
Lutz M=FCller <lu...@us...>