Bugzilla – Bug 688990
imagemask interpolation doesn't quite match Adobe
Last modified: 2011-07-19 19:36:48 PDT
Ghostscript now implements imagemask interpolation, internally done with the
/Imscale filter, which outputs a bitmap with 4 times the horizontal and vertical
resolution of its input. However, the results don't exactly match Adobe.
The current implementation is based on a 4x4 window of source pixels, addressing
a lookup table. This gives results that are fairly close to Adobe's
implementation, but not quite. On further analysis of test images, it looks like
even a 5x5 window is not adequate to exactly predict the Adobe interpolation
A Python script generating all 4x4 combinations is attached to this bug, as well
as the results from an Adobe interpreter. The current results are probably "good
enough," but if anyone can figure out the actual logic used, that would be much
Keep in mind that the algorithm was initially implemented on an 8 MHz 68000
family processor, to make 75 dpi MacPaint bitmap images print more smoothly on
the then brand-new Apple LaserWriter. This suggests that the actual algorithm
must be fairly simple and not too expensive in CPU or memory.
Created attachment 2597 [details]
test case for analyzing Adobe imagemask interpolation
imm2.py generates the test file used to render the resulting images. The four
pbm files are the pages generated, in order. Rendering is 600dpi, so each pixel
from the interpolation filter is actually rendered as a 2x2 block.
What format is the file that you attached to this bug report?
Sorry, it's a .tar.bz2 file. I should have realized that the bug tracker strips
out the name of the file.
I am a freelance developer working on the this bug. I am working towards the
bounty. My plan is to work in my off time in the next 1-2 weeks to finish
My code converts the output of Ghostscript to 90% correlation to the Adobe
pbms. My code does uses the same tables as Raphs code, no more. My code runs
in 120 ms per page (not counting i/o) and would probably do fine on a 8 MHz
I will be modifying the zoom_line function in simscale.c to concur with my
code. I will ensure that the code is not dependent on resolution. The Adobe
pattern does not change on a lower level than 300 dpi, so my code will also
not change the pattern at any lower level.
retest and reassign.
A VERY low priority issue since this is 'implementation dependent'
Enhancement still missing in Ghostscript 9.03