Closed MCA4213 closed 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.
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.
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 .
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: `
` 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.