How to tell ghostscript to leave bitmap images alone?

[T3X]

Hi,

When I run a .ps or .pdf file through ghostscript, all bitmap images
are recommpressed and their quality drops visibly (although, the file
size remains roughly the same). By trial and error I found out that
the following options prevent that (but at a price of much bigger
file):

-dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode

How can I tell ghostscript not to touch bitmap images at all and make
use of what's in the original file without any reencoding?

Thanks in advance,

Tomek

[Helge Blischke]

T3X wrote:

Use

-dDownsampleColorImages=false \
-dDownsampleGrayImages=false \
-dDownsampleMonoImages=false \
-dColorImageFilter=/FlateEncode \
-dGrayImageFilter=/FlageEncode \
-dMonoImageFilter=/CCITTFaxEncode

Or better you take one of the distiller parameters file from Adobe Acrobat
and tweak it to your needs.

Thus the images will not be degraded though they get recompressed.

Helge

[David Kastrup]

T3X <t34...@googlemail.com> writes:

Not at all. If you feel like finishing some mostly done work from Szabo
Peter (author of sam2p), requiring some PostScript and C programming, I
can send you what he came up with after a conference. If I find all the
requisite files.

The basic idea was to replace the _decoding_ filters in PostScript/PDF
by code that just writes out the raw data to external files instead of
decoding it, and have a postprocessor reinsert the stuff. The
pswrite/pdfwrite back ends themselves can't write already coded stuff as
images, they will always reencode.

I think that the PostScript part was pretty much done, at least as
proof-of-concept, but the postprocessor wasn't. I think that sam2p or
some other utility could be gutted for that as well, but no idea.
Anyway, there still remains a nontrivial amount of work to be done, but
it should be worth doing that. I think not even Adobe's Acrobat itself
offers a way around reencoding.

--
David Kastrup
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>

[Helge Blischke]

David Kastrup wrote:

Be aware that in PostScript images can have many different data sources
besides the "usual" currentfile. And, be aware that there is no simple means
of cerbatim copying the image data, as the end of data condition depends
on the compression method used.
But what I suggested earlier - letting gs decompress the image data from
the input and recompressing it lossless (!) should at least result in
identical appearence when displayed or printed.

Helge

[David Kastrup]

Helge Blischke <h.bli...@acm.org> writes:

> David Kastrup wrote:
>
>> The basic idea was to replace the _decoding_ filters in
>> PostScript/PDF by code that just writes out the raw data to external
>> files instead of decoding it, and have a postprocessor reinsert the
>> stuff. The pswrite/pdfwrite back ends themselves can't write already
>> coded stuff as images, they will always reencode.
>>
>> I think that the PostScript part was pretty much done, at least as
>> proof-of-concept, but the postprocessor wasn't. I think that sam2p or
>> some other utility could be gutted for that as well, but no idea.
>> Anyway, there still remains a nontrivial amount of work to be done, but
>> it should be worth doing that. I think not even Adobe's Acrobat itself
>> offers a way around reencoding.
>>
>
> Be aware that in PostScript images can have many different data
> sources besides the "usual" currentfile.

The idea was to replace the image decoding filters, not the data
decoding filters. So the data source is not relevant since the data is
intercepted after the data retrieval stage.

> But what I suggested earlier - letting gs decompress the image data
> from the input and recompressing it lossless (!) should at least
> result in identical appearence when displayed or printed.

Sure, but that's horribly expensive in disk space. I should know, since
the company I worked with was responsible for pushing PDFTeX's 4GB PDF
size limit to 10GB. Exactly because that's the way we had to settle on.

[T3X]

On Sep 10, 2:55 pm, Helge Blischke <h.blisc...@acm.org> wrote:
> Use
>
> -dDownsampleColorImages=false \
> -dDownsampleGrayImages=false \
> -dDownsampleMonoImages=false \
> -dColorImageFilter=/FlateEncode \
> -dGrayImageFilter=/FlageEncode \
> -dMonoImageFilter=/CCITTFaxEncode

And

-dAutoFilterColorImages=false
-dAutoFilterGrayImages=false

or this doesn't work. However, /FlateEncode leads to significant file
size increase as I mentioned above.

Cheers,

Tomek

[T3X]

Thanks for this information, but I'm afraid that programming
PostSctipt filters and postprocessors is way out of my league.

Some more googling around pointed me to /PassThroughJPEGImages
introduced in Acrobat 6. Too bad that GS does not support this, I will
have to do with /FlateEncode

Cheers,

Tomek