strange problems with png8 image format

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

strange problems with png8 image format

fgdrf
Hi,

after the fix of bug UDIG-1650 (transparency and image format png8) the labels of rendered features are ugly. What I've done:

- default image format png8
- checked out response from geoserver with image format png8 and transparency
- I run the app with anti-aliasing option enabled and compared it to the result when anti-aliasing was disabled. -> no difference


The effect of ugly labels (see attachment wms-2.png) I only get with the udig WMS client (1.2 RC2 btw.). Do you have any suggestions why this happens?

Frank

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel

wms.png (14K) Download Attachment
wms-2.png (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: strange problems with png8 image format

Jody Garnett-2
Interesting.

I wonder if the alpha buffer is being used to soften the edges of the fonts? uDig is probably trying to respect any transparency so content can show through.  If you are just looking at the image on its own perhaps this is not noticeable?  Could you try loading the images into a paint program to see what is going on with transparency...

Other then that we should ask on the geoserver-users email list to see if we can learn the specific of how encoding transparency occurs.

Jody

On 18/05/2010, at 11:55 PM, Frank Gasdorf wrote:

Hi,

after the fix of bug UDIG-1650 (transparency and image format png8) the labels of rendered features are ugly. What I've done:

- default image format png8
- checked out response from geoserver with image format png8 and transparency
- I run the app with anti-aliasing option enabled and compared it to the result when anti-aliasing was disabled. -> no difference


The effect of ugly labels (see attachment wms-2.png) I only get with the udig WMS client (1.2 RC2 btw.). Do you have any suggestions why this happens?

Frank
<wms.png><wms-2.png>_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange problems with png8 image format

fgdrf
Well, I just created new pictures with the missing parameter transparency=true and the returned pictures of these requests are different. The "ugly" labels using the image format png8 are generated from geoserver. My fault :(
Sorry for that post, I'm going to move this question to the geoserver/geotools list.

Frank

2010/5/19 Jody Garnett <[hidden email]>
Interesting.

I wonder if the alpha buffer is being used to soften the edges of the fonts? uDig is probably trying to respect any transparency so content can show through.  If you are just looking at the image on its own perhaps this is not noticeable?  Could you try loading the images into a paint program to see what is going on with transparency...

Other then that we should ask on the geoserver-users email list to see if we can learn the specific of how encoding transparency occurs.

Jody

On 18/05/2010, at 11:55 PM, Frank Gasdorf wrote:

Hi,

after the fix of bug UDIG-1650 (transparency and image format png8) the labels of rendered features are ugly. What I've done:

- default image format png8
- checked out response from geoserver with image format png8 and transparency
- I run the app with anti-aliasing option enabled and compared it to the result when anti-aliasing was disabled. -> no difference


The effect of ugly labels (see attachment wms-2.png) I only get with the udig WMS client (1.2 RC2 btw.). Do you have any suggestions why this happens?

Frank
<wms.png><wms-2.png>_______________________________________________


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel



_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange problems with png8 image format

aaime
Frank Gasdorf ha scritto:
> Well, I just created new pictures with the missing parameter
> *transparency=true* and the returned pictures of these requests are
> different. The "ugly" labels using the image format png8 are generated
> from geoserver. My fault :(

Labels use antialising heavily, when we do color reduction to 256 colors
that will suffer inevitably, especially with transparent output.
There is nothing easy that can be done for that unfortunately,
we'd need a color reduction algorithm that supports alpha in the
palette, something that an open source project, pngnq, does, but
it's not trivial at all to port over.

I'd estimate it would take 3-5 days of work for a developer
that knows _very_ well its way in the raster data manipulation
algorithms and will probably result in a 2-10 times slowdown
compared to the current color reduction algorithm

Cheers
Andrea



--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange problems with png8 image format

Simone Giannecchini
In reply to this post by fgdrf
Ciao Frank,
atm there is no way to improve the appearance of those labels if you
choose to encode with either gif or png8.
The quantization algorithm that I implemented does not take into
account transparency originally, nevertheless I modified to make it
possible to work on translucent images. This means that while going
from translucent images (various transparent levels) to
opaque/transparent images (where a pixel can be only transparent or
opaque) as supported by GIF, the non completely transparent pixels are
turned into pure opaque, therefore we generate aliasing, although we
retain full transparency.

That said, this can be improved but not overnight since the algorithm
would be quite different from what we have and performances will be
different as well (much worse).

Simone.

-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041  Camaiore (LU)
Italy

phone: +39 0584983027
fax:      +39 0584983027
mob:    +39 333 8128928


http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------



On Wed, May 19, 2010 at 8:42 AM, Frank Gasdorf
<[hidden email]> wrote:

> Well, I just created new pictures with the missing parameter
> transparency=true and the returned pictures of these requests are different.
> The "ugly" labels using the image format png8 are generated from geoserver.
> My fault :(
> Sorry for that post, I'm going to move this question to the
> geoserver/geotools list.
>
> Frank
>
> 2010/5/19 Jody Garnett <[hidden email]>
>>
>> Interesting.
>> I wonder if the alpha buffer is being used to soften the edges of the
>> fonts? uDig is probably trying to respect any transparency so content can
>> show through.  If you are just looking at the image on its own perhaps this
>> is not noticeable?  Could you try loading the images into a paint program to
>> see what is going on with transparency...
>> Other then that we should ask on the geoserver-users email list to see if
>> we can learn the specific of how encoding transparency occurs.
>> Jody
>> On 18/05/2010, at 11:55 PM, Frank Gasdorf wrote:
>>
>> Hi,
>>
>> after the fix of bug UDIG-1650 (transparency and image format png8) the
>> labels of rendered features are ugly. What I've done:
>>
>> - default image format png8
>> - checked out response from geoserver with image format png8 and
>> transparency
>> both requests return same image :
>> png :
>> http://localhost:8092/geoserver/wms?bbox=-130,24,-66,50&styles=&Format=image/png&request=GetMap&layers=utm_grp&width=550&height=250&srs=EPSG:4326
>> png8 :
>> http://localhost:8092/geoserver/wms?bbox=-130,24,-66,50&styles=&Format=image/png8&request=GetMap&layers=utm_grp&width=550&height=250&srs=EPSG:4326
>> see attachment wms.png
>>
>> - I run the app with anti-aliasing option enabled and compared it to the
>> result when anti-aliasing was disabled. -> no difference
>>
>>
>> The effect of ugly labels (see attachment wms-2.png) I only get with the
>> udig WMS client (1.2 RC2 btw.). Do you have any suggestions why this
>> happens?
>>
>> Frank
>> <wms.png><wms-2.png>_______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>
>>
>> _______________________________________________
>> User-friendly Desktop Internet GIS (uDig)
>> http://udig.refractions.net
>> http://lists.refractions.net/mailman/listinfo/udig-devel
>>
>
>
> _______________________________________________
> User-friendly Desktop Internet GIS (uDig)
> http://udig.refractions.net
> http://lists.refractions.net/mailman/listinfo/udig-devel
>
>
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange problems with png8 image format

fgdrf
Hi Simone, Hello List

2010/5/19 Simone Giannecchini <[hidden email]>
That said, this can be improved but not overnight since the algorithm
would be quite different from what we have and performances will be
different as well (much worse).

So as long as this behavior occurs the default image order in udig should be changed. The image/png8 format as the first entry should be moved right behind image/png. maybe is this the reason, why there was no transparency support for png8 before the patch of UDIG-1650 was applied? Should we revert this patch and comment it or change the default order instead?

Any suggestions?

Cheers, Frank


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange problems with png8 image format

Jody Garnett-2
It is kind of strange; png8 is the fastest performing format for tiles :-)
But sure we can change the default order back.... done.

Jody
On 19/05/2010, at 9:50 PM, Frank Gasdorf wrote:

Hi Simone, Hello List

2010/5/19 Simone Giannecchini <[hidden email]>
That said, this can be improved but not overnight since the algorithm
would be quite different from what we have and performances will be
different as well (much worse).

So as long as this behavior occurs the default image order in udig should be changed. The image/png8 format as the first entry should be moved right behind image/png. maybe is this the reason, why there was no transparency support for png8 before the patch of UDIG-1650 was applied? Should we revert this patch and comment it or change the default order instead?

Any suggestions?

Cheers, Frank

_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel


_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
Reply | Threaded
Open this post in threaded view
|

Re: strange problems with png8 image format

aaime
Jody Garnett ha scritto:
> It is kind of strange; png8 is the fastest performing format for tiles :-)
> But sure we can change the default order back.... done.

It is the fastest as long as you have a remote server and the tile is
opaque, which makes it a good choice for the first layer, but not for
the others

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel