2

I am trying to produce some high quality 8bpp bmp from pdf file with ghostscript. For that purpose, I use the bmp256 device.

So far, everything works well and is really fast, but ghostscript use halftoning to dither the image, leading to some uggly patterns when zooming on the picture :

enter image description here

I've managed to reduce their size by playing with the -dDITHERPPI flag, but this is still not satisfying enough. Those are too regular and are too easily spotted, even with little zoom.

Instead of using halftone, I would like to use some error diffusion algorithm, like the Floyd–Steinberg one. I found this algorithm is implemented on other devices, but they are all printer related devices, so I can't really use them.

Plus, I need to be as fast as possible when converting the PDF to 8bpp BMP, and the outputed pictures are very large: so converting it to 24 or 32bpp BMP in the first place to dither it later with another tool is excluded.

I already downloaded the source to try to implement it myself, but the project is really big and complex and I don't know how and where to start.

Is there any way to use some error diffusion algorithm with ghostscript without having to implement it myself ?

If no, is there a prefered way for extending ghostscript ? Any guideline ?

Blablablabli
  • 174
  • 9
  • That's a halftone screen and is the standard method for downgrading colour on printers supporting PostScript. Ghostscript does have alternative methods, you can look at ETS which is a form os stochastic screening, but I have no idea if it works with the bmp device. Alternatively you can create a higher colour depth output and simply post-process. Consider ImageMagick. – KenS Jun 16 '16 at 07:04
  • Other than that you would need to write your own device in order to take the higher colour depth bitmap and crop it down to a lower colour depth. This is a non-trivial task and will require a good C programmer. – KenS Jun 16 '16 at 07:07
  • @KenS I can't use ImageMagick or make some postprocess from a higher depth picture, it's too slow for my needs. I am going to try to implement a new device myself. Do you have some tips or some leads on where/how to start ? – Blablablabli Jun 16 '16 at 07:56
  • Alternatively, do you know if I can get the resulting output not be writted to the disk but hold it in RAM to retrieve it without having to make those useless read and write operations ? Maybe I can tricks it with a pipe ? – Blablablabli Jun 16 '16 at 08:04
  • I'd start by looking at the source for the an existing device, ppmraw maybe, or one of the TIFF devices. You can have GS send the data to you via stdout, so you could deal with it that way. Obviously the rendered image is in RAM (provided there is enough RAM to hold the page in memory) so its available to you. All that most devices do is repackage it in a file format. Do please read the AGPL licence before you embark on writing any device code! – KenS Jun 16 '16 at 10:17
  • Okay, thanks a lot ! – Blablablabli Jun 16 '16 at 12:11

0 Answers0