[Gdal-dev] NITF ICHIPB Extension?

Frank Warmerdam fwarmerdam at gmail.com
Fri Dec 10 12:52:12 EST 2004

On Fri, 10 Dec 2004 12:13:07 -0500, William Lyons
<wlyons at prologic-inc.com> wrote:
> Frank and list, 
> I have discovered that the NITF reader doesn't read image chipping
> information from an NITF file (the ICHIPB TRE).  All it really does is
> supply 4 tie points (usually the centers of the corner pixels but not
> necessarily) from some original image to the data contained in the image
> block.  Folks use the ICHIPB info so they can preserve sensor information
> and RPCs.  Something I've run into using the GDALRPCTransformer is:  When I
> get a pixel and line back from the RPC calculation, it is in reference to
> the original image.  I have changed my local source to read an ICHIPB and
> followed the same paradigm of the RPC information by putting it in the
> nitfdataset's metadata for extraction later.  Let me know if you'd like to
> add it to the baseline. 


I gather the ICHIPB TRE is used when the NITF image is a subset of the
original image to which the RPCs apply?  I'm a bit surprised that it is 
legal to emit original RPCs with a subset image.  I would have expected
the RPC to be transformed.   But given that it doesn't work that way, yes
I would indeed be interested in patches that would apply the ICHIPB. 
Ideally I would like a sample image with ICHIPB as well if possible.

> Given all this, my question is:  How would you go about translating
> coordinates between the two image spaces?  GenImgProjTransformer? 

The GenImgProjTransformer() will use an RPC if there is no geotransform
or GCPs on the source image, but I suspect that isn't your question.
If the first "image" space is an RPC controlled image, what is the second
image?  I believe that the GenImgProjTransformer is currently 
asymmetric, in that it allows the source image to use geotransform, gcps
or RPCs but assumes the target image is strictly geotransform based.  So
you couldn't relate pixel/line locations in two RPC controlled images with
that transformer. Of course, the GenImgProjTransformer isn't really all that
complicated.  You can use it as an example to build a particular transformer
you need yourself. 

PS. I'm also working on the NITF code just now integrating JPEG2000 NITF
writing, so it is a good time to send me patches as I am in the NITF head-space,
scary as that may sound. 

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

More information about the Gdal-dev mailing list