[gdal-dev] GDAL, Java and UINT16

Even Rouault even.rouault at mines-paris.org
Thu Oct 27 14:56:04 EDT 2011


Le jeudi 27 octobre 2011 20:14:32, Mike O'Malley a écrit :
> Hi-
> 
>    I've built GDAL 1.8.1 on Windows and used SWIG to produce the Java
> bindings.  I've tried to run Worldwind's GDALTest application
> (http://worldwind31.arc.nasa.gov/svn/trunk/GDAL/GDAL-1.7.2/swig/java/app
> s/GDALtest.java) against a known good NITF image, but with no success.
> 
>    Initially, I got an exception because the image's single band is of
> type UINT16, and the Worldwind code didn't have a case for that type.  I
> shoehorned it into the INT16 clause, producing this:
> 
> 
> 
>               else if ((buf_type ==
> gdalconstConstants.GDT_Int16)||(buf_type==gdalconstConstants.GDT_UInt16)
> )
> 
>               {
> 
>                   System.out.println("Int16/Uint16");
> 
>                   short[][] shorts = new short[bandCount][];
> 
>                   for (int i = 0; i < bandCount; i++)
> 
>                   {
> 
>                       shorts[i] = new short[pixels];
> 
>                       bands[i].asShortBuffer().get(shorts[i]);
> 
>                   }
> 
>                   imgBuffer = new DataBufferShort(shorts, pixels);
> 
>                   buffer_type = DataBuffer.TYPE_USHORT;
> 
>                   sampleModel = new BandedSampleModel(buffer_type,
> 
>                       xsize, ysize, xsize, banks, offsets);
> 
>                   data_type = BufferedImage.TYPE_USHORT_GRAY;
> 
>               }
> 
> 
> 
>    I knew it wasn't quite correct, but it turns out that it's not at all
> correct.  The Worldwind function returns a BufferedImage object
> constructed from the NITF file.  Java's ImageIO object refuses to write
> the BufferedImage created for the UINT16 image using the code above.
> There's no exception, the function ImageIO.write() simply returns false
> and no file is created.
> 
>    The problem isn't the image; the GDAL command line applications work
> very well with it, as does FWTools.
> 
>    I don't think this is a Java bindings problem; I just think I'm not
> handling UINT16 images correctly.  Given the difference in sign between
> Java and C, what's the best way to proceed?  There has to be a
> straightforward answer for this, but I can't find it.  The Worldwind
> code handles bytes, signed int16s, and signed int32s.

I'm not familiar with the BufferedImage API, but I can point you to the 
introduction paragraph of http://gdal.org/java/org/gdal/gdal/Band.html

"""
Band objects are returned by methods from other classes, such as 
Dataset.GetRasterBand() Users of the Java bindings must be aware that the Java 
primitive types byte, short, int are signed types, whereas a few GDAL data 
types (GDT_Byte, GDT_UInt16 and GDT_UInt32) are unsigned. To read/write those 
data types, you may have to choose a "larger" type for example 
(short/GDT_Int16 for GDT_Byte, int/GDT_Int32 for GDT_UInt16, 
double/GDT_Float64 for GDT_UInt32), or use some tricks to hold unsigned values 
into signed data type. For example : 
   byte[] byteArray = new byte[xsize * ysize];
   byte[] byteArray2 = new byte[xsize * ysize];
   band.ReadRaster(0, 0, xsize, ysize, gdalconst.GDT_Byte, byteArray);
   for(int j=0; j < ysize; j++)
   {
      for(int i=0; i < xsize; i++)
      {
          byte bVal = byteArray[j*xsize+i]; // ranging from -128 to 127
          int nVal = ((int)bVal) & 0xff; // remapped to range from 0 to 255
          int nVal2;
          if (nVal > threshold)
              nVal2 = 255;
          else
              nVal2 = 0;
          byte bVal2 = (nVal2 > 127) ? nVal2 - 256 : nVal2; // remapped to range from -128 to 127
          byteArray2[j*xsize+i] = bVal2;
      }
   }
   band2.WriteRaster(0, 0, xsize, ysize, gdalconst.GDT_Byte, byteArray2);
 """

I'd note that what you call the Worldwind's GDALTest application is actually 
the GDAL's GDALTest application ;-) I'm not sure how well it works with non-
byte data type.

> 
> 
> 
>    Thanks,
> 
>                 Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20111027/e4e25367/attachment-0001.html


More information about the gdal-dev mailing list