gwaldron / osgearth

3D Maps for OpenSceneGraph / C++14
https://www.pelicanmapping.com/home-1/opensource
Other
1.5k stars 779 forks source link

Uint16 images can not be loaded in osgEarth (GDAL plugin issue) #755

Closed MCA4213 closed 8 years ago

MCA4213 commented 8 years ago

Hi, This issue that I am writing about is about how osgEarth treat the 16 bits images, the issue can be perhaps repeated with the following: `

LC81220322015227LGN00_B3.TIF

` The image is uploaded on google drive (about 100mb), or you can used any other Landsat band. https://drive.google.com/open?id=0BwUM6S4j6vlXbmNkSFBwaFZ5YWM

The problem happens because the osgEarth use RasterIO with GDT_Bytes for all kinds of images, and this case was mentioned on the GDAL doc that it will cause problem with 16bit images ( the data can not be scaled. From: http://www.gdal.org/gdal_tutorial.html ).

To test what I was saying, I just made a simple modification on the ReaderWriterGDAL.cpp Line 1580 at the: if (!*_options.interpolateImagery() || _options.interpolation() == INTERP_NEAREST) here I remove the code inside the "if" clause and replace it with the code of the next "else", I mean I used the : float color = getInterpolatedValue (bandGray,geoX,geoY,false) / 255 ; In the getInterpolatedValue function, the RasterIO is called with the GDT_Float32 and it is returning a full float value that I divided in this code on 255 to get a 8 bit value.

The result of the test: was an image a little bit darker (my max value was 11000) but with a full detail, that I enhanced after that using the GLSL (stretching).

Recent posts on similar problem in the forum: http://forum.osgearth.org/osgEarth-and-16bit-images-td7589497.html (my post) http://forum.osgearth.org/TIF-image-applied-not-displayed-td7589483.html

Question: I think that not be able to read an uint16 image should be an issue, I didn't give a fix because I can't take all the cases for the different image, and I do not understand all the code in the GDAL plugin, so I wish it can be fixed by a person with knowledge.

Thank you very much.

jasonbeverage commented 8 years ago

Right now the GDAL plugin expects the input data to be scaled to a byte range before osgEarth will render it as a texture. You can use gdal_translate with the -scale option to create a VRT or a Tif with the scale factor applied that you want. I think it would be useful to have more facilities for dealing with multispectral and hyperspectral imagery directly in osgEarth, but it's not in there ATM.

MCA4213 commented 8 years ago

Yes, the GDAL plugins is expecting an auto conversion, but the reality is that the GDAL is not doing that, it can not scale a 16bit image to 8bit image, according to their doc.

Using the gdal_translate will make osgEarth a non-real time rendering toolkit for a large numbers of image, I use it before in my application for viewing images, and I need to wait 1 minutes to get my image converted each time: really a loose of time especially if the image is shared on a small network without any services. Also my tests show that a few modification can be done to the GDAL plugins to allow scaling the image, so we can add an option to activate the scaling without affecting the old system.

I will try to make a fix for that (after a small vacation) then I will share it to discuss, because I don't see a reason to maintain the plugin as it is now (not able to deal with all images), and as I said before osgEarth is a real time rendering engine so it must be able to do this kind of processing on the fly. thank you.

jasonbeverage commented 8 years ago

With gdal_translate you can pass in the -of VRT flag to write out a VRT instead of a tiff. It should be instantaneous since it just writes out an XML file.

osgEarth is definitely a real time rendering engine, but it isn't quite a fully capable multispectral imagery viewer just yet :)

Jason

On Tue, Jul 26, 2016 at 11:09 PM MCA4213 notifications@github.com wrote:

Yes, the GDAL plugins is expecting an auto conversion, but the reality is that the GDAL is not doing that, it can not scale a 16bit image to 8bit image, according to their doc.

Using the gdal_translate will make osgEarth a non-real time rendering toolkit for a large numbers of image, I use it before in my application for viewing images, and I need to wait 1 minutes to get my image converted each time: really a loose of time especially if the image is shared on a small network without any services. Also my tests show that a few modification can be done to the GDAL plugins to allow scaling the image, so we can add an option to activate the scaling without affecting the old system.

I will try to make a fix for that (after a small vacation) then I will share it to discuss, because I don't see a reason to maintain the plugin as it is now (not able to deal with all images), and as I said before osgEarth is a real time rendering engine so it must be able to do this kind of processing on the fly. thank you.

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/gwaldron/osgearth/issues/755#issuecomment-235470482, or mute the thread https://github.com/notifications/unsubscribe-auth/AAT74nOtd5812ZXyRRXvydNqUT5bJ_wpks5qZsvMgaJpZM4JO0Jq .