Opened 14 years ago

Closed 8 years ago

#2914 closed defect (fixed)

Building RRD overviews using AVERAGE_BIT2GRAYSCALE results in wrong value

Reported by: gaopeng Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.6.0
Severity: normal Keywords: overviews


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.

Attachments (2) (134.7 KB ) - added by gaopeng 13 years ago. (289.9 KB ) - added by gaopeng 12 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 by warmerdam, 13 years ago

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?

comment:2 by gaopeng, 13 years ago

Resolution: worksforme
Status: newclosed

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

comment:3 by gaopeng, 13 years ago

Resolution: worksforme
Status: closedreopened

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.

by gaopeng, 13 years ago

Attachment: added

comment:4 by warmerdam, 13 years ago

Keywords: overviews added

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.

comment:5 by warmerdam, 13 years ago

Resolution: fixed
Status: reopenedclosed

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/ - perhaps there is a distinction in how overviews are created in the same file vs in a separate file?

comment:6 by gaopeng, 12 years ago

Resolution: fixed
Status: closedreopened

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

by gaopeng, 12 years ago

Attachment: added

comment:7 by warmerdam, 12 years ago

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.

comment:8 by warmerdam, 12 years ago

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?

comment:9 by gaopeng, 12 years ago

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

comment:10 by Jukka Rahkonen, 8 years ago

Feels like undone back porting to 1.6-esri is the thing that has kept this otherwise resolved issue open. That back porting will never happen so close the issue as fixed.

comment:11 by Even Rouault, 8 years ago

Milestone: 1.8.1
Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.