[mapserver-users] jagged edges on images
chris_faulkner@anytimenow.com
chris_faulkner@anytimenow.com
Fri, 14 Jun 2002 21:51:27 +0100 (GMT Daylight Time)
--------------Boundary-00=_R9RPEHQ4GRES4WTFXFP0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
HI=20
How do you store your imagery ? Presumably, you will need to have many SH=
APEPATH definitions in map files and tileindex shape files around the pla=
ce. I'd be interested to know how you deal with this area.=20
Chris
> Chris -
> =20
> I deal with multi-terabyte data sets under MapServer already, and while
> there is a price for the resampled images, it does only have to be paid
> once. Even an extensive set of overviews (2x, 4x, 8x, 16x, etc.)
> increases the data storage by about a third (the 2x resample is
> obviously by far the largest). The additional processing to produce
> high-quality resampled images is pretty substantial relative to the res=
t
> of what MapServer does.
> =20
> However, if you do want to go that route, the best solution right now
> would be to have MapServer generate the "native resolution" output imag=
e
> - perhaps of a larger size than the output image if needed - and then
> write an image post-processor that does something like bicubic
> resampling in RGB space to the desired output size and then send it
> along to the client. High-quality resampling is somewhat compute- and
> memory-intensive, but if your output map images are modest sizes it
> might not be a big deal.
> =20
> - Ed
>=20
> -----Original Message-----=20
> From: chris_faulkner@anytimenow.com
> [mailto:chris_faulkner@anytimenow.com]=20
> Sent: Fri 6/14/2002 12:00 PM=20
> To: Ed McNierney=20
> Cc: mapserver-users@lists.gis.umn.edu; chris_faulkner@anytimenow.com=20
> Subject: RE: [mapserver-users] jagged edges on images
> =20
> =20
>=20
> Hi
> =20
> Sorry for the incorrect terminology.
> =20
> I wouldn't want to store multiple copies of the data because our image
> database is measured in terrabytes. The cost of the disk is not
> necessarily of prime importance (although top-end robust, reliable, rai=
d
> is not cheap when you buy that sort of quantity). The management issues
> of all those files would come into play, though. I'd rather wait anothe=
r
> fraction of a second for it to do the resampling every time, especially
> when the image is being served over the web and the slowest part of the
> process is much longer than that and is out of our control - the
> download ro the user's device.
> =20
> =20
> Chris
> =20
> > Chris -
> >
> > In the example you sent, it's not downsampling, it's upsampling - th=
e
> > output image is at a higher resolution than the input image. While
> > there are alternatives, and it would be nice for MapServer to suppor=
t
> > more resampling options, doing that well really needs to wait for th=
e
> > 24-bit output support to be available.
> >
> > Why do you not want to store multiple copies of the data? With
> multiple
> > copies you greatly reduce the amount of resampling that needs to be
> > done, and I'm a big fan of precomputing everything you possibly can.
> >
> > - Ed
> >
> >
> > -----Original Message-----
> > From: chris_faulkner@anytimenow.com
> > [mailto:chris_faulkner@anytimenow.com]
> > Sent: Friday, June 14, 2002 3:41 AM
> > To: Ed McNierney
> > Cc: chris_faulkner@anytimenow.com; mapserver-users@lists.gis.umn.edu
> > Subject: RE: [mapserver-users] jagged edges on images
> >
> >
> > Hi
> >
> > Yes - when I make sure that the input image resolution is the same a=
s
> > output, the image looks OK.
> >
> > However, as my last email says, I do want to be able to change scal=
e
> > without storing multiple copies of the data so it would be nice if
> the
> > down-sampling operation could support an option of a higher quality
> > alogorithm. IN this case, the output image might need to increase in
> > depth, though - maybe MapServer wouldn't support that.
> >
> > Chris
> >
> >
> > > Chris -
> > >
> > > This looks like an artifact of image scaling in the output image.
> > > MapServer prudently uses a fast algorithm for scaling source input
> > > images to produce the output result. If you ask for an output
> image
> > > whose pixel resolution (that is, meters per pixel, for example) is
> > > different than the source image resolution, the source image has t=
o
> be
> > > scaled. Your sample image looks like an output image with a pixel
> > > resolution slightly smaller than the input image. For example,
> let's
> > > assume your source image is at a resolution of 2 meters per pixel.
> > Then
> > > let's assume you asked for a 400 x 400 pixel output image from
> > MapServer
> > > with a spatial extent of 600 meters by 600 meters. That means you
> > want
> > > the output pixels to be 1.5 meters per pixel.
> > >
> > > Since the output is "zoomed in" a bit, MapServer is being asked to
> > > generate 400 output pixels (in each dimension) out of 300 input
> pixels
> >
> > > (600 meters at 2 meters per pixel). It will do that by duplicatin=
g
> > > every third input pixel in the output, so if you had a row of
> pixels
> > > with these values:
> > >
> > > 0 1 2 3 4 5
> > >
> > > you would get an output image with these values:
> > >
> > > 0 1 2 2 3 4 5 5
> > >
> > > Image then, that you had two single-pixel vertical lines in the
> source
> >
> > > image. In the output, the one at pixel position 2 would end up
> being
> > > two pixels wide, while the identical input line at pixel position =
4
> > > would still be only one pixel wide in the output. This will look
> > > strange.
> > >
> > > In your specific example, you appear to have antialiased text in
> the
> > > input image. The intermediate-shaded pixels along the edge of the
> > > text are sometimes replicated, giving the odd effect you see in th=
e
> > > words "Briar Patch".
> > >
> > > For optimum image quality without artifacts, keep the output image
> > > resolution the same as the source resolution, or a multiple of 2x
> the
> > > source resolution. If you're going to be doing that often,
> consider
> > > using GDAL and create overview images (preprocessed subsamples of
> the
> > > source image) to avoid having to resample the source image over an=
d
> > > over again to serve map requests.
> > >
> > > - Ed
> > >
> > > Ed McNierney
> > > President and Chief Mapmaker
> > > TopoZone.com / Maps a la carte, Inc.
> > > 73 Princeton Street, Suite 305
> > > North Chelmsford, MA 01863
> > > ed@topozone.com
> > > (978) 251-4242
> > >
> > > -----Original Message-----
> > > From: chris_faulkner@anytimenow.com
> > > [mailto:chris_faulkner@anytimenow.com]
> > > Sent: Wednesday, June 12, 2002 6:14 PM
> > > To: mapserver-users@lists.gis.umn.edu
> > > Subject: [mapserver-users] jagged edges on images
> > >
> > >
> > > Hello again
> > >
> > > I've been looking at some imagery being generated via PHP
> Mapscript.
> > > On my imagery , jagged effects appear along some of the edges. The
> > > jagged version from MapServer is attached. Look along the road
> > > boundaries and the word "Briar Patch". Anyone know why this happen=
s
> ?
> > > These effects don't appear when I view and zoom in and out of the
> > > source with ImageMagick. Here is the tiffinfo output. Note that I
> > > started with tiled Tifs and converted to stripped - I have played
> with
> >
> > > different sized strips.
> > >
> > > TIFF Directory at offset 0x1255d6
> > > Image Width: 3500 Image Length: 3500
> > > Bits/Sample: 8
> > > Compression Scheme: PackBits
> > > Photometric Interpretation: palette color (RGB from colormap)
> > > FillOrder: msb-to-lsb
> > > Document Name: "Standard Input"
> > > Image Description: "converted PNM file"
> > > Orientation: row 0 top, col 0 lhs
> > > Samples/Pixel: 1
> > > Rows/Strip: 2
> > > Planar Configuration: single image plane
> > > Color Map: (present)
> > >
> > > If anyone needs it, I can send the original one but I didn't want
> to
> > > waste too much bandwidth !
> > >
> > > Thanks
> > >
> > >
> > > Chris
> > >
> > >
> >
> >
> =20
>=20
>=20
>=20
--------------Boundary-00=_R9RPEHQ4GRES4WTFXFP0--