RGB Composition Problem(using GDAL Java API to load image to Oracle Spatial GeoRaster object)

[jimmyzhao]

I used GDAL Java API to load image to Oracle Spatial database.After I loaded a GTiff file to GeoRaster database, I used GeoRasterViewer to check the result. I found that the result in GeoRasterViewer has wrong colors, just like painted in red and blue. But I really loaded the three bands into database.The source image is a GTiff file(187M with 3 bands). The version of tools I used is as follows,GDAL--1.8dev-trunk(compiled in VS2008 by myself),JDK--1.6.0u10, Oracle--11gR2. Are these softwares suitable?

I used gdalinfo command line to check detailed information, and reports of source and target image are also attached. I also I found that there was no difference between the two images in meta data, but the values of corresponding pixels in each image were different(See line 18~line 19, line 24~line 25 and line 30~line 31 in "source.txt" and "target.txt" in attachment).

I turned on the show cellValues tool in the georasterviewer to exam the pixels, and choosed different layers for RGB to display the same georaster, but the results showed that the data wasn't loaded into database correctly.(See "source.bmp" and "target.bmp" in attachment, "source.bmp" is the snapshot of the source image in GeoRasterViewer, and "target.bmp" is the snapshot of the target image in GeoRasterViewer). In addition, the program I useded to load data is also attached.

[ilucena]

Jimmy,

The problem should be fixed now.

Code revision: r20412

What was happening is that when GDAL writes to a band composition it not only writes to the output but it also reads it in an attempt to cache the content in memory and speed up the process of interleaving and writing the composition to the output. That is good for a situation when you are updating a band of a pre-existing dataset but in your case all the BLOB are empty at that time.

That wouldn't happen if you program was calling the Writing method with a full block instead of a line as you are doing. What is not wrong at all, please continue to do that and test if everything is working correctly now. GDAL should take care of accumulating the data in memory and it will call the driver to write blocks accordantly without a problem.

Please not that in your code there is a unnecessary and expensive call to the Dataset's FlushCache() method inside the main for-loop. Removing it will represent a significant improvement in performance. I usually prefer to use (Oracle's) NetBeans instead of Eclipse to easily spot those drag code in Java. Just a tip.

Regards,

Ivan

[ilucena]

There is a typo on "Please not that..." That would be "Please note that..." and what I meant by "drag code" is not very friendly way to say "Aha! here is the line that is dragging the performance down". Sorry for any misunderstand.

What I also forget to mentions was that the georaster driver was getting confused with those interchanged reads and write but I hope that will be fixed now.

[ilucena]

Jimmy found a problem and sent this screenshot "result.jpg". The way to replicate it is by using a BLOCKBSIZE=2 for a 3 bands image. That would require a little bit more of "thinking" from the driver.

Comparing the checksum from the input and the loaded GeoRaster shows that band 1 is loading incorrectly.

Note that this problem doesn't happen in a gdal_translate operation, no matter the BLOCKBSIZE and the number of bands.

[ilucena]

Fixed on r20454.

The flag that makes CreateCopy run faster (by not reading before interleaving) wasn't initialized properly.