antialias : hardness support configured in the map file

[assefa]

There is a need to adjust the hardness factor to get diffrent effect for the 
antiialias support.

I think few issues was the following :
  * parameter to b used : a new parameter or use the antialias parameter
  * values should be between 0-1 or 0-100 or soft/hard
  * what about true and false values now used for the antialias parameters

Here are some conversations done on mapservder-dev list in Jan 2006 :


Date:         Sun, 15 Jan 2006 17:55:04 -0500
Reply-To:     Daniel Morissette <dmorissette@DMSOLUTIONS.CA>
Sender:       UMN MapServer Developers List <MAPSERVER-DEV@LISTS.UMN.EDU>
From:         Daniel Morissette <dmorissette@DMSOLUTIONS.CA>
Subject:      Re: antialiasing stuff
In-Reply-To:  <112BBC37-8343-4AE1-A407-1EB2C95C8257@dmsolutions.ca>
Content-Type: text/plain; charset=us-ascii; format=flowed

After seeing how you had to tune the hardness value in order to get the 
best possible looking maps, I agree that just soft and hard might not be 
enough, especially when at the lower level the range of valid values is 
much larger than that.

My main concern would be to not break backwards compatibility with older 
mapfiles (even if antialias never really worked before). We'd have to 
make sure that ANTIALIAS TRUE/FALSE are still supported by the parser, 
with some acceptable default for the TRUE case.

BTW, isn't the internal hardness value a float in the 0.0-1.0 range? If 
that's the case then that's what we should offer in the mapfile too.

Daniel


Paul Spencer wrote:
> That seems to go against other aspects of mapserver's design where  full 
> control is provided at the expense of some complexity.  Whatever  gets 
> picked will never be quite right for some people.  I think the  extra 
> complexity can be adequately controlled by documenting  reasonable 
> values for 'soft', 'medium', and 'hard' and what the  effect is on the 
> output.
> 
> 
> Cheers
> 
> Paul
> 
> On 14-Jan-06, at 11:15 AM, Sean Gillies wrote:
> 
>> IMO, that's more control than people need. How about a few flavors  of 
>> antialiasing like "soft" and "hard".
>>
>> Sean
>>
>> On Jan 14, 2006, at 8:56 AM, Paul Spencer wrote:
>>
>>> Would it make sense to change the meaning of the antialias tag in the
>>> style and change it to a 0-100 value instead of a true/false?  If you
>>> don't want to antialias a layer, then you wouldn't put ANTIALIAS
>>> FALSE, you'd just remove it altogether.  So in the case of using
>>> antialias as an integer value, it would make sense.
>>>
>>> Paul
>>>
>>> On 13-Jan-06, at 4:38 PM, Yewondwossen Assefa wrote:
>>>
>>>> I have not seen an equivalent term in the sld specs.
>>>>
>>>> Steve Lime wrote:
>>>>
>>>>> I think in the next version we could expose the hardness setting
>>>>> to mapfile
>>>>> tweaking... What's the equivalent terminiology in something like  SLD?
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>>>>> Paul Spencer <pspencer@DMSOLUTIONS.CA> 01/13/06 2:43 PM >>>
>>>>>>>>
>>>>> cool, thanks :)  I hadn't tried it, thought I would ask first.
>>>>> I've  managed to achieve almost the desired effect by jacking the
>>>>> hardness  to 0.95 and fixing the gd bug for 1 pixel lines since I
>>>>> asked so  maybe we won't end up going this route.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Paul
>>>>>
>>>>> PS: any chance of having a HARDNESS keyword at the style level?
>>>>>
>>>>> On 13-Jan-06, at 2:55 PM, Steve Lime wrote:
>>>>>
>>>>>
>>>>>> This should be doable "as is". Just set TRANSPARENCY ALPHA and  point
>>>>>> to the right image in your style or symbol definition. All the
>>>>>> fuzzy brush
>>>>>> support does is do this programatically.
>>>>>>
>>>>>> I believe I've tested this before using an image or two that
>>>>>> Sean  had created
>>>>>> while fixing another bug.
>>>>>>
>>>>>> Have you tried it and it doesn't work?
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>
>>>>>>>>> Paul Spencer <pspencer@DMSOLUTIONS.CA> 01/13/06 12:59 PM >>>
>>>>>>>>>
>>>>>> Steve,
>>>>>>
>>>>>> what would it take to support rendering lines with custom symbols
>>>>>> that have alpha transparency in them?  We would like to be able to
>>>>>> make our own brushes that work in the same way that fuzzy brushes
>>>>>> work, but we pre-render them and access them as symbols.  This  would
>>>>>> allow finer control over styling without having to tweak mapserver
>>>>>> code to get the desired effect :)
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Paul
>>>>>>
>>

[assefa]

added Paul in CC

[bartvde@…]

Adding myself to the cc.

[tbonfort]

irrelevant now we have agg rendering