[gdal-dev] 16bit Pixel Arrangement?

[Even Rouault]

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