Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2427 closed defect (fixed)

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

Reported by: gaopeng Owned by: warmerdam
Priority: normal Milestone: 1.5.3
Component: GDAL_Raster Version: 1.5.2
Severity: normal Keywords: HFA
Cc:

Description

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?.

Attachments (2)

bit1.img (21.2 KB) - added by gaopeng 11 years ago.
bit8.img (8.8 KB) - added by gaopeng 11 years ago.

Download all attachments as: .zip

Change History (6)

Changed 11 years ago by gaopeng

Attachment: bit1.img added

Changed 11 years ago by gaopeng

Attachment: bit8.img added

comment:1 Changed 11 years ago by gaopeng

Summary: Returns wrong pixel value reading a newly created empty IMAGINE imageHFA driver returns wrong pixel value reading a newly created empty IMAGINE image

comment:2 Changed 11 years ago by warmerdam

Component: defaultGDAL_Raster
Keywords: HFA added
Owner: changed from Frank Warmerdam to warmerdam
Status: newassigned

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.

comment:3 Changed 11 years ago by warmerdam

Resolution: fixed
Status: assignedclosed

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.

comment:4 Changed 11 years ago by 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.

Note: See TracTickets for help on using tickets.