HFA driver returns wrong pixel value reading a newly created empty IMAGINE image

[gaopeng]

There are two issues comparing with IMAGINE:

1. A GDAL created empty image (after Create(), but before writing any pixels) conttains valid blocks initialized to 0, while an IMAGINE created image contains invalid blocks. 2. The GDAL HFA driver always initializes an invalid block to 0, while IMAGINE sets an invalid block to NoData? value if given, otherwise to the max value of the pixel type, e.g. 255 for u8, 1 for u1, and etc.

Atatched are two sample images, an 1-bit without NoData?, and an 8-bit with NoData?.

[warmerdam]

Gao,

I'd be ok with altering the HFA driver to return uninitialized blocks as the nodata value if it is defined. But I'm not very comfortable with returning uninitialized blocks as the maximum value the band supports when no nodata value is defined. This would violate a fairly standard assumption of applications for raster files (which is that they are all zero after Create() unless otherwise set).

I will look into making the HFA driver create produce a file with uninitialized blocks instead of zeroed out valid blocks.

[warmerdam]

In trunk (r14731) I have made these changes:

Read invalid blocks as nodata value if available. Create new files with all blocks marked invalid. Support writing to invalid blocks as long as there is already a pointer to valid data.

I have incorporated some minimal testing in hfa_write.py (r14732).

Back porting changes into 1.5.x (r14733).

Gao has indicated the invalid as maxvalue behavior is not required though GDAL will return different values than Imagine does in this case.

[warmerdam]

I have discovered that the proposed changes cause problems when the logvalid flag is set in an order other than from first block to last. This is due to code in HFAField::SetInstValue?() that updates the array/pointer count value whenever a value is set in the array based on the index. This ends up "truncating" the array after a fashion though it can result in other corruption in the file.

I have corrected this in trunk (r14761) and 1.5 branch (r14762) though this is now making me quite nervous since the changes are somewhat risky with regard to side effects.

Some careful testing of HFA support will be needed before 1.5.3 release.