patch for Ticket #743 / png8 transparency

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

patch for Ticket #743 / png8 transparency

Bruno Scott

Take a look at this
http://trac.osgeo.org/mapguide/ticket/743#comment:15

The patch only affect png8 output. As the actual png8 output has really a poor quality it's quite safe to apply this patch on the 2.4 branche.

Test image before patch



Test image with patch


It would be great if someone could test this patch with any type of maps

Bruno Scott
Geomap
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Jackie Ng
WOW!

This is a bug that sorely needed to be fixed. I was originally planning to go for the 2.4 final release after RC2, but now I'm considering a 3rd RC just to get this patch in with a good round of testing.

Many thanks for this patch. I'm definitely gonna give this a workout.

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Gabriele Monfardini
In reply to this post by Bruno Scott
Hi,

> Take a look at this
> http://trac.osgeo.org/mapguide/ticket/743#comment:15
> <http://trac.osgeo.org/mapguide/ticket/743#comment:15>
>
> The patch only affect png8 output. As the actual png8 output has really a
> poor quality it's quite safe to apply this patch on the 2.4 branche.
>
> Test image before patch
> <http://osgeo-org.1560.n6.nabble.com/file/n5003596/trans_mapguide_png8.png>
>
> Test image with patch
> <http://osgeo-org.1560.n6.nabble.com/file/n5003596/new2_mapguide_png8.png>

I've always used PNG8 in my maps (except for overlay since as you
noted Mapguide was unable to handle partial transparency in overlay).

I've seen defects like  "Test image before patch" if I have a
background polygon layer (a.k.a. sort of state limits or the like) and
I set it to off from the legend.

With a filled "background" layer lines and text are rendered
correctly, without they are subsampled (low res) as in your "Test
image before patch".

This however has a simple workaround, to add a "background" layer
which cannot be toggled off by users.

The only real drawback of using PNG8 imho is the bug that I described
in ticket http://trac.osgeo.org/mapguide/ticket/1518.

The proper solution to the bug is to preserve exactly the color that
has been chosen in map layers if their number is below the 256 entries
in the palette.
A sort of color quantization with some centroid color fixed.

Otherwise even a small pan may discover a part of the map with
different colors w.r.t. the rest and color quantization may lead to
different palette entries.
This is quite visible where you have large filled polygons, which
colors drift significantly or in cases when colors are prescribed and
should not be modified.
It also affects map readability since colors drift from their legend entries.

I'm willing to test your patch since it may be a good mapguide enhancement.

Regards,

Gabriele Monfardini
_______________________________________________
mapguide-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Jackie Ng
For those who want to try out this patch, I've attached MgRenderers.dll built with this patch applied for 32-bit and 64-bit

Drop into your MGOS 2.4 RC2 installation and overwrite the existing MgRenderers.dll

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Jackie Ng
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

zspitzer
Great work Bruno!

On Sat, Sep 22, 2012 at 2:19 AM, Jackie Ng <[hidden email]> wrote:

> Attached to ticket 743 that is.
>
> http://trac.osgeo.org/mapguide/attachment/ticket/743/MgRenderers-MGOS24RC2-x64.zip
>
> http://trac.osgeo.org/mapguide/attachment/ticket/743/MgRenderers-MGOS24RC2-x86.zip
>
> - Jackie
>
>
>
> --
> View this message in context: http://osgeo-org.1560.n6.nabble.com/patch-for-Ticket-743-png8-transparency-tp5003596p5003624.html
> Sent from the MapGuide Users mailing list archive at Nabble.com.
> _______________________________________________
> mapguide-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-users



--
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
+61 405 847 168
_______________________________________________
mapguide-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Jackie Ng
In reply to this post by Gabriele Monfardini
I like to look at this from a macro-level perspective.

Yes, there may still be the aforementioned bugs w.r.t. palette preservation, but the fact that I can finally have transparent PNG8 tiles means this patch is still a net gain over what we had previously (opaque tiles when tile image format is PNG8)

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Bruno Scott
It is possible to add some fixed palette color in this.
But i really would like to see how it reacts on a big tiled map full of colors.
The mapserver quantization looks pretty good. It is possible that we dont need it.

Bruno
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

zspitzer
the logic used for palette preservation (based on layers defs)
for PNG8 tiles is here

http://trac.osgeo.org/mapguide/changeset/4484

z

On Mon, Sep 24, 2012 at 7:10 PM, Bruno Scott <[hidden email]> wrote:

> It is possible to add some fixed palette color in this.
> But i really would like to see how it reacts on a big tiled map full of
> colors.
> The mapserver quantization looks pretty good. It is possible that we dont
> need it.
>
> Bruno
>
>
>
> --
> View this message in context: http://osgeo-org.1560.n6.nabble.com/patch-for-Ticket-743-png8-transparency-tp5003596p5003938.html
> Sent from the MapGuide Users mailing list archive at Nabble.com.
> _______________________________________________
> mapguide-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-users



