Opened 13 years ago

Closed 13 years ago

#3848 closed defect (fixed)

Faulty image/png; mode=8bit output if source image has overviews

Reported by: jratike80 Owned by: tbonfort
Priority: highest Milestone: 6.0 release
Component: Renderer API Version: svn-trunk (development)
Severity: blocker Keywords:
Cc:

Description

MapServer 6.0 beta versions create occasionally odd coloured output images if the outputformat is image/png; mode=8bit and if the source image has overviews. Odd output occurs at some scale ranges only, but the issue can be repeated so that a certain WMS request yields always an odd looking result. Typically all 256 palette entries in the output image are presenting very dark colours. The same error can also be achieved by using the following outputformat OUTPUTFORMAT

NAME 'AGG_Q'

MIMETYPE "image/png"

DRIVER "AGG/PNG"

EXTENSION "png"

IMAGEMODE RGB

FORMATOPTION "QUANTIZE_FORCE=ON" FORMATOPTION "QUANTIZE_DITHER=OFF"

FORMATOPTION "QUANTIZE_COLORS=256"

END

MapServer v. 5.6.5 works OK with this outputformat even if the source image has overviews.

Change History (3)

comment:1 by tbonfort, 13 years ago

Component: WMS ServerRenderer API
Milestone: 6.0 release
Owner: changed from mapserverbugs to tbonfort
Priority: normalhigh
Status: newassigned
Version: unspecifiedsvn-trunk (development)

I'm narrowing this down. This hasn't got anything to do with overviews, but rather to the number of colors that are present in the final image. Building an overview with -r average creates an image with more r,g,b triplets than the original and triggers the bug.

  • suppress overviews, and add RESAMPLE=average in the raster layer => wrong output

  • remove RESAMPLE=average, and add noise into the source raster image to add to the number of total colors => depending on the quantity of noise, the bug will appear.

I've probably made a copy/paste error when transitioning from the 5.x to 6.x quantization code. The problem is I can't find where yet.

comment:2 by tbonfort, 13 years ago

Priority: highhighest
Severity: normalblocker

ok, I've found the bug. It was due to some scaling/rescaling of pixel values in the quantization step, and only occured in some situations.

My head is about to explode from this so I'll put the fix off to tomorrow !

thanks for finding this and providing the testcase !

comment:3 by tbonfort, 13 years ago

Resolution: fixed
Status: assignedclosed

fixed in r11599

msautotest test added in r11600

Note: See TracTickets for help on using tickets.