Bug 688990 - imagemask interpolation doesn't quite match Adobe
imagemask interpolation doesn't quite match Adobe
Status: IN_PROGRESS
Product: Ghostscript
Classification: Unclassified
Component: Graphics Library
master
All All
: P5 enhancement
Assigned To: Michael Vrhel
Bug traffic
: bountiable
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-11 13:25 PST by Raph Levien
Modified: 2011-07-19 19:36 PDT (History)
3 users (show)

See Also:
Customer:
Word Size: ---


Attachments
test case for analyzing Adobe imagemask interpolation (222.70 KB, application/octet-stream)
2006-11-11 13:28 PST, Raph Levien
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Raph Levien 2006-11-11 13:25:24 PST
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
results.

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
appreciated.

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.
Comment 1 Raph Levien 2006-11-11 13:28:18 PST
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.
Comment 2 Dan Coby 2006-11-11 21:09:13 PST
Raph,

What format is the file that you attached to this bug report?
Comment 3 Raph Levien 2006-11-11 21:11:30 PST
Sorry, it's a .tar.bz2 file. I should have realized that the bug tracker strips
out the name of the file.
Comment 4 Joel R. Voss 2007-05-02 10:11:16 PDT
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 
this.
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 
mc68k.

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.

Comment 5 Henry Stiles 2008-02-26 11:36:30 PST
retest and reassign.
Comment 6 Ray Johnston 2008-08-21 13:52:23 PDT
A VERY low priority issue since this is 'implementation dependent'
Comment 7 Shailesh Mistry 2011-07-19 19:36:48 PDT
Enhancement still missing in Ghostscript 9.03