[Gdal-dev] hatches rendering issues

[Eric Lemoine]

On 11/6/07, Frank Warmerdam <warmerdam at pobox.com> wrote:
> Eric Lemoine wrote:
> >> It would be helpful to see the results, but generally it is hard to
> >> downsample repeating patterns without odd aliasing effects.  The best
> >> is to be very certain that exact factor of 2 downsamplings are done in
> >> which case the algorithms should sample the data in a consistent way.
> >
> > Thanks for your response Franck. Would you mind elaborate a bit more
> > on your last sentence?
> >
> > <http://dev.camptocamp.com/grandlyon_plu/problem_images/>
> >
> > Three screenshots at 1/20000, 1/10000, and 1/5000.
>
> Eric,
>
> I've looked at the three images.  The 1/5000 is the original, right?  Is this
> really the *original*?  It seems the hatching spacing is not exactly uniform
> and darkness of the hatch is not uniform.  So if this is what you are working
> from you are basically doomed to relatively poor and inconsistent results.
>
> The hatching does not follow on nice power of 2 boundaries, so nearest
> neighbour downsampling will certainly produce inconsistent results (some
> hatches will be completely missed for instance).  Are the 1/10000 and
> 1/20000 samples you provide produced with averaging?  With MapServer or
> gdaladdo?
>
> MapServer's "averaging" does not always go back to the original image to
> do the averaging (I think), so as you start to downsample a lot it will
> suffer from nearest neighbour "missing a line" effects which seems to be
> the case.  Gdaladdo on the other hand should not have this effect.

If my original image is 1/5000 and if I use <gdaladdo file.tif 2 4>,
is MapServer going to do its own downsampling? I was expecting
MapServer to rely on the overviews created by gdaladdo and do nothing
more.

--
Eric