--
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
+61 405 847 168
_______________________________________________
mapguide-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Bruno Scott
In reply to this post by Jackie Ng
These 2 dlls also works with Autodesk Infrastructure MapServer 2013.

So if someone want to test some nice png8 output with this platform, you are welcome.

Bruno Scott
Geomap
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Jackie Ng
In reply to this post by Gabriele Monfardini
I've taken a stab at this. Turns out that the new PNG8 code path in Bruno's patch does nothing with the computed baseColorPalette parameter that gets handed down.

So my changes now tell msQuantizeRasterBuffer() to compute a palette of (256 - baseColorPalette.size()) colors, and fill the remainder of the palette with the colors from the baseColorPalette parameter, which is only done if baseColorPalette is not NULL and has < 256 colors.

New MgRenderers.dll for MGOS 2.4 RC2 attached to the same ticket.

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Bruno Scott
Hi jackie,

I've tried this also. And i have not see much difference on the resulting images.
The msquantization seem pretty smart, it compute a color histogram first. For each color theres the amout of pixels used. Then it is sorted. So color that are used mostly in the image will be in the palette.

When passing a predefined palette,we may reserve a color that is not use in the images.
Then loosing some color accuracy

I've tested some tiled maps here, and they are all super nice.
I really would like to see other tileds maps, or having some feedback from other users before applying this type of modification.

We could also replace the s_useColorMap memory flags by a serverconfig.ini switch

Bruno Scott
Geomap
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Jackie Ng
Unless I got this PNG8 quantization business all wrong, if the resulting image would use < 256 colors then there shouldn't be a need for the quantizer to compute a palette is there? Just take this list of colors that we've extracted out of all the Layer/Symbol Definitions and let the PNG8 quantizer "fill in the blanks" up to the 256 colors.

If we have defined these colors in our Layer/Symbol definitions, I think they should be respected if the total number of colors used < 256.

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

zspitzer
One of the issues is that with subpixel rendering using AGG, a map using
60 base colours will actually use more than 60 colours for fine edges
(so I believe)

The reason why we use a predefined palette for tiles is that for
Explore Australia,
we were having heaps of problems with the colour of ocean changing
between tiles,
obviously this is less of a problem with a single image dynamic map.

Perhaps the ultimate solution would be to feed to predefined palette into the
the quantization routines as a hint, with any used predefined colours being
discarded. Perhaps this could be triggered when a certain threshold is reached,
i.e. a full palette. An obvious example would be a map using a raster background


z

On Thu, Sep 27, 2012 at 2:33 AM, Jackie Ng <[hidden email]> wrote:

> Unless I got this PNG8 quantization business all wrong, if the resulting
> image would use < 256 colors then there shouldn't be a need for the
> quantizer to compute a palette is there? Just take this list of colors that
> we've extracted out of all the Layer/Symbol Definitions and let the PNG8
> quantizer "fill in the blanks" up to the 256 colors.
>
> If we have defined these colors in our Layer/Symbol definitions, I think
> they should be respected if the total number of colors used < 256.
>
> - Jackie
>
>
>
> --
> View this message in context: http://osgeo-org.1560.n6.nabble.com/patch-for-Ticket-743-png8-transparency-tp5003596p5004724.html
> Sent from the MapGuide Users mailing list archive at Nabble.com.
> _______________________________________________
> mapguide-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/mapguide-users



--
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
+61 405 847 168
_______________________________________________
mapguide-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-users
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Crispin_at_Linknode
In reply to this post by Jackie Ng
The result (even with scanned map rasters - ie small-ish colour palette in the image) overlaid with vector detail looks great.  x64 version tested.

From the top 6 scale ranges from Sheboygan I also created a small PNG8 tile cache (27,000 tiles) and it reduced the size to less than half the PNG and took 5-10% less time (MGCooker).

 Crispin
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Jackie Ng
In reply to this post by Jackie Ng
I've put up a 3rd version of this patch (with matching MgRenderers.dll).

I screwed up the color preservation logic in the previous version. Turns out if you ask for (256 - baseColorPalette.size()) colors in msQuantizeRasterBuffer, it may not exactly fill up to that number of colors that your requested (it could be less), resulting in potential overruns of the baseColorPalette, when appending them to the computed palette.

The maps where I tested Bruno's original patch did some unwanted color shifting for some symbols, but those colors are retained in this patch.

- Jackie
Reply | Threaded
Open this post in threaded view
|

Re: patch for Ticket #743 / png8 transparency

Gabriele Monfardini
Hi all,

it seems that PNG8 quantization patch works very well.
I've closed ticket http://trac.osgeo.org/mapguide/ticket/1518 since
seems to be fixed.

Also selection in PNG8 works.

IMHO PNG8 is better suited in all cases w.r.t. PNG.
Why don't set PNG8 as default format for RequestMapImage and for
RequestSelectionImage?

Regards,

Gabriele Monfardini
_______________________________________________
mapguide-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/mapguide-users