Ticket #94 (assigned defect)

Opened 7 years ago

Last modified 6 years ago

New OGR Autostyling colors don't always work

Reported by: warmerdam Assigned to: dmorissette (accepted)
Priority: highest Milestone:
Component: OGR Support Version: 4.0
Severity: normal Keywords:
Cc:

Description 

Daniel, 

I am testing my autostyling of DGN labels.  I have it working with true type
fonts now and suddenly the labels are no longer being colored properly. 

I have determined that new colors added to the map palette in msLayerGetAutoStyle
may not get added to the gdImg palette.  In particular, when I render anti-aliases
labels, the gd and freetype code add extra colors to the gdImg palette for the
edge pixels with mixed colors.  If a later label with a new color is
encountered by msLayerGetAutoStyle() it gets added to the map palette.  
However, the subsequent call to msUpdatePalette() fails to copy the new color
over to the gdImg palette since that slot is already occupied by anti-aliasing
colors that were never in the map palette.  

The result is that the labels are colored improperly. 

I am not sure what the solution is.  Perhaps before calls to
msLayerGetAutoStyle() any extra gdImg colors should be (at least temporarily?) 
propagated into the map's palette.  What are the issues with doing that?

Best regards,

msLayerGetAutoStyle w

 1)

Change History

01/18/02 18:44:23 changed by dmorissette

  • status changed from new to assigned.
The problem description makes complete sense but unfortunately I don't have an 
easy solution to suggest right now.  I'll try to have a look at the code and 
come back to you on this during the weekend.

05/21/02 10:48:48 changed by dmorissette

  • cc set to steve.lime@dnr.state.mn.us.
  • version changed from 3.5 to 3.7.
Frank,  I had another look at this, and it seems that OGR AUTO styles should 
actually behave like raster layers with respect to color allocations and 
allocate colors directly in the gdImage instead of going through msAddColor.

In this context, I think the fix would be to make add_color() from mapraster.c 
public (maybe call it msAddColorDirectly()) and then use it from mapogr.cpp.

I'll add Steve in the CC: of this bug in case he wants to comment.

02/28/03 16:25:26 changed by dmorissette

  • priority changed from high to highest.
OGR STYLEITEM AUTO color handling really needs some work.  At the same time I 
should also consider using msAddColorGD() and supporting the 
COLOR_MATCH_THRESHOLD output format parameter:

Frank Warmerdam wrote:
> 
> Folks,
> 
> I can't recall who brought up the issue of vectors being drawn in gray
> when a grayscale image is drawn first (because it sucked up the colors).
> 
> Well, we discussed adding a mechanism to force raster layers to use less
> colors here, and I have now implemented such a mechanism.   Currently it is
> implemented as the COLOR_MATCH_THESHOLD processing directive, such as shown
> here:
> 
> LAYER
>    NAME grey
>    TYPE raster
>    PROCESSING "COLOR_MATCH_THRESHOLD=3"
>    STATUS default
>    DATA data/grey.tif
> END
> 
> When looking for a matching color for a color entry in a raster layer, the
> logic now is to compare the "distance" from the desired color to this
> threshold.  The details are in msAddColorGD() in mapraster.c but the gist
> of it is that you should set the threshold to "3" to be allow a color 1 off
> in each of red, green and blue to match.
> 
> The default threshold is zero, meaning an exact match is required if possible,
> and if not a new color will be allocated.  As before it will fall back to
> using the nearest color if the colormap is full.
> 
> If we like this option we might want to promote it to having a proper keyword
> in the mapfile, and ensure it works for the other raster layer types.
> Currently it only works for GDAL rendered raster layers.
> 
> In fact, such a mechanism might be desirable for other color allocation such
> as that occuring due to colors loaded from vector files using the OGR "AUTO
> styling".   However, that is a bigger effort than I am interested in pursuing
> at this time.