Accidental color changes

[kafka@…]

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

[kafka@…]

Good colors - without underlying layer.

[kafka@…]

Bad road labels color - with underlying layer.

[kafka@…]

The colors are changed when LFA layer is set on.

[fwarmerdam]

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. 

[kafka@…]

sample map file and data for testing

[kafka@…]

sample data - part 2

[kafka@…]

  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

[fwarmerdam]

Steve,

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

[sdlime]

Will do...

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

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

[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 

[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

[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

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

[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

[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

[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

[sdlime]

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

Steve

[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

[sdlime]

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

[dmorissette]

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?

[kafka@…]

I did some tests with new (tonight) version and it works well! Thank you very 
much. The bug seems to be fixed. 

[sdlime]

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

Steve

[kafka@…]

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

[sdlime]

What happend with 3.6 in this case?

[fwarmerdam]

Stepan,

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

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

[kafka@…]

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

[fwarmerdam]

Closing on the basis of the last message.