[Geoserver-users] jags in rasters when transforming projection

Hi,

I came across with a problem of using paletted images in different projection. I have geotiffs' (8-bit paletted) in 2393 and 2394 projections. When I use 2393 projected raster in projection 2394, the result is an image with a jagged edge (see the attachment). I think that the color of the jags is the color of the palette index 0. The number and size of the jags depends on the zoom level. Maybe it is tied up on the tile size?

Should I use 24-bit images instead? These are color reduced images having only a couple of dozens colors.

mika

(Geoserver 1.6.3)

jags.jpg

I tested 24-bit image. This time the jagged (or serrated) edge is black. Is this a bug or what’s going on? You can check this by your own. Please, be my guest.

http://karjala.digikartta.net/kartat/index.html

mika

P.S. Also the rendering is quite terrible, although the original material isn’t so perfect either (made before the Second World War).

Lehtonen, Mika kirjoitti:

Lehtonen, Mika ha scritto:

I tested 24-bit image. This time the jagged (or serrated) edge is black. Is this a bug or what's going on? You can check this by your own. Please, be my guest.

http://karjala.digikartta.net/kartat/index.html

mika

P.S. Also the rendering is quite terrible, although the original material isn't so perfect either (made before the Second World War).

Mika, can you open a jira issue about this one?
Also, we'll need some sample data to reproduce and the wms calls
that do force the projection. If you can, attach
it to the jira issue, if you cannot, send the data by private mail.

Cheers
Andrea

Lehtonen, Mika ha scritto:

I tested 24-bit image. This time the jagged (or serrated) edge is black. Is this a bug or what's going on? You can check this by your own. Please, be my guest.

http://karjala.digikartta.net/kartat/index.html

mika

P.S. Also the rendering is quite terrible, although the original material isn't so perfect either (made before the Second World War).

Hi Lehtonen,
I've looked at the data you gave me but I cannot reproduce
neither the bad rendering nor the jagged result.
I've attached a screenshots with the data you gave me, I've
just configured it, no special tricks.
Maybe whatever bug you're seeing has already been solved?
Try a 1.6.x nightly and tell me if it works anything
better for you:
http://gridlock.openplans.org/geoserver/1.6.x/geoserver-1.6.x-latest-war.zip

Cheers
Andrea

previewOne.jpg

Hi Andrea,

rendering looks satisfactory but is this a case of 2393 projected image in a 2394 projection? Images supposed to be little rotated from the horizontal line. These are not. Please take a look again at my site.

mika

Andrea Aime kirjoitti:

Lehtonen, Mika ha scritto:

Hi Andrea,

rendering looks satisfactory but is this a case of 2393 projected image in a 2394 projection? Images supposed to be little rotated from the horizontal line. These are not. Please take a look again at my site.

Ah sorry. New screenshot, the problem with the edge is that
the reprojection is using black as the background color instead of
transparent, and I'm not sure why (Simone, don't you think the image
reprojection should use a fully transparent background instead?).
But the image quality is a lot better than the one you have, probably
due to a fix I have and you have not.

If you set up an image mosaic lik in http://geoserver.org/display/GEOSDOC/Using+the+ImageMosaic+plugin you'll
at least avoid the black borders inside the map, and you can setup
the ExpandToRGB=true property in the mosaic property file to get
good results. Simone, I remember the black background issue can
be solved by setting up a property, but I don't remember which one
(and is the property available on 1.6.x or only on trunk?)

Cheers
Andrea

Andrea Aime ha scritto:

Lehtonen, Mika ha scritto:

Hi Andrea,

rendering looks satisfactory but is this a case of 2393 projected image in a 2394 projection? Images supposed to be little rotated from the horizontal line. These are not. Please take a look again at my site.

Ah sorry. New screenshot, the problem with the edge is that
the reprojection is using black as the background color instead of
transparent, and I'm not sure why (Simone, don't you think the image
reprojection should use a fully transparent background instead?).

Eh, this time with screenshot all right
Cheers
Andrea

mosaic.jpeg

