[gdal-dev] 16bit Pixel Arrangement?
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.92W, 18d36'54.78N) Lower Left ( 774731.700, 2046011.700) ( 72d23'53.93W, 18d29'12.10N) Upper Right ( 788966.300, 2060246.300) ( 72d15'41.67W, 18d36'47.89N) Lower Right ( 788966.300, 2046011.700) ( 72d15'49.05W, 18d29' 5.26N) Center ( 781849.000, 2053129.000) ( 72d19'47.89W, 18d33' 0.05N) 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 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? 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. 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? QGIS seems to be able to display the image correctly. Thanks (sorry its a bit waffly) Martin -- View this message in context: http://osgeo-org.1560.x6.nabble.com/16bit-Pixel-Arrangement-tp5166812.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAl no more compiling on Ubunut 12.0.4
Hello everybody. It compiled GDAL on Ubuntu 12.0.4 LTS about 6 months ago. Today I updated the git sources, a new error at the very beginning of compilation stops everything Configure seems to have changed a lot. Any suggestions? Cheers, Rémi-C //error// In file included from cpl_conv.h:35:0, from cpl_conv.cpp:33: cpl_port.h:89:2: error: #error Unexpected value for SIZEOF_INT cpl_port.h:93:2: error: #error Unexpected value for SIZEOF_UNSIGNED_LONG cpl_port.h:97:2: error: #error Unexpected value for SIZEOF_VOIDP ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAl no more compiling on Ubunut 12.0.4
It compiled GDAL on Ubuntu 12.0.4 LTS about 6 months ago. Today I updated the git sources, a new error at the very beginning of compilation stops everything Configure seems to have changed a lot. Any suggestions? I can compile svn trunk on 12.04 as of today. I started with a make clean and then this is my configure: ./configure --with-poppler --with-spatialite=yes --with-java=yes --with-mdb=yes --with-python --with-curl --with-expat --with-libkml make clean might help. There are a lot of different libraries which can be internal or external and many combinations to test so not sure how similar my setup is to yours. Best regards, Eli Cheers, Rémi-C //error// In file included from cpl_conv.h:35:0, from cpl_conv.cpp:33: cpl_port.h:89:2: error: #error Unexpected value for SIZEOF_INT cpl_port.h:93:2: error: #error Unexpected value for SIZEOF_UNSIGNED_LONG cpl_port.h:97:2: error: #error Unexpected value for SIZEOF_VOIDP ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] 16bit Pixel Arrangement?
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.92W, 18d36'54.78N) Lower Left ( 774731.700, 2046011.700) ( 72d23'53.93W, 18d29'12.10N) Upper Right ( 788966.300, 2060246.300) ( 72d15'41.67W, 18d36'47.89N) Lower Right ( 788966.300, 2046011.700) ( 72d15'49.05W, 18d29' 5.26N) Center ( 781849.000, 2053129.000) ( 72d19'47.89W, 18d33' 0.05N) 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
Re: [gdal-dev] 16bit Pixel Arrangement?
Am 10.10.2014 23:27, schrieb Even Rouault: On Friday 10 October 2014 01:12:14 M Lewis wrote: QGIS seems to be able to display the image correctly. As grey level I guess ? And likely after adjusting the min/max values QGIS has support for pseudocolurs from single band. Maybe the author of the data used the same default colour ramp as QGIS does. Greetings, André Joost ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
