Opened 11 years ago

Closed 11 years ago

#4343 closed defect (fixed)

GDAL incorrectly sets irepband information when saving nitf->nitf

Reported by: jeepingben Owned by: warmerdam
Priority: normal Milestone: 1.9.0
Component: default Version: svn-trunk
Severity: normal Keywords:


I found this while using GDAL to convert from uncompressed NITF to JPEG2000 compressed NITF, but it happens when converting uncompressed nitf to uncompressed nitf as well.

The setting of IREP and IREPBAND seems to be based on a series of special cases and for any case that doesn't match the special case IREP is set to MONO and IREPBAND is set to M for all bands.

The attached file has IREP MULTI and GRBX band-order. If I change the bandorder to RGBX, it works as expected. This was tested using gdal-translate from a recent SVN build.

From the project I am working on, I tried explicitly setting the color interpretation for the bands before writing and it did not help.

Attachments (2)

multi-grbx.r0 (17.1 KB ) - added by jeepingben 11 years ago.
4 band uncompressed nitf, non-rgb band order
irepband_and_isubcat.patch (3.6 KB ) - added by jeepingben 11 years ago.

Download all attachments as: .zip

Change History (8)

by jeepingben, 11 years ago

Attachment: multi-grbx.r0 added

4 band uncompressed nitf, non-rgb band order

comment:1 by Even Rouault, 11 years ago

I somehow manage to get a result close to what you want by using SetColorInterpretation() after creating the file. The only thing you cannot do is write X as a value. However I can imagine that the driver could be easily expanded to write custom value, for example with a new creation option "IREPBAND=val1,val2,...,valN" or implement SetMetadataItem() at the band level so that SetMetadataItem("IREPBAND", "X") works.

from osgeo import gdal

ds = gdal.GetDriverByName('NITF').Create('grbx.ntf', 1, 1, 4)
ds.GetRasterBand(4).SetColorInterpretation(gdal.GCI_Undefined) # write M actually
ds = None

comment:2 by jeepingben, 11 years ago

Thanks for the reply,

I was able to set the color interpretation on the output file, but only when writing uncompressed NITF, if I write a JPEG2000 nitf, I still get 'M' for all IREPBANDs.

Adding a creation option would be very helpful especially for ISUBCAT, currently I see no way to preserve it.

Supporting other values (X, IR, etc) for IREPBAND is not so important.

comment:3 by Even Rouault, 11 years ago

I've successfully managed to adapt the above script to produce a JPEG2000 NITF with B,G,R order... (only tested with trunk)

from osgeo import gdal

ds = gdal.GetDriverByName('NITF').Create('grbx.ntf', 128, 128, 4, options = ['IC=C8'])
ds = None

comment:4 by jeepingben, 11 years ago

I think I figured out why this is working for your script, but not for my program. I'm using createCopy. This means that nitfdataset.cpp:599 is never reached, so bJP2Writing is false. The code at nitfdataset.cpp:136 isn't called and my changes to color interpretation are not saved. I would expect createCopy to get the color interpretation from the source image, or possibly to let me set it.

by jeepingben, 11 years ago

Attachment: irepband_and_isubcat.patch added

comment:5 by jeepingben, 11 years ago

I've attached a patch which allows passing in IREPBAND and ISUBCAT as creation options. It expects a comma separated list of values in band order.

Example: IREPBAND=B ,G ,R ISUBCAT=560 ,480 ,660

comment:6 by Even Rouault, 11 years ago

Milestone: 1.9.0
Resolution: fixed
Status: newclosed

r23491 /trunk/gdal/frmts/nitf/ (frmt_nitf.html nitfdataset.cpp nitffile.c): NITF: add IREPBAND and ISUBCAT creation option (adapted from a patch by jeepingben, #4343)

r23492 /trunk/gdal/frmts/nitf/nitffile.c: Fix previous commit. Max length for ISUBCAT is 6

Note: See TracTickets for help on using tickets.