Building RRD overviews using AVERAGE_BIT2GRAYSCALE results in wrong value

[gaopeng]

The overview pixel values are correctly scaled from [0,1] to [0,255] during overview generation, but are truncated back to 1 when saved to RRD band, which is of data type EPT_u1.

[warmerdam]

I have tried the following command:

gdaladdo -r average_bit2grayscale test1.tif 2 --config USE_RRD YES --config HFA_USE_RRD YES

on a 1 bit TIFF file, and produced .rrd overviews that seem to be correctly greyscale averaged in a byte overview type.

I did find I had to make some changes to avoid the new color table lookup logic when doing bit2grayscale overviews in trunk (r16884) and 1.6 branch (r16885) but I don't think this relates to the problem report directly.

Could you provide more detail on how I might reproduce this problem?

[gaopeng]

I can't reproduce this anymore. I closed it as non-reproducible.

[gaopeng]

I reopen this ticket with a new test case. The attached is an 1-bit tiff image with an external tiff overview (.ovr) with AVERAGE_BIT2GRAYSCALE (created by making tiff read-only). The overview pixel values are 1 instead of 255.

[warmerdam]

I have confirmed that if I copy the .tif file to wrk.tif and run the following the generated overviews are still just 0/1 valued - and in fact the overviews are 1bit.

gdaladdo -r average_bit2grayscale wrk.tif 2
warmerda@gdal64[146]% tiffinfo wrk.tif.ovr
TIFFReadDirectory: Warning, Unknown field with tag 42112 (0xa480) encountered.
TIFF Directory at offset 0x8 (8)
  Subfile Type: reduced-resolution image (1 = 0x1)
  Image Width: 5388 Image Length: 6564
  Tile Width: 128 Tile Length: 128
  Bits/Sample: 1
  Sample Format: unsigned integer
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  Samples/Pixel: 1
  Planar Configuration: single image plane
  Tag 42112: <GDALMetadata><Item name="RESAMPLING" sample="0">AVERAGE_BIT2GRAYSCALE</Item></GDALMetadata>

It would appear there are smarts in the TIFF driver for creation of the overviews of NBITS=1 files with one bit depth that need to be disabled for this kind of overview sampling.

[warmerdam]

Corrected in trunk (r17614) and 1.6-esri (r17615).

I'm not really sure why this problem was not exposed by tiff_ovr_4 in autotest/gcore/tiff_ovr.py - perhaps there is a distinction in how overviews are created in the same file vs in a separate file?

[gaopeng]

I reopen this ticket, again, with a new test case. The attached is an 1-bit IMG. Building overviews (.rrd) using AVERAGE_BIT2GRAYSCALE results in a black overviews All pixels are [0,1], instead of [0,255].

[warmerdam]

It appears that HFACreateOverview() always creates overviews for a 1bit layer as 1bit overviews. The resampling algorithm is not consulted. So even though things are promoted to 8bit and computed in greyscale the result is demoted to 1bit on write.

I tested with the command:

gdaladdo -r average_bit2grayscale sw_pyr2.img --config USE_RRD YES --config HFA_USE_RRD YES 2

I will dig into ensuring HFACreateOverview() can be forced to create 8bit overviews for 1bit layers if bit2grayscale is in effect.

[warmerdam]

I have fixed the code so the overview is generated as 8bit instead of 1bit for this particular overview algorithm. I also found I had to fix things so that HFARasterBand has an nHFADataType of EPT_u8 instead of EPT_u1 for the overview in this case or it was written corrupted.

Incidentally fixed GetFileList?() to include .rrd.

The fixes are currently in trunk (r21352) with some regression testing (r21351).

Should this be back ported to 1.6-esri or some other branch?

[gaopeng]

Yes. Could you please back port it to 1.6-esri?