I did that but this approach has new problems. See the screenshot.

This makes the map appearence slow and not completed. Parts of the mosaic are missing depending on the zoom level. Try it yourself. You can find the new candidate in the previous address.

mika

Andrea Aime kirjoitti:

If you set up an image mosaic lik in http://geoserver.org/display/GEOSDOC/Using+the+ImageMosaic+plugin you'll
at least avoid the black borders inside the map, and you can setup
the ExpandToRGB=true property in the mosaic property file to get
good results. Simone, I remember the black background issue can
be solved by setting up a property, but I don't remember which one
(and is the property available on 1.6.x or only on trunk?)

Cheers
Andrea

mosaic-test.jpg

Hi Andrea,

I was just wondering, beacuse I haven't still got this problem resolved, is the situation same in the1.7 alpha? You were right about the better rendering in the latest version, but black jags still remain. And mosaic, which wouldn't even fully remove the problem, seems to be working "limping". For some reason it's slow and don't show the whole map. I can't figure out why. Wrong type of rasters?

mika

Andrea Aime kirjoitti:

Lehtonen, Mika ha scritto:

Hi Andrea,

rendering looks satisfactory but is this a case of 2393 projected image in a 2394 projection? Images supposed to be little rotated from the horizontal line. These are not. Please take a look again at my site.

Ah sorry. New screenshot, the problem with the edge is that
the reprojection is using black as the background color instead of
transparent, and I'm not sure why (Simone, don't you think the image
reprojection should use a fully transparent background instead?).
But the image quality is a lot better than the one you have, probably
due to a fix I have and you have not.

If you set up an image mosaic lik in http://geoserver.org/display/GEOSDOC/Using+the+ImageMosaic+plugin you'll
at least avoid the black borders inside the map, and you can setup
the ExpandToRGB=true property in the mosaic property file to get
good results. Simone, I remember the black background issue can
be solved by setting up a property, but I don't remember which one
(and is the property available on 1.6.x or only on trunk?)

Cheers
Andrea

Ciao Mika,
sorry to chime in late into the discusion. Could you please do a quick
summary of what kind of data you playing with?

Simone.

On Thu, May 15, 2008 at 10:29 AM, Lehtonen, Mika <mika@anonymised.com> wrote:

Hi Andrea,

I was just wondering, beacuse I haven't still got this problem resolved, is
the situation same in the1.7 alpha? You were right about the better
rendering in the latest version, but black jags still remain. And mosaic,
which wouldn't even fully remove the problem, seems to be working "limping".
For some reason it's slow and don't show the whole map. I can't figure out
why. Wrong type of rasters?

mika

Andrea Aime kirjoitti:

Lehtonen, Mika ha scritto:

Hi Andrea,

rendering looks satisfactory but is this a case of 2393 projected image
in a 2394 projection? Images supposed to be little rotated from the
horizontal line. These are not. Please take a look again at my site.

Ah sorry. New screenshot, the problem with the edge is that
the reprojection is using black as the background color instead of
transparent, and I'm not sure why (Simone, don't you think the image
reprojection should use a fully transparent background instead?).
But the image quality is a lot better than the one you have, probably
due to a fix I have and you have not.

If you set up an image mosaic lik in
http://geoserver.org/display/GEOSDOC/Using+the+ImageMosaic+plugin you'll
at least avoid the black borders inside the map, and you can setup
the ExpandToRGB=true property in the mosaic property file to get
good results. Simone, I remember the black background issue can
be solved by setting up a property, but I don't remember which one
(and is the property available on 1.6.x or only on trunk?)

Cheers
Andrea

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

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

http://www.geo-solutions.it

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

Ok,

take a look at this site:

http://karjala.digikartta.net/kartat/index.html

On the right there are two rasters projected into 2394. On the left there should me two rasters projected into 2393. In this approach the left ones are inside a mosaic, which obviously isn't working. I have tried both paletted and 24-bit mode. Actually in this particular case one is paletted, another one 24-bit. Maybe it has something to do with a non functioning mosaic? Rasters are Geotiffs' all.
Anyway mosaic or not, the main concern are the jags in the reprojected raster (those which are rotated). They can't be accepted, not in any case.

