2006.02.20 07:54 "[Tiff] TIFFReadScanline query", by Benares
2006.02.22 12:45 "Re: [Tiff] TIFFReadScanline query", by Benares
OMG Joris! Immediately after changing my uint32* to uint8* for the line_buffer (as you've pointed out in your last reply), the output.tif image file appeared to be what I've always wanted it to be! Thank you all so much for your most constructive help and suggestions. A million thanks to all the life-savers out there on this mailling list!
Cheers,
Benares ^^
On 2/20/06, Joris <joris.at.lebbeke@skynet.be> wrote:
I can't seem to get my head around why you get the results you do, given the code (and bug) that you've quoted, or not entirely anyway, but maybe that's just lack of caffeïne... In any case, there is a bug in the code you've quoted.
- Your basic problem is that you're not dealing with bytes given to you in line_buffer, but are indexing uint32 values in that buffer instead. So declare line_buffer to be an uint8*, or equivalent (you C guys custom redefining basic types all the time, it's hard to tell how to properly name a simple pointer to a byte). The rest of your code seems designed fine on the condition that you declare line_buffer to be an uint8* instead.
- Allocate only ScanlineSize bytes for line_buffer, not ScanlineSize*sizeof(uint32). (But cure above problem first, or you'll have an access violation on your hands.)
- How can you be sure a<<8<<8 equals (a<<8)<<8? It seems that way, from the results you get, I think, but how you C guys manage to keep track of the priority of your set of thousands of such operations, and know for sure such stuff doesn't instead equal a<<(8<<8) is beyond me.
- As to your input file itself, it's monstorous. The very much invalid flawed content of Kodak DC290 files has been described on the list before (see http://www.asmail.be/msg0054881737.html). I've double-checked, and your input file seems to follow that same layout.