Ticket #306 (closed defect: fixed)

Opened 10 years ago

Last modified 7 years ago

Accidental color changes

Reported by: kafka@… Owned by: warmerdam
Priority: high Milestone: 4.4 release
Component: MapServer CGI Version: 4.0
Severity: normal Keywords:
Cc: jmckenna@…, woodbri@…, mapserver@…

Description

In PC256 color mode, sometimes the colors are accidentaly changed, mainly for 
label backgrounds.

Attachments

colors1.gif Download (8.8 KB) - added by kafka@… 10 years ago.
Good colors - without underlying layer.
colors2.gif Download (21.4 KB) - added by kafka@… 10 years ago.
Bad road labels color - with underlying layer.
colors1.zip Download (165.8 KB) - added by kafka@… 10 years ago.
sample map file and data for testing
colors2.zip Download (0.9 MB) - added by kafka@… 10 years ago.
sample data - part 2

Change History

Changed 10 years ago by kafka@…

Good colors - without underlying layer.

Changed 10 years ago by kafka@…

Bad road labels color - with underlying layer.

Changed 10 years ago by kafka@…

  • bug_file_loc set to http://www.premathmod.cz/cgi-bin/mapserv?map=/home/www/virtuals/premathmod.cz/bnh/vuze/vuze.map&mode=map&mapext=-703485%20-1113938%20-658100%20-1113872&layer=lfa&layer=silnice
The colors are changed when LFA layer is set on.

Changed 10 years ago by kafka@…

  • owner changed from sdlime to fwarmerdam

Changed 10 years ago by fwarmerdam

  • status changed from new to assigned

Changed 10 years ago by fwarmerdam

  • status changed from assigned to closed
  • resolution set to invalid
Stepan,

You didn't provide any mapfile, or other supporting data to reproduce this
problem, so I can't really do much.  However, looking at the results I suspect
the label backgrounds were set with the wrong value because the available set
of colors was exausted before the first label was drawn (and thus the background
color was allocated). 

Does the bad case include a background layer with 256 colors?  If so, solutions
might include:

 o Running the background raster through a color reduction process.  
 o Somehow forcing the label background color to be pre-allocated (not too
   sure if if there is a normal way of acomplishing this in MapServer or not).
 o Using 24bit mode. 
 o Ensuring the raster file's color set includes all desired colors. 
 o Using the new color tolerance processing option for rasters to down-sample
   the raster colors set on the fly.

I am closing this bug report for now, but if you think I am way off base feel
free to re-open it with a minimal map file, and supporting data that reproduces
the problem. 

Changed 10 years ago by kafka@…

sample map file and data for testing

Changed 10 years ago by kafka@…

sample data - part 2

Changed 10 years ago by kafka@…

  • cc steve.lime@… added
  • status changed from closed to reopened
  • resolution invalid deleted
  I have resolved the problem. The color changes are really caused by color 
table overflow. In my simple map many colors are allocated by antialiasing (I 
wonder it has not been seen in GD versions < 2.0).

  BUT! If antialias is set false, still sort of antialiasing is performed in my 
map. I did some research and found:
- antialias is processed if fg < 0 in gdImageStringTTF (gdft.c)
- if the font or outline color is white (255 255 255), it gets index 0 (map 
background)
- then antialias is performed because of index 0 - and waste of colors allocated

Possible solutions:
- in GD changing gdImageStringTTF parameters call - introduce antialias as new 
parameter or do another coding (I think it is not practically possible.)
- avoid using white color for labels in Mapserver (changing to 255 255 254 or 
something like that).
- ?

Stepan

Changed 10 years ago by fwarmerdam

Steve,

I wonder if you could look at this briefly.  I don't really know what to do
about it. 


Changed 10 years ago by sdlime

Will do...

Changed 9 years ago by woodbri@…

This problem also shows up when users are not using antialiasing. I have lots of
mapfiles where I will get random color changes of items on the map as I zoom
through the layers. I have been able to work around it by creating dumby layers
like:
## dummy layer to protect symbol colors from changing
  LAYER
    NAME "color_symbol"
    STATUS DEFAULT
    TYPE point
    TRANSFORM false
    FEATURE
      POINTS
        1 1
      END
    END
    CLASS
      SYMBOL "color_symbol"
      COLOR 0 0 0
    END
  END
## protect other colors
  LAYER
    NAME blue
    STATUS DEFAULT
    TYPE point
    TRANSFORM false
    FEATURE
      POINTS
        1 1
      END
    END
    CLASS
      COLOR 0 0 255
    END
  END
  LAYER
    NAME green
    STATUS DEFAULT
    TYPE point
    TRANSFORM false
    FEATURE
      POINTS
        1 1
      END
    END
    CLASS
      COLOR 8 206 107
    END
  END

at the top of my mapfile to protect colors I have explicitly used in my mapfile,
but this uses up a lot of additional layers. Mapserver should make an explict
list of colors reference/defined in the mapfile and pre-allocate these colors in
 the GD image. Similarly, when symbols are added the colors reference in them
should be added to the color list.