- mika -

Simone Giannecchini kirjoitti:

Ciao Mika,
sorry to chime in late into the discusion. Could you please do a quick
summary of what kind of data you playing with?

Simone.

On Thu, May 15, 2008 at 10:29 AM, Lehtonen, Mika <mika@anonymised.com> wrote:
  

Hi Andrea,

I was just wondering, beacuse I haven't still got this problem resolved, is
the situation same in the1.7 alpha? You were right about the better
rendering in the latest version, but black jags still remain. And mosaic,
which wouldn't even fully remove the problem, seems to be working "limping".
For some reason it's slow and don't show the whole map. I can't figure out
why. Wrong type of rasters?

mika

Andrea Aime kirjoitti:
    

Lehtonen, Mika ha scritto:
      

Hi Andrea,

rendering looks satisfactory but is this a case of 2393 projected image
in a 2394 projection? Images supposed to be little rotated from the
horizontal line. These are not. Please take a look again at my site.
        

Ah sorry. New screenshot, the problem with the edge is that
the reprojection is using black as the background color instead of
transparent, and I'm not sure why (Simone, don't you think the image
reprojection should use a fully transparent background instead?).
But the image quality is a lot better than the one you have, probably
due to a fix I have and you have not.

If you set up an image mosaic lik in
http://geoserver.org/display/GEOSDOC/Using+the+ImageMosaic+plugin you'll
at least avoid the black borders inside the map, and you can setup
the ExpandToRGB=true property in the mosaic property file to get
good results. Simone, I remember the black background issue can
be solved by setting up a property, but I don't remember which one
(and is the property available on 1.6.x or only on trunk?)

Cheers
Andrea
      

Here you go with another example. This time there are no mosaic, just four separate geotiffs'.

http://karjala.digikartta.net/kartat/index2.html

- mika -

Simone Giannecchini kirjoitti:

Ciao Mika,
sorry to chime in late into the discusion. Could you please do a quick
summary of what kind of data you playing with?

Simone.

On Thu, May 15, 2008 at 10:29 AM, Lehtonen, Mika <mika@anonymised.com> wrote:
  

Hi Andrea,

I was just wondering, beacuse I haven't still got this problem resolved, is
the situation same in the1.7 alpha? You were right about the better
rendering in the latest version, but black jags still remain. And mosaic,
which wouldn't even fully remove the problem, seems to be working "limping".
For some reason it's slow and don't show the whole map. I can't figure out
why. Wrong type of rasters?

mika

Andrea Aime kirjoitti:
    

Lehtonen, Mika ha scritto:
      

Hi Andrea,

rendering looks satisfactory but is this a case of 2393 projected image
in a 2394 projection? Images supposed to be little rotated from the
horizontal line. These are not. Please take a look again at my site.
        

Ah sorry. New screenshot, the problem with the edge is that
the reprojection is using black as the background color instead of
transparent, and I'm not sure why (Simone, don't you think the image
reprojection should use a fully transparent background instead?).
But the image quality is a lot better than the one you have, probably
due to a fix I have and you have not.

If you set up an image mosaic lik in
http://geoserver.org/display/GEOSDOC/Using+the+ImageMosaic+plugin you'll
at least avoid the black borders inside the map, and you can setup
the ExpandToRGB=true property in the mosaic property file to get
good results. Simone, I remember the black background issue can
be solved by setting up a property, but I don't remember which one
(and is the property available on 1.6.x or only on trunk?)

Cheers
Andrea
      

On Thu, May 15, 2008 at 11:16 AM, Lehtonen, Mika <mika@anonymised.com> wrote:

Ok,

take a look at this site:

http://karjala.digikartta.net/kartat/index.html

Looking at it right now....

On the right there are two rasters projected into 2394. On the left there
should me two rasters projected into 2393. In this approach the left ones
are inside a mosaic, which obviously isn't working.

