Opened 22 years ago
Closed 14 years ago
#94 closed defect (wontfix)
New OGR Autostyling colors don't always work
Reported by: | warmerdam | Owned by: | dmorissette |
---|---|---|---|
Priority: | highest | Milestone: | |
Component: | OGR Support | Version: | 4.0 |
Severity: | normal | Keywords: | |
Cc: |
Description (last modified by )
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 (4)
comment:2 by , 22 years ago
Cc: | added |
---|---|
Version: | 3.5 → 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.
comment:3 by , 21 years ago
Priority: | high → 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.
comment:4 by , 14 years ago
Description: | modified (diff) |
---|---|
Resolution: | → wontfix |
Status: | assigned → closed |
Closing WONTFIX. In addition to being 7 year old, this issue is becoming less relevant with the new palette and related outputformat options.
Note:
See TracTickets
for help on using tickets.