libiptcdata-devel Mailing List for IPTC Metadata Library (Page 2)
Brought to you by:
dmoore
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
(7) |
May
(1) |
Jun
(5) |
Jul
|
Aug
(5) |
Sep
(8) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(2) |
Feb
(1) |
Mar
(4) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2009 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: David M. <dcm@MIT.EDU> - 2005-08-01 05:12:57
|
I have no experience with libiptcdata on Mac OS X, but this looks like a library incompatibility. Perhaps Mac OS X ships with an older version of gettext than is on my system. First of all, try running ./configure with the --with-included-gettext option. Then 'make' and 'make install' again. If that still fails, you might try getting a newer version of gettext for your system. Are there any other Mac OS X users out there who have had success or failure with libiptcdata? -David On Sun, 2005-07-31 at 22:15 +0200, S=E9bastien Maerten wrote: > Well, I have a strange behavior of the iptc tool, here is the sample=20 > output : > $ iptc 2005_0607_203643.jpg > Tag Name Type Size Value > ----- -------------------- --------- ------ ----- > dyld: lazy symbol binding failed: Symbol not found:=20 > _libintl_bind_textdomain_codeset > Referenced from: /usr/local/lib/libiptcdata.0.dylib > Expected in: flat namespace >=20 > dyld: Symbol not found: _libintl_bind_textdomain_codeset > Referenced from: /usr/local/lib/libiptcdata.0.dylib > Expected in: flat namespace >=20 > I'm working on Mac OS X 10.4.2, with minimal changes to the original=20 > environment. libiptcdata was built with default compiler. I'm not a=20 > developper and am quite lost. The iptc tool shows the expected=20 > behavior on another image without any IPTC data, however, the=20 > above-mentionned picture should contain IPTC data (previously set with=20 > the iptc tool). Maybe this is a matter of character encoding (I may=20 > well have tried to set utf-8 IPTC data, not sure), but this is just a=20 > rough gess. >=20 > Any help on what to do would be greatly apreciated. >=20 > BTW : > $ gcc --version > powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc.=20 > build 5026) >=20 > $ iptc --version > iptc 0.1.2 >=20 > I didn't join the offending picture since it's about 2 MB, however, I=20 > can upload it if needed. >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl= ick > _______________________________________________ > Libiptcdata-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libiptcdata-devel |
From: <mae...@la...> - 2005-08-01 00:53:01
|
Well, I have a strange behavior of the iptc tool, here is the sample output : $ iptc 2005_0607_203643.jpg Tag Name Type Size Value ----- -------------------- --------- ------ ----- dyld: lazy symbol binding failed: Symbol not found: _libintl_bind_textdomain_codeset Referenced from: /usr/local/lib/libiptcdata.0.dylib Expected in: flat namespace dyld: Symbol not found: _libintl_bind_textdomain_codeset Referenced from: /usr/local/lib/libiptcdata.0.dylib Expected in: flat namespace I'm working on Mac OS X 10.4.2, with minimal changes to the original environment. libiptcdata was built with default compiler. I'm not a developper and am quite lost. The iptc tool shows the expected behavior on another image without any IPTC data, however, the above-mentionned picture should contain IPTC data (previously set with the iptc tool). Maybe this is a matter of character encoding (I may well have tried to set utf-8 IPTC data, not sure), but this is just a rough gess. Any help on what to do would be greatly apreciated. BTW : $ gcc --version powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc. build 5026) $ iptc --version iptc 0.1.2 I didn't join the offending picture since it's about 2 MB, however, I can upload it if needed. |
From: David M. <dcm@MIT.EDU> - 2005-06-02 18:33:43
|
There is a provision in the IIM spec for additional character sets=20 beyond ASCII. It uses dataset 1:90, in which you can specify escape=20 codes that will be used in future datasets. As best as I can tell, if=20 1:90 contains the three character sequence [ESC]%G then all future=20 datasets will be interpreted as UTF-8. However, I have not seen another application that obeys this rule.=20 Photoshop does not seem to use it. Before I implement it, I'd like to=20 find at least one application that uses it to make sure I am=20 interpreting the spec correctly. Let me know if you find one. -David S=E9bastien Maerten wrote: > Hello, >=20 > I was wondering, while reading the IIMV4.1 how to specify the text =20 > encoding ? How can I decide (using the iptc command line tool) how to =20 > encode the text that is written. > I was thinking of this because, I'm using it where all text is =20 > naturally in UTF-8 format, but after writing (I think) in UTF-8 using =20 > iptc, another software (ill written?) displays "strange characters". =20 > Reading from the same file in an UTF-8 capable terminal gives the righ= t=20 > output though. > So my question is : does iptc specify the text encoding while writing = a=20 > tag, and how does it determine which encoding is used ? >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q= 22005 > _______________________________________________ > Libiptcdata-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libiptcdata-devel |
From: <mae...@la...> - 2005-06-02 09:28:35
|
Hello, I was wondering, while reading the IIMV4.1 how to specify the text encoding ? How can I decide (using the iptc command line tool) how to encode the text that is written. I was thinking of this because, I'm using it where all text is naturally in UTF-8 format, but after writing (I think) in UTF-8 using iptc, another software (ill written?) displays "strange characters". Reading from the same file in an UTF-8 capable terminal gives the right output though. So my question is : does iptc specify the text encoding while writing a tag, and how does it determine which encoding is used ? |
From: <mae...@la...> - 2005-06-01 08:07:39
|
Le 1 juin 05 =E0 06:13, David Moore a =E9crit : > S=E9bastien Maerten wrote: >> Thank you for this iptc utility. > Glad you like it. You reminded me that I need to release version =20 > 0.1.2 which I just did. It includes a windows port and a other few =20= > bug fixes. I'll give it a try, but I don't mind the windows port since I'm using =20= it on Mac OS X ;) > I have never heard any reports of corruption. However, since the =20 > JPEG file format can vary a bit from application to application, =20 > bugs are always possible. To be safe, you can use the -b option to =20= > backup modified files. Glad to know you are confident in the library. I wanted to be sure I =20 can avoid the -b option. Didn't find any corruption here either. >> - could you provide a list of IPTC valid tags name / identifiers =20 >> in the doc ? > Yeah, good idea. I'll work on that. If you like, I can contribute a little text, just let me know. >> - could you add a configure option to disable building the doc =20 >> (on Mac OS X, gtk-doc is a nightmare to build manually) ? > If you are using the CVS version, there is no way to avoid gtk-doc. =20= > However, the .tar.gz package should not require gtk-doc unless you =20 > specify the --enable-gtk-doc option to configure. If this is not =20 > the case, it's a bug -- send me the output from your build and I'll =20= > try to track it down. To be honest, I don't remember if I ran into trouble using the =20 tarball or the cvs version. I'll try with the 0.1.2 version and =20 report any problems here, if any. >> - is it expected behavior that you can add a tag if one such tag =20 >> is already there (at least GraphicConverter does not like that) ? > Yes, this is correct. For example, the "Keywords" tag appears once =20= > for every keyword in the file. It may not be a good idea to do =20 > this with tags such as "Caption", but I figure it's best to leave =20 > such decisions to the user. Most (all) IPTC-aware applications =20 > violating the IPTC specification anyway, so there's not much point =20 > in enforcing it. I presume that the IPTC specification allows multiple same tags, so =20 (I've no time to read it now). Maybe having a command line option to =20 prevent multiple definitions of the same thing (and keep =20 compatibility with ill-written software) would be handy though, since =20= the only one I used (which has been the most used graphic application =20= on macs for ages) "breaks" when following the specs. >> - is it possible to add a kind of --force option so that if I =20 >> want to modify a tag that does not exist, it is created (eg: iptc =20= >> --force --modify=3D"2:120" --value=3D"Created caption if not already = =20 >> there" ? > Yes, perhaps I'll just make that the default behavior. I'm not sure it is better to have it the default, however, having an =20 option is surely handy. Your decision, though. >> - is it possible to add an option --append that would append the =20 >> -- value to the existing tags ? > Yes, that wouldn't be too difficult. I'm waiting for you to implement it ;) > I've added these suggestions to my todo list, so hopefully I'll get =20= > those into the 0.1.3 release. Feel free to ping me in a few weeks =20 > if you haven't seen any updates. Thank you for considering my suggestions, be sure that I'll remind =20 you of your promisses in a few weeks :) One final question : do you have an idea of your audience with this =20 software ? Do you know of any tools using it ? |
From: David M. <dcm@MIT.EDU> - 2005-06-01 04:20:02
|
libiptcdata 0.1.2 has just been released. The changes are as follows: * Added new Visual Studio project and changes necessary to build libiptcdata in Windows. Contributed by Luka Renko. * Be more tolerant of JPEG headers in unexpected orderings. * Improved handling of datasets with zero-length data. The latest version of libiptcdata can be downloaded from the webpage at: http://libiptcdata.sourceforge.net |
From: David M. <dcm@MIT.EDU> - 2005-06-01 04:13:47
|
S=E9bastien Maerten wrote: > Hello, >=20 > This is my first post here. I've recently found your libiptcdata, and = I=20 > appreciate it very much. > Thank you for this iptc utility. Glad you like it. You reminded me that I need to release version 0.1.2=20 which I just did. It includes a windows port and a other few bug fixes. >=20 > I have a few comments / questions though, here they are: > - how much confident are you in your iptc tool ? I have never heard any reports of corruption. However, since the JPEG=20 file format can vary a bit from application to application, bugs are=20 always possible. To be safe, you can use the -b option to backup=20 modified files. Once you are satisified that it doesn't corrupt your=20 files, you can stop using the -b option. > - could you provide a list of IPTC valid tags name / identifiers in =20 > the doc ? Yeah, good idea. I'll work on that. > - could you add a configure option to disable building the doc (on Ma= c=20 > OS X, gtk-doc is a nightmare to build manually) ? If you are using the CVS version, there is no way to avoid gtk-doc.=20 However, the .tar.gz package should not require gtk-doc unless you=20 specify the --enable-gtk-doc option to configure. If this is not the=20 case, it's a bug -- send me the output from your build and I'll try to=20 track it down. > - is it expected behavior that you can add a tag if one such tag is =20 > already there (at least GraphicConverter does not like that) ? Yes, this is correct. For example, the "Keywords" tag appears once for=20 every keyword in the file. It may not be a good idea to do this with=20 tags such as "Caption", but I figure it's best to leave such decisions=20 to the user. Most (all) IPTC-aware applications violating the IPTC=20 specification anyway, so there's not much point in enforcing it. > - is it possible to add a kind of --force option so that if I want to= =20 > modify a tag that does not exist, it is created (eg: iptc --force =20 > --modify=3D"2:120" --value=3D"Created caption if not already there" ? Yes, perhaps I'll just make that the default behavior. > - is it possible to add an option --append that would append the --=20 > value to the existing tags ? >=20 Yes, that wouldn't be too difficult. > I'm sorry not to be able to code this myself, however, I think it coul= d=20 > improve usability of the iptc utility. >=20 I've added these suggestions to my todo list, so hopefully I'll get=20 those into the 0.1.3 release. Feel free to ping me in a few weeks if=20 you haven't seen any updates. Regards, David |
From: <mae...@la...> - 2005-05-31 19:18:54
|
Hello, This is my first post here. I've recently found your libiptcdata, and I appreciate it very much. Thank you for this iptc utility. I have a few comments / questions though, here they are: - how much confident are you in your iptc tool ? - could you provide a list of IPTC valid tags name / identifiers in the doc ? - could you add a configure option to disable building the doc (on Mac OS X, gtk-doc is a nightmare to build manually) ? - is it expected behavior that you can add a tag if one such tag is already there (at least GraphicConverter does not like that) ? - is it possible to add a kind of --force option so that if I want to modify a tag that does not exist, it is created (eg: iptc --force --modify="2:120" --value="Created caption if not already there" ? - is it possible to add an option --append that would append the -- value to the existing tags ? I'm sorry not to be able to code this myself, however, I think it could improve usability of the iptc utility. Feel free to comment, and keep up the good work ! |
From: David M. <dcm@MIT.EDU> - 2005-04-17 04:34:08
|
Luka, Your patch is now applied to the CVS version of libiptcdata. I made a few cosmetic modifications, and have confirmed that it builds properly under Visual Studio for me. iptctool also runs fine. I hope to do a new release of libiptcdata in the next few days that will include all this. Thanks again! -David On Wed, 2005-04-13 at 21:48 -0400, David Moore wrote: > On Thu, 2005-04-14 at 00:47 +0200, Luka Renko wrote: > > I have attached first patch - this adds win directory with appropriate > > files and changes some of the existing code - primerily to fix some > > signed/unsigned warnings (some still left), > > Okay, thanks, I'll get these changes into CVS. > > > There is also win\iptctool directory where I have put a stripped down > > version of your iptc utility - there is no getopt on Windows (at least > > not standard) therefore it is not portable as easily. > > Okay, that should be sufficient since there are numerous windows > programs that can write IPTC data. On Linux, there are very few. > > > This patch also includes a quick solution for 0xdb marker in my JPEG images. > > I just put a fix for this bug into CVS that will skip over all non-APP13 > markers until reaching the image data. > > > It is still only static library as DLL exporting requires changes in > > all headers to add appropriate dllexport defines. We probably need to > > think how can this impact Linux. > > > > Yes, that's true. I suppose we'll just forget about the DLL for now. > This library is so small that a DLL would go against the normal windows > style of keeping most functionality in the monolithic application > anyway. > > -David > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Libiptcdata-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libiptcdata-devel -- -------------------------------------------------------- David Moore <dc...@ac...> http://davemoore.org Computer Science and Artificial Intelligence Lab (CSAIL) Massachusetts Institute of Technology -------------------------------------------------------- |
From: David M. <dcm@MIT.EDU> - 2005-04-14 01:49:17
|
On Thu, 2005-04-14 at 00:47 +0200, Luka Renko wrote: > I have attached first patch - this adds win directory with appropriate > files and changes some of the existing code - primerily to fix some > signed/unsigned warnings (some still left), Okay, thanks, I'll get these changes into CVS. > There is also win\iptctool directory where I have put a stripped down > version of your iptc utility - there is no getopt on Windows (at least > not standard) therefore it is not portable as easily. Okay, that should be sufficient since there are numerous windows programs that can write IPTC data. On Linux, there are very few. > This patch also includes a quick solution for 0xdb marker in my JPEG images. I just put a fix for this bug into CVS that will skip over all non-APP13 markers until reaching the image data. > It is still only static library as DLL exporting requires changes in > all headers to add appropriate dllexport defines. We probably need to > think how can this impact Linux. > Yes, that's true. I suppose we'll just forget about the DLL for now. This library is so small that a DLL would go against the normal windows style of keeping most functionality in the monolithic application anyway. -David |
From: Luka R. <luk...@gm...> - 2005-04-13 22:48:04
|
I have attached first patch - this adds win directory with appropriate files and changes some of the existing code - primerily to fix some signed/unsigned warnings (some still left), There is also win\iptctool directory where I have put a stripped down version of your iptc utility - there is no getopt on Windows (at least not standard) therefore it is not portable as easily. This patch also includes a quick solution for 0xdb marker in my JPEG images= . It is still only static library as DLL exporting requires changes in all headers to add appropriate dllexport defines. We probably need to think how can this impact Linux. Regards, Luka |
From: David M. <dcm@MIT.EDU> - 2005-04-13 21:07:58
|
On Wed, 2005-04-13 at 22:18 +0200, Luka Renko wrote: > OK, that makes sense. I will put all win specific stuff for building > into win and I will also put intermediate/output files there (under > Debug and Release directories). > Yes, sounds good. > Currently there is really not much changes in the code required for > the port, but I will for sure use #ifdef for any OS specific stuff. > > The only thing I am still not sure how to address is the issue of > missing config.h and stdlib.h headers. They are included in more or > less all source files, therefore it does not make sense to #ifdef them > out for WINDOWS. Temporarily I have created empty files + I have put > some stuff for Windows specifics (missing typdefs & defines). I know > that configh is generated by configure script and I suspect the same > is true for stdlib.h. I am thinking of putting also Windows specific > config.h and stdlib.h also in win directory and then fix the include > path in .vcproj to pick them up there. In config.h I would put > #include <windows.h> and us much Windows specifics as possible. > Is this OK with you? > I thought stdlib.h was available under Windows as well. Is it not? Under Linux, it is globally available (not created by configure) and includes definitions for things such as malloc() and free(). If it turns out to be unavailable, I guess an empty stub inside win/ is fine. For config.h and _stdint.h, you'll want to create windows-specific versions inside win/ since configure does generate these two. I think your idea of putting #include <windows.h>, etc. inside the win-specific config.h is a good idea. _stdint.h should simply contain an include of whatever windows system file contains definitions for types uint16_t uint32_t and int32_t (or nothing if those are already globally available). > > > > Once it works, you can send me the whole archive of the libiptcdata/ > > directory, and I'll incorporate the changes into the CVS tree. I do > > have access to a Windows machine with Visual Studio .NET 2003, so I can > > test things too. > > OK. Do you want the whole sources or do you prefer a patch to be > created with "diff"? > diff is fine too, assuming all the Visual Studio project files are text- only. Make sure you use the -u option to diff if you go that route. > > > > By the way, do you compile libiptcdata into a DLL, or just a .lib that > > can be linked with other visual studio projects? > > For quick test I have created a simple static library project, but I > can change it now to real DLL (* .lib for easier linking). We can also > have two .vcproj if you think it is needed... > One vcproj that creates both is probably fine. > > Okay, thanks for the tip. The 0xdb section is the quantization tables. > > I'm surprised it appears before the IPTC data, but now I know. I'll > > incorporate your fix. Also, I'd like to have one of your images too, so > > I can keep it around for future regression testing. > > This is probably depends on the application writing IPTC into Image. I > do not have PhotoShop (too expensive for me), therefore I have used > BreezeBrowser and BreezeBrowser Pro (see www.breezesys.com). > It probably makes sense to make parsing as flexible as possible as I > have heard that different applications are quite different in handling > this. > Yes, I think what I'll do is just read into the image all the way until image data starts rather than just stopping at the first non-APP* section. > I will probaby work on this tommorow and I hope I will have something > to share with you then. Okay, great. Regards, David |
From: Luka R. <luk...@gm...> - 2005-04-13 20:18:29
|
On 4/13/05, David Moore <dc...@mi...> wrote: > Great! I'm surprised it was so easy myself. Good code is portable by definition. ;-) > Yes, I'd like to incorporate it into the next release. Thanks for > offering. I'd suggest this file layout: >=20 > Add a new directory "win" at the top-level. So the distribution would > look like this: >=20 > libiptcdata/win > libiptcdata/iptc > libiptcdata/docs > libiptcdata/libiptcdata > etc. >=20 > Then, inside win/ you would put the .vcproj, .sln, and any other header > files you had to create specifically for windows. Also, if you had to > make any modifications to files outside of win/, make sure to wrap the > changes in an #ifdef WINDOWS. (I imagine you had to do that with i18n.h > for example). OK, that makes sense. I will put all win specific stuff for building into win and I will also put intermediate/output files there (under Debug and Release directories). Currently there is really not much changes in the code required for the port, but I will for sure use #ifdef for any OS specific stuff. The only thing I am still not sure how to address is the issue of missing config.h and stdlib.h headers. They are included in more or less all source files, therefore it does not make sense to #ifdef them out for WINDOWS. Temporarily I have created empty files + I have put some stuff for Windows specifics (missing typdefs & defines). I know that configh is generated by configure script and I suspect the same is true for stdlib.h. I am thinking of putting also Windows specific config.h and stdlib.h also in win directory and then fix the include path in .vcproj to pick them up there. In config.h I would put #include <windows.h> and us much Windows specifics as possible. Is this OK with you? >=20 > Once it works, you can send me the whole archive of the libiptcdata/ > directory, and I'll incorporate the changes into the CVS tree. I do > have access to a Windows machine with Visual Studio .NET 2003, so I can > test things too. OK. Do you want the whole sources or do you prefer a patch to be created with "diff"? >=20 > By the way, do you compile libiptcdata into a DLL, or just a .lib that > can be linked with other visual studio projects? For quick test I have created a simple static library project, but I can change it now to real DLL (* .lib for easier linking). We can also have two .vcproj if you think it is needed... > Okay, thanks for the tip. The 0xdb section is the quantization tables. > I'm surprised it appears before the IPTC data, but now I know. I'll > incorporate your fix. Also, I'd like to have one of your images too, so > I can keep it around for future regression testing. This is probably depends on the application writing IPTC into Image. I do not have PhotoShop (too expensive for me), therefore I have used BreezeBrowser and BreezeBrowser Pro (see www.breezesys.com). It probably makes sense to make parsing as flexible as possible as I have heard that different applications are quite different in handling this. I will probaby work on this tommorow and I hope I will have something to share with you then. Regards, Luka |
From: David M. <dcm@MIT.EDU> - 2005-04-13 15:29:19
|
On Tue, 2005-04-12 at 23:14 +0200, Luka Renko wrote: > As CDS is running on Windows, I first had to compile libiptcdata > library on Windows. I have used MS Visual Studio .NET 2003 and have > created a new .vcproj for it and by my suprise, port to Windows was as > easy as adding empty config.h and a stdint.h file with couple of > defines (like integer types and some GETTEXT stuff). Even more to my > suprise, a quick test for reading just worked on standard JPEG with > IPTC. > Great! I'm surprised it was so easy myself. > I would like to know if you would be interested to incorporate my > Windows port work. In that case I would like to discuss what would be > the most appropriate way of doing this in order not to impact UNIX > platforms too much and clutter directories with Windows specific files > (.vcproj, .sln, config.h). > Yes, I'd like to incorporate it into the next release. Thanks for offering. I'd suggest this file layout: Add a new directory "win" at the top-level. So the distribution would look like this: libiptcdata/win libiptcdata/iptc libiptcdata/docs libiptcdata/libiptcdata etc. Then, inside win/ you would put the .vcproj, .sln, and any other header files you had to create specifically for windows. Also, if you had to make any modifications to files outside of win/, make sure to wrap the changes in an #ifdef WINDOWS. (I imagine you had to do that with i18n.h for example). Once it works, you can send me the whole archive of the libiptcdata/ directory, and I'll incorporate the changes into the CVS tree. I do have access to a Windows machine with Visual Studio .NET 2003, so I can test things too. By the way, do you compile libiptcdata into a DLL, or just a .lib that can be linked with other visual studio projects? > I have also found out that my JPEG pictures from my Canon PowerShot G3 > camera somehow confuse libitpcdata. These images have first EXIF data > (marker 0xe1) and this is followed with marker 0xdb which is not > recognized properly and is not skipped (but prevents further parsing > of the file). This causes libiptcdata to finish parsing before it > reaches IPTC data in the image. > I have done a quick fix in iptc_jpeg_seek_to_ps3() to skip this > similar to other APPx markers and everything works now. I have added > the folowing code: > > else if (buf[i+1] == 0xdb) { > state = IL_JPEG_SKIP_BYTES; > seek = iptc_get_short(buf+i+2, > IPTC_BYTE_ORDER_MOTOROLA); > } > > I did not have time to investigate further what this marker is, but > this quick hack is fine for me for now. If you are interested in some > example pictures I could send them to your private e-mail. > Okay, thanks for the tip. The 0xdb section is the quantization tables. I'm surprised it appears before the IPTC data, but now I know. I'll incorporate your fix. Also, I'd like to have one of your images too, so I can keep it around for future regression testing. > BTW, libiptcdata also works nice on .THM files from my G3: these files > are actualy small JPG files (thumbnails) generated for AVI (movies) > and RAW files in order to store EXIF (and IPTC data) about the > AVI/RAW. > Good, glad to hear it. -David |
From: Luka R. <luk...@gm...> - 2005-04-12 21:15:27
|
I would like to write plug-in for Copernic Desktop Search (www.copernic.com) which would extract IPTC data and publish it to CDS tool for search purposes. I have found that libiptcdata could be a great help in doing this as it provides nice C API for extracting IPTC info from JPG images. As CDS is running on Windows, I first had to compile libiptcdata library on Windows. I have used MS Visual Studio .NET 2003 and have created a new .vcproj for it and by my suprise, port to Windows was as easy as adding empty config.h and a stdint.h file with couple of defines (like integer types and some GETTEXT stuff). Even more to my suprise, a quick test for reading just worked on standard JPEG with IPTC. I would like to know if you would be interested to incorporate my Windows port work. In that case I would like to discuss what would be the most appropriate way of doing this in order not to impact UNIX platforms too much and clutter directories with Windows specific files (.vcproj, .sln, config.h). I have also found out that my JPEG pictures from my Canon PowerShot G3 camera somehow confuse libitpcdata. These images have first EXIF data (marker 0xe1) and this is followed with marker 0xdb which is not recognized properly and is not skipped (but prevents further parsing of the file). This causes libiptcdata to finish parsing before it reaches IPTC data in the image. I have done a quick fix in iptc_jpeg_seek_to_ps3() to skip this similar to other APPx markers and everything works now. I have added the folowing code: else if (buf[i+1] == 0xdb) { state = IL_JPEG_SKIP_BYTES; seek = iptc_get_short(buf+i+2, IPTC_BYTE_ORDER_MOTOROLA); } I did not have time to investigate further what this marker is, but this quick hack is fine for me for now. If you are interested in some example pictures I could send them to your private e-mail. BTW, libiptcdata also works nice on .THM files from my G3: these files are actualy small JPG files (thumbnails) generated for AVI (movies) and RAW files in order to store EXIF (and IPTC data) about the AVI/RAW. Regards, Luka P.S. I would like to thank you for nice, readable code which just works! |
From: David M. <dc...@ac...> - 2005-03-07 06:34:13
|
libiptcdata 0.1.1 has just been released. The changes are as follows: * Added date/time manipulation functions iptc_dataset_get_date(), iptc_dataset_get_time(), iptc_dataset_set_date(), and iptc_dataset_set_time(). * Fixed parsing error for some jpeg files. The latest version of libiptcdata can be downloaded from the webpage at: http://libiptcdata.sourceforge.net |