Sorry to not understand, but what exactly is not working :slight_smile: ? What
kind original data are you using (a gdalinfo could help)? How did you
prepared them?

Simone.
(you can point me to a previous email in nabble if you already gave this info)

I have tried both
paletted and 24-bit mode. Actually in this particular case one is paletted,
another one 24-bit. Maybe it has something to do with a non functioning
mosaic? Rasters are Geotiffs' all.
Anyway mosaic or not, the main concern are the jags in the reprojected
raster (those which are rotated). They can't be accepted, not in any case.

- mika -

Simone Giannecchini kirjoitti:

Ciao Mika,
sorry to chime in late into the discusion. Could you please do a quick
summary of what kind of data you playing with?

Simone.

On Thu, May 15, 2008 at 10:29 AM, Lehtonen, Mika <mika@anonymised.com>
wrote:

Hi Andrea,

I was just wondering, beacuse I haven't still got this problem resolved,
is
the situation same in the1.7 alpha? You were right about the better
rendering in the latest version, but black jags still remain. And mosaic,
which wouldn't even fully remove the problem, seems to be working
"limping".
For some reason it's slow and don't show the whole map. I can't figure
out
why. Wrong type of rasters?

mika

Andrea Aime kirjoitti:

Lehtonen, Mika ha scritto:

Hi Andrea,

rendering looks satisfactory but is this a case of 2393 projected image
in a 2394 projection? Images supposed to be little rotated from the
horizontal line. These are not. Please take a look again at my site.

Ah sorry. New screenshot, the problem with the edge is that
the reprojection is using black as the background color instead of
transparent, and I'm not sure why (Simone, don't you think the image
reprojection should use a fully transparent background instead?).
But the image quality is a lot better than the one you have, probably
due to a fix I have and you have not.

If you set up an image mosaic lik in
http://geoserver.org/display/GEOSDOC/Using+the+ImageMosaic+plugin you'll
at least avoid the black borders inside the map, and you can setup
the ExpandToRGB=true property in the mosaic property file to get
good results. Simone, I remember the black background issue can
be solved by setting up a property, but I don't remember which one
(and is the property available on 1.6.x or only on trunk?)

Cheers
Andrea

--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

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

http://www.geo-solutions.it

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

....   Sorry to not understand, but what exactly is not working :-) ? What
kind original data are you using (a gdalinfo could help)? How did you
prepared them? .....

Isn’t obvious? =-O

Those jags or whatever you’d like to call them, overlapping with the map and making wedges into the map edges (am I poetic? :wink: ).

Take a look at the attachment (jags2.jpg).

mika

P.S. Andrea Aime has my files, if they still exist. Please consult him with this.

Simone Giannecchini kirjoitti:

jags2.jpg

Simone wrote:

Sorry to not understand, but what exactly is not working :slight_smile:
? What kind original data are you using (a gdalinfo could
help)? How did you prepared them

For me the situation looks like following:

Individual images when they are warped are getting some colour value for
the triangel shaped areas in the warped image presenting the nodata
area. I mean with nodata areas those areas that do not have any image
information in the original images in native projection.
Now the example image sent by Mika seems to me that there are several
warped image tiles presented together, but the nodata areas are not
transparent. In the ultimate boundaries of the resulting mosaic the
nodata values are visible as they are, at the image boundaries nodata
area is covering the real data of the underlying image.
It seems as well like the nodata value is different for different
originals. Perhaps this happens because original images are paletted.
On the other hand I remember like Mika had tried several image formats.

In MapServer this kind of situation is handled by defining an offsite
colour value in the layer definitions. That colour will be used for
filling the offdata triangles. With another parameter this same offsite
value is made transparent at map level, so the triangles will not be
visible in the final result. I have no idea about how to handle this
with GeoServer, or this is the real problem here.

-Jukka Rahkonen-

Hi,

