Re: [Libiptcdata-devel] Problem with Nikon pictures

[Michael D. <mic...@ya...>]

I believe the problem is with the stdint.h file that is currently used in t=
he Windows build of the library.  I don't think it's compatible with newer =
versions of Visual Studio.  The example below seems to work nicely, and the=
 errors no longer occur.=0A=0Ahttp://msinttypes.googlecode.com/svn/trunk/st=
dint.h=0A=0AMike=0A=0A----- Forwarded Message ----=0AFrom: Michael Dillon =
=0ATo: David Moore <dc...@MI...>=0ASent: Sunday, January 28, 2007 9:16:27 P=
M=0ASubject: Re: [Libiptcdata-devel] Problem with Nikon pictures=0A=0AHi Da=
vid,=0A=0AI'm still getting familiar with the code, and I haven't had to di=
ve this deep into JPEGs in quite a while, so please bear with me! =0A=0AI c=
ompared things in CVS, and the critical code appear to be identical.  So, I=
'm just going to use the packaged download that's on=0A SourceForge.=0A=0AW=
hen using the D200 sample image, I make a call to iptc_jpeg_save_with_ps3()=
.  In that routine, the call to iptc_jpeg_seek_to_ps3() is returning -1.=0A=
=0AWhen I dig deeper into iptc_jpeg_seek_to_ps3(), the first call to iptc_g=
et_short() returns a fairly large negative number (-26980).  This eventuall=
y makes 'i' a negative number. The while() loop tries a couple more times, =
and returns -1 when buf[i] !=3D JPEG_MARKER.=0A=0ATracing down to=0A the bo=
ttom into iptc_get_sshort(), the IptcByteOrder is passed in as IPTC_BYTE_OR=
DER_MOTOROLA, and the buffer that is passed in contains:=0A=0A0x96,0x9c,E,x=
,i,f (and so on)=0A=0ASo, =0A=0A((buf[0] << 8) | buf[1])=0A=0Ais returned t=
o iptc_get_short() and then applied with a bitwise '&' against 0xffff to ge=
t the negative which seems to throw things off...=0A=0AAny ideas?=0A=0AMike=
=0A=0A----- Original Message ----=0AFrom: David Moore <dc...@MI...>=0ATo: M=
ichael Dillon =0ACc: lib...@li...=0ASent: Sunday=
, January 28, 2007 3:45:06 PM=0ASubject: Re: [Libiptcdata-devel] Problem wi=
th Nikon pictures=0A=0AI just tried modifying your Nikon_D200.jpg on my Lin=
ux machine, and it=0Aworked fine.  I'm using the latest CVS version of libi=
ptcdata, so could=0Ayou give that a try also?=0A=0AIf that=0A still doesn't=
 work, this is probably a Windows-only bug.  If=0Ayou're willing, I'd reall=
y appreciate it if you could track it down in=0Athe code since I don't have=
 access to a Windows machine.=0A=0AThanks,=0A=0ADavid=0A=0AOn Sun, 2007-01-=
28 at 14:29 -0800, Michael Dillon wrote:=0A> Hello,=0A> =0A> I'm encounteri=
ng a problem with writing IPTC to pictures from Nikon=0A> cameras.  =0A> =
=0A> The details:=0A> =0A> I'm using the windows port of version 0.2.1.=0A>=
 If I attempt operations on any Nikon images (from D200, D80, or 970=0A> mo=
dels) I'm unable to write any data.=0A> If I use the iptctool on the images=
 to read them, it crashes.=0A> In the debugger, iptc_jpeg_read_ps3() return=
s a massive value, almost=0A> the size of the entire image.=0A> When I call=
 iptc_jpeg_save_with_ps3(), it always returns -1.=0A> If I use Irfanview to=
 save some IPTC data, then the library works fine=0A> on=0A the picture.=0A=
> My code seems to work fine for other images, but not Nikon...=0A> =0A> So=
me sample images can be found here:=0A> =0A> http://www.fileshack.us/v/4494=
380/Nikon_D200.jpg.html=0A> http://www.fileshack.us/v/1295234/Nikon_D70.JPG=
.html=0A> http://www.fileshack.us/v/1763376/Nikon_D80.JPG.html=0A> =0A> Doe=
s anyone have a suggested fix or workaround for this?   I haven't=0A> start=
ed to dig into the library code yet...=0A> =0A> Mike=0A=0A=0A=0A=0A=0A=0A=
=0A=0A=0A=0A