LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 2006
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2006.08.04 17:40 "Re: newbiequestion: [?] backup complete ifd > private ifd", by Bernie Pallek
Karin wrote: > i want to backup the ifd[0] >one< time and just leave it in > what ever position in the file. since ifd[0] does not have > any pointers to the backuped ifd[1], there shouldn't be any > problems with the file, because ifd[1] is just a chunk > of data. am i right with that assumption? Yep, at this point, I'd say you can fairly easily do what you're after, but you must realize that the files you produce will not be true TIFFs (because they will have "junk" at the end that's usually ignored by readers, but if a reader is snoopy, it might complain (justifiably so) that there are data that shouldn't be there). I guess you're tired of hearing this... :-> > with every loading-function (in the to-be-programmed app) i > want compare >every< (numerical) value of ifd[0] and the > backup ifd[1]. if >anything< is different (e.g. a single bit), > i want to copy the values of ifd[1] to ifd[0]. [...] > i have to admit: it was mentioned and i know, thet i >can< > somehow copy the > ifd, but i still couldn't figue aut >how<. (sorry... newbie) Well, the offset of IFD[0] is stored at offset 4 in the TIFF file; then, the size of the IFD is calculable by reading its number of entries, multiplying by the size of each entry (12 bytes), and adding 2 bytes for the directory entry count value (16-bit), and 4 bytes for the "next IFD offset" (I recommend you to double-check my calculations against the spec). Now you have the start location and size of IFD[0] -- read this chunk of bytes from the file into a buffer; now you have a copy. Seek to the end of the file, opened in binary-append mode, and write the buffer at the end of the file. Finally, write a word (let's go with 16-bit for the purposes of this explanation), equal to the size, in bytes, of the IFD (let's refer to this as 'copysize'). Now you have a copy of IFD[0] at the "end" of the TIFF. How do you read the buffer back? Well, assuming you're not doing any other tricky stuff :-), you can seek to the end of the file, minus the size of 'copysize' (2 bytes), and read the value (16-bit word). This value will tell you how many more bytes to seek backwards, in order to read the cloned IFD. When doing your "integrity check", you can calculate the size of IFD[0], read back your 'copysize' value, and compare the two -- if sizes match, it's time for binary comparison (byte-by-byte). Your cause will be helped by TIFFCurrentDirOffset(TIFF* tif) -- to get the location of IFD[0]. I think you'll need to implement your own "calculate_IFD0_size" function. > [4] > what i want to know about ifd[0] (and copy to ifd[1]) is > something like this > (copied elsewhere): > > 00000008 : 00 10 number of tags : 16 > > 0000000A : 00 FF 00 03 00 00 00 01 00 01 00 00 whatever_tag[1] > 00000016 : 01 00 00 04 00 00 00 01 00 00 02 40 whatever_tag[2] [...] > it would be nice, if i could manage to get and compare > >something< like a > plain string of the bytes in the ifd: > > 001000FF00030000000100010000 ... ... 00000000 > > (something like the tiffinfo -d option, only for the directory.) Unless you need to know exactly which values have been changed, and to what, this might be a lot of unnecessary effort.