I was just wondering how come in the mosaic tutorial, at the end, the first outcome is without colored margins and the latter one has margins? Follow these links please:
http://geoserver.org/download/attachments/1278191/result.gif
http://geoserver.org/download/attachments/1278191/result2.gif
Or is it just so that the first one has white margins?
In my opinion, it is mandatory to have a setting which defines the color of the outside area of the warped (reprojected) map or defines it to be transparent. From my point of view, having a reprojection possibility for coverages is almost useless without that option.
Does this have something to do with the alpha channel? I mean should I define some transparent value in GDAL? Also, I noticed there are some transparency settings in the mosaic coverage editor (input/output transparency). I am afraid, that I am asking something too obvious here? But really I can’t get rid of those jags. And on the other hand, I don’t won’t to make anything on the map area to be transparent.

mika

Rahkonen Jukka kirjoitti:

I set the mosaic coverage editor setting of ‘OutputTransparentColor’ into rgb(0,0,0) and get rid of the jags, fine! But still… does it mean that also all the rgb(0,0,0) pixels will be transparent on the map area?
Also, as a continuation for this method, would it be applicable to single images? I mean, if I set ‘dstnodata’ into rgb(0,0,0) in GDAL as well. What do you think about the idea?
Mosaic seems to be little slower than separate geotiffs’ with overviews. True? Should one set some pyramids in order to make it faster? I only have two files in the mosaic and it keeps me waiting… :frowning:
http://karjala.digikartta.net/kartat/index.html

mika

Lehtonen, Mika kirjoitti:

Lehtonen, Mika ha scritto:
...

Mosaic seems to be little slower than separate geotiffs' with overviews. True? Should one set some pyramids in order to make it faster? I only have two files in the mosaic and it keeps me waiting.. :frowning: http://karjala.digikartta.net/kartat/index.html

I cannot answer about the transparency part, but for the speed one,
in the mosaic overview get a different treatment you should
be aware of:
* all tiles in the mosaic must have the same overview levels
* the overview resolutions must be declared in the properties file
   in order to be used, the reader won't scan each file to figure them
   out (some mosaics are made of thousands of images.

An example property file for a multiresolution mosaic:
Name=aerial
Levels=0.5,0.5 1,1 2,2 4,4 8,8 16,16 32,32 64,64
LevelsNum=8
Envelope2D=7627042.500000,682550.000000 7659510.500000,714891.000000
NumFiles=144

Hope this helps
Cheers
Andrea

All right,

I see. The explanation in the mosaic plugin tutorial was misleading:

The values for “Levels” can be gathered by inspecting the output from gdalinfo (HINT: read the absolute values from the “Pixel Size” line):
gdalinfo passA2006260173532.tif
where the line of interest reads:
Pixel Size = (10000.000000000000000,-10000.000000000000000)
Note that the values for the “Levels” parameter should be positive, since our goal is to describe the cell size in SRS units in the x and y directions.

So should I put there something which is derived from 2 by multiplying or dividing it or something which is derived from the real pixel size? I am now a little bit of confused…

mika

Andrea Aime kirjoitti:

ok,

I put the real pixel size and doubled it and once again doubled it; that is three levels. Seems to be doing the trick. The mosaic is much faster now and opens tiles on the fly.

mika

Andrea Aime kirjoitti:

Lehtonen, Mika ha scritto:
...

Mosaic seems to be little slower than separate geotiffs' with overviews. True? Should one set some pyramids in order to make it faster? I only have two files in the mosaic and it keeps me waiting.. :frowning: http://karjala.digikartta.net/kartat/index.html

I cannot answer about the transparency part, but for the speed one,
in the mosaic overview get a different treatment you should
be aware of:
* all tiles in the mosaic must have the same overview levels
* the overview resolutions must be declared in the properties file
  in order to be used, the reader won't scan each file to figure them
  out (some mosaics are made of thousands of images.

An example property file for a multiresolution mosaic:
Name=aerial
Levels=0.5,0.5 1,1 2,2 4,4 8,8 16,16 32,32 64,64
LevelsNum=8
Envelope2D=7627042.500000,682550.000000 7659510.500000,714891.000000
NumFiles=144

Hope this helps
Cheers
Andrea