[gdal-dev] RE: Finding Actual Bits Per pixel

[Cole, Derek]

After an afternoon of work - I am able to get the Actual Bits per pixel by getting the metadata, and doing a bunch of string parsing. This is not really that ideal either, so I am still open to suggestions if there is a cleaner way of doing it via the API that I just havent stumbled upon.

Derek
________________________________
From: gdal-dev-bounces at lists.osgeo.org [gdal-dev-bounces at lists.osgeo.org] on behalf of Cole, Derek [dcole at integrity-apps.com]
Sent: Friday, June 10, 2011 4:15 PM
To: gdal-dev at lists.osgeo.org
Subject: [gdal-dev] Finding Actual Bits Per pixel

   Similar to another ongoing thread, I am needing to convert imagery to 8 bit to display in my own viewer.

This has presented me with a few issues. It seems like no matter what of the GDALDataTypes I perform a sizeof() operation on, be it GDT_Byte or GDT_Float32, the size is always 4 bytes.

I am trying to use RasterIO presently to display image. As it turns out, if i run a gdalinfo on the image, i see that it uses uint16 as the Type, but only uses 11 bits per pixel actually!

Since the data types all had a sizeof() = 4, I allocated a float, and I have been reading the data like so

    float * floatData = (float *) CPLMalloc(sizeof(float)*nXSize*nYSize);

    poBand->RasterIO( GF_Read, 0, 0, nXSize, nYSize, floatData, nXSize, nYSize,GDT_Float32, 0, 0 );

This seems to be working presently at getting the data, however, I have to use a scaling function like so:

    float two_eight =  pow(2.0,8);
    float two_eleven = pow(2.0,11);
    for (int i = 0 ; i < imheight ; i++)
    {
         for (int j = 0 ; j < imwidth ; j++)
         {
                floatData[i*imwidth+j] = (two_eight* floatData[i*imwidth+j])/two_eleven;
            }
     }

Which is obviously not ideal, especially when you consider I still have to cast this to unsigned char to be displayed.

My question is - is there a better way to have this conversion done for me? I tried to allocated my data as unsigned char, and read in a GDT_Byte, but the image looked bad. If I continue with this way, is there a way to dynamically figure out the actual bits per pixel from the band? It is not clear to me from the API how this was performed, as it seems like it is buried in the nitf image format code in the example application.

Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110610/513ab69c/attachment.html