[Gdal-dev] Block size consistency (and SetColorInterpretation()
sjahputerao at missouri.edu
Wed Feb 7 11:32:53 EST 2007
You are probably right. I am just trying to rule out any possible
source of image "shift" that I am seeing.
Using RasterIO instead of block write/read seems to increase my
computation time by 40-50%. If I find the source of error to be
something else unrelated to block size, I will go back to using
blockWrite/Read. Still looking now.
Frank, one more thing, when I use "Create()" from "GTiff" driver, I
cannot assign the band name in the new image using :
I always get : ERROR 6: SetColorInterpretation() not supported for
However, the first band in the new image seems to have "gray" as the
band name, while others are "undefined" due to the error above.
But I can do SetColorInterpretation() above if I use "Create()" from
Is this a limitation of GTiff driver in GDAL now? Is there a way I can
assign the band name after using "Create()" from GTiff driver?
Frank Warmerdam wrote:
> Ozy Sjahputera wrote:
>> Thanks, Frank. I was using ReadBlock and WriteBlock using the same
>> Block size obtained from one of the channels (usually channel 1). I
>> found out that my output image from some other bands look funny. So
>> I replaced the block I/O with regular RasterIO. I think my output
>> image is correct now, but the program does run slower with RasterIO.
>> So my hypothesis is .... there is no guarantee that the block size
>> for different bands belonging to the same image will always be
>> identical. I'm glad you confirmed my suspicion.
> I am doubtful that differing block sizes would be your problem since this
> is so rare. But perhaps there was some other issue.
> Do you find things substantially slower with RasterIO()?
> Best regards,
More information about the Gdal-dev