On Friday 10 October 2014 01:12:14 M Lewis wrote: > I am trying to read a NITF image that has a single band with a data type of > UInt16 and a ColorInterp of 'Undefined' as show below in some details taken > from the gdalinfo dump: > > NITF_IMODE=B > NITF_IREP=MONO > NITF_ISCLAS=U > NITF_OSTAID=DG > NITF_PJUST=R > NITF_PVTYPE=INT > Corner Coordinates: > Upper Left ( 774731.700, 2060246.300) ( 72d23'46.92"W, 18d36'54.78"N) > Lower Left ( 774731.700, 2046011.700) ( 72d23'53.93"W, 18d29'12.10"N) > Upper Right ( 788966.300, 2060246.300) ( 72d15'41.67"W, 18d36'47.89"N) > Lower Right ( 788966.300, 2046011.700) ( 72d15'49.05"W, 18d29' 5.26"N) > Center ( 781849.000, 2053129.000) ( 72d19'47.89"W, 18d33' 0.05"N) > Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Undefined > > I am trying to create a corresponding 16bit bitmap for display but having > trouble as it appears this is a mono image but its coming out 'blue/green' > so it appears a shift somewhere in the pixel data
Martin, this does not make sense to me. If it is a single band dataset, the best you can do is display it in grey levels. You will never have colours from that, unless you apply some color table with other means. > > Can any one tell me, for a UInt16, what is the likely pixel data arrangement > that is returned in the RasterIO call as 'Undefined' doesn't help much i.e: > > Is it 5 bits for R, 5 for B etc? > If it is, is it ABGR or RGBA? > Or is it none of the above and something else? That would be extremely odd to pack color components within uint16. Well, I known this is done in OpenGL textures, but I've never seen that trick in GIS format ;-) > Should there be any further clues in the NITF metadata? > > I have looked at the bytes coming back from the RasterIO call and they make > little sense; all the bottom bits are loaded and the top 5 bits 0 but for a > mono image I would expect a more even pattern of bits set across all the 16 > bits. It is very common to have 12 bit imagery. And where each 12 bit sample is placed in a 16 bit container. Check if there's not a NITF_ABPP metadata item (ABPP = Actual Bit Per Pixel). That would give you the real dynamics of the values. Otherwise just do "gdalinfo -stats the.nitf" and look at the minimum and maximum values. You can try the -scale option of gdal_translate to for example convert to 8 bit depth. > > I have simplified the call to RasterIO using the following parameters: > > eBufType = GDT_UInt16 > nBandCount = 1 > pBandMap = NULL - so it reads just the first band > nPixelSpace = 0 > nLineSpace = 0 > nBandSpace = 0 > > For other things e.g. YCbCR, I understand that RasterIO does some > translation to RGB, is that what is going on here? If it is, what is the > translation likely to produce? In your case, no translation will be done, since there's apparently nothing to convert. > > QGIS seems to be able to display the image correctly. > As grey level I guess ? And likely after adjusting the min/max values Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev