I found out that libgfl (and XNView) often do not process IPTC "correctly", while other programs (tested eg. with IrfanView) do.
I furthermore was able to read it using my own code.
Dont know it it is a bug or simply too "strict" parse-code...
Result is always that the gfl-functions return: No IPTC data found.
Here is the APP13 block of a jpeg where I encountered this behaviour.
Im sorry, but I cannot post the whole image due to legal reasons
My parse tree (which I got from my own parse-code):
Just wanted to file this report and let you know about ...
I thought its maybe related to other implementations I saw when I did the research for my own code.
PHP eg. has the following header string in ext/standard/iptc.c (but doesnt check it when simply parsing a block):
Code: Select all
static char psheader = "\xFF\xED\0\0Photoshop 3.0\08BIM\x04\x04\0\0\0\0";
Im not sure if I remember it right, but was there another length desciptor behind that header? Think I read something about.
This might be another problem and furthermore checking this isnt really necessary if you parse by checking of 0x1C markers.
BTW: Do you have a good link for IPTC section meanings (like 2#120 is Caption)?