Running this quick test:
im = mapnik.Image.open('tests/data/raster/white-alpha.tiff')
pixel = im.get_pixel(0,0)
alpha = (pixel >> 24) & 0xff
red = pixel & 0xff
green = (pixel >> 8) & 0xff
blue = (pixel >> 16) & 0xff
print '%s,%s,%s,%s' % (red,green,blue,alpha)
shows that the rgba for this tiff is rgba(255,255,255,102). This pretty clearly looks like non or un premultiplied pixels. However the tiff reports the tag:
$ tiffinfo tests/data/raster/white-alpha.tiff | grep alpha
Extra Samples: 1<assoc-alpha>
assoc-alpha means the pixels should be premultiplied as per http://www.awaresystems.be/imaging/tiff/tifftags/extrasamples.html, but they are not.
going to rename this image to white-alpha-assoc-alpha-wrong.tiff and will create a new replacement that does not report premultiplied alpha by creating a png with mapnik then converting to a tiff using image magick as per #1510. NOTE: I tried converting the tiff with image magick like:
convert -define tiff:alpha=unassociated tests/data/raster/white-alpha.tiff tests/data/raster/white-alpha-assoc-alpha-wrong.tiff
But that command also multiplied the pixels, which we don't want (just want to change the tag).
more test fixes to set up to enforce desired behavior around tiff and…
… premultiplied alpha in source files - refs #1508 and #1511
in 2714bdc fixed up tests so that we can now test expected behavior for a fixed version of this image and still the broken one. The broken on is causing failures for the raster.input after 77e5858, which is where we start checking for the premultiplied status of the source image. Now, remaining task is to be able to have user control over premultiplied status of the image so we can get the tests passing again for this broken image. See #1512. closing.