From: Hubert F. <hfi...@te...> - 2006-01-25 03:20:25
Attachments:
tiff_support.diff
|
Hi, Here is a patch I had around for almost 6 monthes: I have implemented TIFF support for libexif, and I have also sanitized the exif_data_save_data() to save pure EXIF data. exif_data_save_data() is being renamed to exif_data_save_data_jpeg() and exif_data_save_data_raw() implements the same without the "Exif\0" marker for JPEG chunks. exif_data_sava_data() still behave as previously, but is marked as deprecated. For compatibility only. I have changed the .so version consequently. If someone can review it, but please don't commit it. I'll do IT myself with the appropriate ChangeLog if it is OK. Thanks. Hub |
From: Lutz <lu...@to...> - 2006-01-25 07:34:34
|
On Tue, 2006-01-24 at 22:20 -0500, Hubert Figuiere wrote: > If someone can review it, but please don't commit it. I'll do IT myself=20 > with the appropriate ChangeLog if it is OK. I'd prefer another option EXIF_DATA_OPTION_INCLUDING_JPEG_HEADER (or similar name) that is set by default. That way, the API remains more compact. The exif loader can set the flag according to the data it got. No need for frontends to call an additional function then. Regards --=20 Lutz M=FCller <lu...@to...> |
From: Hubert F. <hfi...@te...> - 2006-01-25 14:59:40
|
Lutz M=FCller wrote: > On Tue, 2006-01-24 at 22:20 -0500, Hubert Figuiere wrote: > >>If someone can review it, but please don't commit it. I'll do IT mysel= f >>with the appropriate ChangeLog if it is OK. > > > I'd prefer another option EXIF_DATA_OPTION_INCLUDING_JPEG_HEADER (or > similar name) that is set by default. That way, the API remains more > compact. OK. But it brings a bit more complexity IMHO > The exif loader can set the flag according to the data it got. > No need for frontends to call an additional function then. Set the output automatically, I don't think that is a good idea as I know some people already work around that problem. That would break the = API. Hub |
From: Lutz <lu...@to...> - 2006-01-25 21:29:28
|
On Wed, 2006-01-25 at 10:03 -0500, Hubert Figuiere wrote: > > I'd prefer another option EXIF_DATA_OPTION_INCLUDING_JPEG_HEADER (or > > similar name) that is set by default. That way, the API remains more > > compact. >=20 > OK. But it brings a bit more complexity IMHO No complexity in the code: void exif_data_save_data ()=20 { if (option & INCLUDING_JPEG_HEADER) _exif_data_save_data (..., 1) else _exif_data_save_data (..., 0) } Complexity in the API? I don't think so. > > The exif loader can set the flag according to the data it got. > > No need for frontends to call an additional function then. >=20 > Set the output automatically, I don't think that is a good idea as I=20 > know some people already work around that problem. That would break the A= PI. Agreed. --=20 Lutz M=FCller <lu...@to...> |
From: Hubert F. <hfi...@te...> - 2006-01-26 02:16:50
|
Lutz M=FCller wrote: > On Wed, 2006-01-25 at 10:03 -0500, Hubert Figuiere wrote: >>> I'd prefer another option EXIF_DATA_OPTION_INCLUDING_JPEG_HEADER (or >>> similar name) that is set by default. That way, the API remains more >>> compact. >> OK. But it brings a bit more complexity IMHO >=20 > No complexity in the code: >=20 Not the code, but API use. I'll do that anyway. Hub |
From: Jan P. <pa...@pi...> - 2006-01-25 16:26:42
|
Hi Hub, none of the 3 supported maker note types gets loaded. I guess you need to subtract those 6 bytes also in all maker note files... --- Jan > Here is a patch I had around for almost 6 monthes: > > I have implemented TIFF support for libexif, and I have also sanitized > the exif_data_save_data() to save pure EXIF data. > exif_data_save_data() is being renamed to exif_data_save_data_jpeg() and > exif_data_save_data_raw() implements the same without the "Exif\0" > marker for JPEG chunks. > exif_data_sava_data() still behave as previously, but is marked as > deprecated. For compatibility only. I have changed the .so version > consequently. > > If someone can review it, but please don't commit it. I'll do IT myself > with the appropriate ChangeLog if it is OK. > > Thanks. > > Hub |
From: Hubert F. <hfi...@te...> - 2006-01-26 02:17:23
|
Jan Patera wrote: > Hi Hub, > > none of the 3 supported maker note types gets loaded. I guess you need > to subtract those 6 bytes also in all maker note files... uh oh, thanks. I'll look into it. Hub |
From: Jan P. <pa...@pi...> - 2006-01-25 16:49:52
|
Aha, I now see how it works for TIFFs: 1) exif_loader_write_file() loads 1024 bytes 2) exif_loader_write() stores first 1012 bytes of them (because of "eld->size = len;" just after "eld->data_format = EL_DATA_FORMAT_TIFF;") 3) exif_loader_write_file stops reading. Then those 1012 are assumed to be EXIF data. Consequences: a) It doesn't read real EXIF tag, but primary TIFF IFD b) It is assumed EXIF is at the beginning of the file c) it is assumed the IFD has at most 1012 bytes I know dealing with TIFF/EXIF isn't easy e.g. because EXIF data can be located anywhere in the file, but I just wanted to be sure this is what you intended.... -- Jan > Hi, > > Here is a patch I had around for almost 6 monthes: > > I have implemented TIFF support for libexif, and I have also sanitized > the exif_data_save_data() to save pure EXIF data. > exif_data_save_data() is being renamed to exif_data_save_data_jpeg() and > exif_data_save_data_raw() implements the same without the "Exif\0" > marker for JPEG chunks. > exif_data_sava_data() still behave as previously, but is marked as > deprecated. For compatibility only. I have changed the .so version > consequently. > > If someone can review it, but please don't commit it. I'll do IT myself > with the appropriate ChangeLog if it is OK. > > Thanks. > > Hub |