[Gdal-dev] Block size consistency (and SetColorInterpretation() in GTiff)

[Ozy Sjahputera]

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 :         
dstBand->SetColorInterpretation(srcBand->GetColorInterpretation());
I always get :    ERROR 6: SetColorInterpretation() not supported for 
this dataset. 
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 
"MEM" driver. 

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?

Thanks

Oz

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.
>
> Ozy,
>
> 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,