In this way if there is an overflow of colors, they will get re-mapped in a
consistant way (and GD's color re-assignment is better the the browsers) so that
the use will not see changes while zooming.

Changed 9 years ago by mapserver@…

  • cc mapserver@… added

Changed 9 years ago by woodbri@…

  • cc woodbri@… added

Changed 9 years ago by woodbri@…

From a post by Frieso ter Haseborg:

looks like the ortho images consume the whole palette, you could try to reduce
this effect by using the processing parameter on the ortho-layer.

LAYER
   NAME "ortho"
   TYPE RASTER
   PROCESSING 'COLOR_MATCH_THRESHOLD=3'
   [...]

Start with a setting of 3 and increase this value until it fits your needs.

Changed 9 years ago by woodbri@…

A few people have suggested switching to 24 bit images, but this significantly
increases the image size and may not be a solution for may users:

IMAGETYPE png24bit
OUTPUTFORMAT
  NAME png24bit
  DRIVER "GD/PNG"
  MIMETYPE "image/png"
  IMAGEMODE rgb
END 

Changed 9 years ago by kafka@…

The accidental color changes are very frequent and troublesome with labels 
(and mainly antialiased ones). I have never met it with mapserver 3.4 version 
but with 4.x very often (in 8bit mode). There is probably different color 
allocation mechanism not taking label colors into account. Somewhere Steve Lime 
announced to reintroduce the old color allocation mechanism into version 4.x. 
It would be VERY welcome.

Stepan Kafka

Changed 9 years ago by sdlime

  • cc warmerdam@… added
The old allocation system took into account all colors in the mapfile and pre-
allocated them. You sometimes ran into trouble with rasters and labels, but it 
was not as evident. With labels at least the core text color was gauranteed to 
work. The fix, I believe, is in the case of 8-bit output to take a pass through 
all the classes and pre-allocate colors. Should be pretty easy to add. I'll try 
to get to it yet this week assuming there are no objections.

Steve

Changed 9 years ago by fwarmerdam

Steve,

In general I think preallocating colors is a good idea, but it seems like
you might end up allocating alot of colors that aren't going to be used. 
I think, at least, you should avoid pre-allocating colors for any disabled layers.
Perhaps there could even be some sort of directive to disable pre-allocation. 



Changed 9 years ago by sdlime

The old allocation system took into account all colors in the mapfile and pre-
allocated them. You sometimes ran into trouble with rasters and labels, but it 
was not as evident. With labels at least the core text color was gauranteed to 
work. The fix, I believe, is in the case of 8-bit output to take a pass through 
all the classes and pre-allocate colors. Should be pretty easy to add. I'll try 
to get to it yet this week assuming there are no objections.

Steve

Changed 9 years ago by sdlime

Mid air collision, sorry for the duplicate post, cut and paste from the wrong 
place...

That was always the problem with the old method. I think if we look at layer 
status that would be enough. Could be added just after image allocation in 
msDraw or in the prepare method. There's no way to predict the colors 
associated with anti-aliasing so there still may be problems there but at least 
labels and features over the top of rasters will render correctly.

Steve

Changed 9 years ago by kafka@…

We don't care for "antialised" colors but basic label and label background 
colors need to be preserved. It would be nice to reintroduce the mechanism 
before 4.4 launch. It is possible?

Thanks 

Stepan Kafka

Changed 9 years ago by sdlime

This will make it into 4.4. It's on my short todo list...

Steve

Changed 9 years ago by sdlime

I committed a fix for this tonite. It's a new function that, for 8-bit GD
images, pre-allocates label and style(s) colors for layers with STATUS
ON/DEFAULT before rendering. Can someone please test the fix? My demos all still
run fine but I don't have a good test case.

Steve

Changed 9 years ago by sdlime

*** Bug 475 has been marked as a duplicate of this bug. ***

Changed 9 years ago by dmorissette

  • cc jmckenna@… added
  • milestone set to 4.4 release
Jeff: Steve implemented a fix for the color problem that you ran into a few days
ago and needs someone to verify. Could you please get a new 4.3 binary from
Assefa and test with your mapfile to confirm that the color problem is gone?

Changed 9 years ago by kafka@…

  • status changed from reopened to closed
  • resolution set to fixed
I did some tests with new (tonight) version and it works well! Thank you very 
much. The bug seems to be fixed. 

Changed 9 years ago by sdlime

Wow, on the first try. Thanks for verifying...

Steve

Changed 9 years ago by kafka@…

  • status changed from closed to reopened
  • resolution fixed deleted
I am sorry, but I have beeen testing the 4.4.0b2 and found NEW color allocation 
bug. If there is a underlying classified raster in the map (22 classes), the 
vector layers colors are bad. If the same raster is not classified (but with 
exactly the same color scheme as classified result), the colors are good. This 
bug wasn't seen BEFORE color pre-allocation function implementation.

Stepan Kafka

Changed 9 years ago by sdlime

What happend with 3.6 in this case?

Changed 9 years ago by fwarmerdam

Stepan,

I think it would be helpful if you could prepare a demonstration of this problem.

Changed 7 years ago by jmckenna@…

Stepan does this color allocation bug in comment#25 apply to mapserver version
4.8 rc2?  If you provide a new sampleset i can also test for you.

Changed 7 years ago by kafka@…

I have tested it with 4.8rc3 and it works well. Thank you.

Changed 7 years ago by fwarmerdam

  • status changed from reopened to closed
  • resolution set to fixed
Closing on the basis of the last message.

Note: See TracTickets for help on using tickets.