Home → TileMill →

Raster scaling artifacts (possible bug)

Admin Functions

• Remove

gregor

27 Sep, 2012 04:35 PM

I have a RGBA tiff with two values: 0,0,0,0 and 196,223,246,255. When I add any raster-scaling other than near I get unexpected artifacts like the attached screenshot, which was with raster-scaling: bilinear; (the only other style applied is raster-opacity: 1). Maybe I should be expecting these artifacts?

• tilemill_raster_scaling.png 66.9 KB

1. 2 Posted by gregor on 27 Sep, 2012 04:46 PM

   

   I realised that perhaps I should have been expecting those artifacts if the transparent background was essentially black with an alpha of 0. I tried again with the background set to 255,255,255,0 but this time got even stranger (and definitely unexpected) artifacts.

   • tilemill_raster_scaling_2.png 58.1 KB

   Admin Functions

   • Split
   • Remove

2. Support Staff 3 Posted by Dane on 27 Sep, 2012 04:58 PM

   

   Hi Gregor,

   Can you post your raster input data so I can replicate? If it is big please clip out just a small chunk (as small as possible). But, before posting please make sure you can still replicate the problem. Thanks!

   Dane

   Admin Functions

   • Echo
   • Remove

3. 4 Posted by gregor on 27 Sep, 2012 10:38 PM

   

   Here is a chunk that still shows the problem.

   • test.tif 30.8 KB

   Admin Functions

   • Split
   • Remove

4. Support Staff 5 Posted by Dane on 28 Sep, 2012 02:22 AM

   

   Thanks. Definitely a bug. I'm going to close this ticket and will track at the mapnik site: https://github.com/mapnik/mapnik/issues/1508

   Admin Functions

   • Echo
   • Remove

5. Dane closed this discussion on 28 Sep, 2012 02:22 AM.

6. gregor re-opened this discussion on 28 Sep, 2012 03:27 AM

7. 6 Posted by gregor on 28 Sep, 2012 03:27 AM

   

   Were you able to replicate the different artifacts that I showed in the second image? That looked like a different problem to the grey banding.

   Admin Functions

   • Split
   • Remove

8. Support Staff 7 Posted by Dane on 28 Sep, 2012 05:42 PM

   

   That second image appears broken for some reason. But, yes, I saw them as well.

   Can you explain where this image originally came from and the whole set of steps you used to create it?

   Admin Functions

   • Echo
   • Remove

9. 8 Posted by gregor on 28 Sep, 2012 05:57 PM

   

   This image is derived from the MODIS Water Mask. I created it by building a VRT from the MODIS tiles, then manually adding a palette to the VRT:

   <ColorInterp>Palette</ColorInterp>
   <ColorTable>
       <Entry c1="255" c2="255" c3="255" c4="0"/>
       <Entry c1="196" c2="223" c3="246" c4="255"/>
   </ColorTable>
   

   Then I created a RGBa Tiff with gdal_translate -expand rgba in.vrt out.tif

   Note, when I created the file with 0,0,0,0 as the first entry I got the grey boundaries, when I used 255,255,255,0 I got the strange artifacts.

   Admin Functions

   • Split
   • Remove

10. Support Staff 9 Posted by Dane on 28 Sep, 2012 06:13 PM

    

    Okay, thanks for the details. The problem is basically that somewhere along that path the image is becoming "premultiplied" which means that the alpha value is stored within each rgb channel (e.g. by multiplying the rgb by the alpha value). Premultiplied alpha is necessary for image blending, so Mapnik also premultiplies the image after reading it from GDAL (it's this double multiplication which is creating the gray fringing). Currently GDAL provides no way to know if alpha is already premultiplied, and its been this way for many years: http://trac.osgeo.org/gdal/ticket/2279.

    So, the obvious solution is to not premultiply the image. However, based on your steps its not obvious to me how the image is actually getting premultiplied.

    Admin Functions

    • Echo
    • Remove

11. 10 Posted by gregor on 28 Sep, 2012 06:43 PM

    

    I can't figure out how it is premultiplying either. Could this be something to do with the gdal_translate command? I see that the bands in my tif have the flag PER_DATASET ALPHA set, is that related? In case it helps troubleshoot, here is a crop of the original tif from MODIS.

    • test_raw.tif 751.4 KB

    Admin Functions

    • Split
    • Remove

12. 11 Posted by gregor on 29 Sep, 2012 03:19 AM

    

    I have at least tracked down when the premultiplication is happening: the raw tiff (with values 0 for land, 1 for water) is fine. A VRT of the tiff, with -vrtnodata 0 works as expected. Changing <ColorInterp> to palette is what causes the problem. Even if I only use RGB values (rather than RGBa):

    <Entry c1="0" c2="0" c3="0" />
    <Entry c1="196" c2="223" c3="246" />
    

    When I look at the VRT in Tilemill (before running gdal_translate -expand rgb) I still get the artifacts.

    I'm not sure how to reclassify my 0,1 values in my original raster without using a color palette, without using some other piece of GIS software (which I was trying to avoid).

    My original idea was to use comp-op to colorize the raster, but I want this layer on top of other layers (hence my other question about grouping comp-ops) so that is not possible.

    Any other ideas for solutions?

    Admin Functions

    • Split
    • Remove

13. Support Staff 12 Posted by Dane on 10 Oct, 2012 08:35 PM

    

    Gregor,

    This bug should now be fixed in the latest mapnik/tilemill. Can you test? You can find the latest development builds at https://github.com/mapbox/tilemill/downloads

    Admin Functions

    • Echo
    • Remove

14. Support Staff 13 Posted by Dane on 20 Oct, 2012 08:59 PM

    

    Gregor,

    Have you had a chance to upgrade to see if this is fixed for you?

    Dane

    Admin Functions

    • Echo
    • Remove

15. 14 Posted by gregor on 21 Oct, 2012 08:17 AM

    

    Hi Dane,

    I've been travelling and got a harddrive failure when away. Going to have to restore next week and I'll be able to test. Thanks for following up, I'll let you know as soon as I can test.

    Gregor

    Admin Functions

    • Split
    • Remove

16. Support Staff 15 Posted by Dane on 21 Oct, 2012 04:04 PM

    

    Gregor,

    Shoot, sorry to hear that! No hurry then :) I'm pretty sure this issue is fixed now, so I'm going to close this up. Just re-open a new issue for anything else you might hit along the way.

    Dane

    Admin Functions

    • Echo
    • Remove

17. Dane closed this discussion on 21 Oct, 2012 04:04 PM.

Comments are currently closed for this discussion. You can start a new one.