[gdal-dev] NITF YCbCr To RGB?

Even Rouault even.rouault at spatialys.com
Mon Oct 6 08:39:53 PDT 2014


Le lundi 06 octobre 2014 17:02:51, M Lewis a écrit :
> We have a software component where users can view/zoom/pan different map
> types.
> We use GDAL to read the specific part of the image using RasterIO as raw
> bytes and then convert to a bitmap for display.
> We are now incorporating viewing NITF files and am a little confused in how
> the NITF driver handles YCbCr colour space (which some of the NITFs have).
> I have found these little snippets from Frank that I found in another post
> from 2005:
> 
> /'....Othewise YCbCr images are automatically converted to RGB internally.
> However, even in the (default) case where YCbCr images are converted to RGB
> internally I *think* that the NITFDataset will still return the YCbCr band
> types. This is a bug, and if you want it fixed please file a bug'/
> 
> Also in the NITFDataset code there is a comment:
> 
> / /* FIXME? Does it make sense if the JPEG/JPEG2000 driver decodes */
>                 /* YCbCr data as RGB. We probably don't want to set */
>                 /* the color interpretation as Y, Cb, Cr *//
> 
> Here is a typical gdalinfo dump of a NITF file that I have to deal with:
> 
> Band 1 Block=640x1 Type=Byte, ColorInterp=YCbCr_Y
>   Overviews: 320x240, 160x120
>   Image Structure Metadata:
>     COMPRESSION=JPEG
> Band 2 Block=640x1 Type=Byte, ColorInterp=YCbCr_Cb
>   Overviews: 320x240, 160x120
>   Image Structure Metadata:
>     COMPRESSION=JPEG
> Band 3 Block=640x1 Type=Byte, ColorInterp=YCbCr_Cr
>   Overviews: 320x240, 160x120
>   Image Structure Metadata:
>     COMPRESSION=JPEG
> 
> The question is can it be assumed (based on Franks comments) that in the
> decoding by the JPEG driver that Band 1 has been converted to Red even
> though it states above that the band is YCbCr?

Martin,

Yes, Frank's comment is right. The color interpretation is wrong. It should be 
RGB, since on-the-fly colorspace conversion from YCbCr to RGB has been done.
That should be fixed

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list