[2009-04-10 16:46:08] hi FrankW [2009-04-10 16:46:25] i've just a little question to you :-/ [2009-04-10 16:46:40] maybe OT on qgis, so i used provate message [2009-04-10 16:46:51] sure, fire away [2009-04-10 16:47:08] i'm tring to learn more about the ossim_gdal_plugin [2009-04-10 16:47:16] are you familiar with it ? [2009-04-10 16:47:38] the problem you expose me the last time was related to the color table [2009-04-10 16:47:40] I had done some work on it at one time. [2009-04-10 16:47:55] the gdal plugin probably only recognizes 8 bit pseudo color data [2009-04-10 16:48:12] but if gdal can read it try translating to 3 band tiff then planet could read it [2009-04-10 16:48:59] Potentially the GDAL pct2rgb.py script could be used to convert to an RGB file. [2009-04-10 16:49:13] But I'm not even positive that supports more than 8bit images! [2009-04-10 16:49:32] Ultimately though I imagine bulk translation would not be the desired approach. [2009-04-10 16:50:07] yes it is ... beacose it implies a data duplication [2009-04-10 16:50:12] i think ... [2009-04-10 16:50:29] You *want* data duplication? [2009-04-10 16:50:35] no [2009-04-10 16:50:47] i prefer to avoid data duplication [2009-04-10 16:51:19] ah, that was what I expected. [2009-04-10 16:51:34] beacouse my targhet is to read grass data directly [2009-04-10 16:51:44] Understood. [2009-04-10 16:51:59] The comment "yes it is" in reply to my suggesting bulk translation was not desirable confused me. [2009-04-10 16:52:30] ahhh ... my poor english sorry :-( [2009-04-10 16:52:37] It may be that the ossimGdalTileSource::loadIndexTo3BandTile method could be updated to support non-8bit data. [2009-04-10 16:53:08] I'm looking at OSSIM code from mid-2006 I happen to have sitting around, but I agree that this code is 8bit oriented, but it seems like it could be correctedly reasonably easily. [2009-04-10 16:53:18] do you have "under hand" the ossim_plugin_source code ? [2009-04-10 16:53:23] ok [2009-04-10 16:53:57] What happens when you load your non-8bit image by the way? A crash? An exception? A runtime error? Or just the wrong visual results? [2009-04-10 16:54:10] no, it load the data [2009-04-10 16:54:21] recognize the right projection too [2009-04-10 16:54:31] but it iis sympli no "rendered" [2009-04-10 16:54:58] i can have a black image or a "band series" [2009-04-10 16:55:37] like the image is composed by different coloured strip [2009-04-10 16:55:56] i can produce a scrrenshot [2009-04-10 16:58:30] these is a screen in imagelinker for the elevation.10m from the spearfish dataset :http://www.geofemengineering.it/data/elevation.10m.png [2009-04-10 17:00:24] while the slope : http://www.geofemengineering.it/data/slope.png is rendered [2009-04-10 17:01:28] FrankW: these the link : http://www.geofemengineering.it/data/elevation.10m.png [2009-04-10 17:01:32] I was able to look at the slope.png [2009-04-10 17:01:48] can you see it ? [2009-04-10 17:01:54] the elevation.10m [2009-04-10 17:02:11] Based on the screen shot of the elevation (I see it now), I believe a 16 or 32bit buffer is just being directly intepreted as 8bit. [2009-04-10 17:02:44] This reassures me that it may be easy to modify loadIndexTo3BandTile() to support non-eight bit imagery. [2009-04-10 17:03:48] ohh :-) i haven't knowledge about cpp/c code, but if you pooint me on the right source ... i'l try to read and learn a bit from the source file [2009-04-10 17:04:18] so i need to point my attention on : ossimGdalTileSource.cpp .h [2009-04-10 17:04:26] ? [2009-04-10 17:04:30] yes [2009-04-10 17:05:12] http://trac.osgeo.org/ossim/browser/trunk/ossim_plugins/gdal/ossimGdalTileSource.cpp#L1516 [2009-04-10 17:05:35] The core problem is that the result of getBuf() is cast to ossim_uint8* without regard to the true type of the buffer. [2009-04-10 17:06:03] I believe the code needs to be modified to handle three cases - 8bit, 16bit and 32bit integers and to error out gracefully if it isn't one of those cases. [2009-04-10 17:06:45] Down at line 1567 where the s[sample] value it fetched from the input buffer this would need to be altered to fetch it based on the type of the buffer. [2009-04-10 17:07:23] The GDALGetColorEntryAsRGB() already supports non-eight bit palette entries so that aspect should not be a problem. [2009-04-10 17:08:11] huhh i'm reading .. and follow you :-) [2009-04-10 17:09:44] each word is for me a great hand, thanks [2009-04-10 17:09:49] right now i haven't the nedeed knowledge to undstoand ... [2009-04-10 17:10:01] but i can document all, reading more .. and try to send a relative mail/irc to the ossimpanet dev-team [2009-04-10 17:10:28] sounds good - those guys should have no problem helping with the code changes. I'm glad to answer further questions too. [2009-04-10 17:11:16] maybe that's what i can do actually, yes nhv gpots gived me a great help and like you ar so kind [2009-04-10 17:11:49] Just now however I need to drive my daughter somewhere ... later! [2009-04-10 17:11:59] i'll try to documnet all , done screenshot and the relative gdalinfo information [2009-04-10 17:12:11] thanks !!! see you at the next time :-)