Add IntergraphDataset::GetInternalHandle, for access to hHeaderOne

[mpd]

We have existing INGR reading that we would like to replace with GDAL INGR reading, but we still need access to the INGR header, for our own nefarious purposes. Adding IntergraphDataset::GetInternalHandle (for hHeaderOne at least) would allow this.

[rouault]

I don't know the official policy of use for GetInternalHandle? but a quick look on GDAL source tree show that this method is rarely used, except for Geotiff and OGDI bridge. I think the encouraged way to do the same thing is to expose metadata, so that people don't have to depend on internal GDAL structures/headers. I suppose you're not interested on all INGR_HeaderOne fields.

[warmerdam]

Martin,

I'm turning this over to Ivan to deal with. As Even mentions, it would be cleaner to expose selected data via metadata (perhaps in a special domain) rather than providing a raw pointer to the internal header. If you can isolate a few data items you need, we could approach it that way. If not, Ivan can modify the code to return the raw HeaderOne? pointer from GetInternalPointer?().

[mpd]

Extra methods are just as easy for me: we'll draw up a list.

[ilucena]

I am sorry I could not understand. Should I wait for a list of items to put in the metadata or should I go ahead and add the GetInternalHandler?()? I can go both ways. I can also implement the option to get HeaderOne? or HeaderTwo? based on the 'Request' parameter of GetInternalHandle?(const char * pszRequest).

[mpd]

On reflection, this request has morphed somewhat... Instead of GetInternalHandle, we'd like two things:

1. 1-bit RLE and CCITT Group 4 images (INGR_Format == 9 && INGR_Format == 24, and any other black and white formats) to be returned as paletted, with two colours in the palette (like TIFF Group 4, for example).

2. More confidence in the handling of TransformationMatrix in hHeaderOne. We have version 2 images that have DGN2IEEEDouble applied to the numbers in the TM, and the results do not seem correct.

[warmerdam]

I will note that treating 1bit black/white images is "normal" in GDAL, and would presumably be appropriate to do in the intergraph driver.

[ilucena]

Martin,

- The black&white colortable should work for CCITT, but I will take a look on the others compressed formats.

- "Version 1 INGR files, and v2 files prior to 1987, use the DEC VAX floating point format and DEC VAX string format. Starting in 1987, v2 was changed to use the IEEE floating point formats and NULL-terminated ASCII strings. Therefore, many v2 files use the older VAX data formats, and many other v2 files use the newer data formats"  http://www.oreilly.com/www/centers/gff/formats/ingr/index.htm.

So I need to find a way to detect if a v2 file is VAX or IEEE.

Can I have a copy of one yours v2 file?

Thanks,

Ivan

[ilucena]

I added B&W color table for RLE Encoded Bitonal;

I fixed a general problem in GetGeoTransform?() - It is not specific to Version 2;

To identify old files version 2 the driver compares the 15th element of the transformation matrix to 1.0 (in IEEE format).

If it is not 1.0 means that the file is version 2-old and the transformation matrix needs VAX/IEEE conversion;

[mpd]

The B&W color table makes all of the files that we have appear as white-on-black instead of black-on-white.

The IEEE change works as expected, thanks.

[ilucena]

CCITT Group 4 compressed file uses B&W color table in a inverse other.

The driver was using that same color table order for Run Length Encode bitonal compressed data by mistake.

That was fixed.

Thanks for point that out and for send your data sample.