Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
High quality Jpeg
192 views
Skip to first unread message
Axel Berger
Dec 10, 2011, 8:53:48 AM12/10/11
to
For compatibilty I often use Ghostscript's ps2pdf14 on PDFs I get. This
usually works fine, makes files slightly bigger (or often enough much
smaller when written by substandard tools) and I can find no loss of
content or quality with one exception:
Images as Jpeg2000 are recoded as Jpeg, which is fine and just what's
wanted, but they are written at a very low quality setting. This makes
small files but terrible compression artefacts. If have read and reread
all documentation but could not find a way to tell Ghostscript to encode
those Jpegs at 90 or 95 % quality - they look something like 70 %.
Is there any command option I can use?
Danke
Axel
usually works fine, makes files slightly bigger (or often enough much
smaller when written by substandard tools) and I can find no loss of
content or quality with one exception:
Images as Jpeg2000 are recoded as Jpeg, which is fine and just what's
wanted, but they are written at a very low quality setting. This makes
small files but terrible compression artefacts. If have read and reread
all documentation but could not find a way to tell Ghostscript to encode
those Jpegs at 90 or 95 % quality - they look something like 70 %.
Is there any command option I can use?
Danke
Axel
ken
Dec 10, 2011, 10:20:28 AM12/10/11
to
In article <4EE3646C...@Gmx.De>, Axel....@Gmx.De says...
> Images as Jpeg2000 are recoded as Jpeg, which is fine and just what's
> wanted, but they are written at a very low quality setting. This makes
> small files but terrible compression artefacts. If have read and reread
> all documentation but could not find a way to tell Ghostscript to encode
> those Jpegs at 90 or 95 % quality - they look something like 70 %.
Don't encode them as JPEG, use Flate instead, JPEG compression on
already quantised data is really bad.
> Is there any command option I can use?
-dColorImageFilter=/FlateEncode -dGrayImageFilter=/FlateEncode
I would also reccomend using Ghostscript directly rather than using a
script (or batch file) in order to be sure that it does not set any
other controls (eg Image downsampling).
Ken
> Images as Jpeg2000 are recoded as Jpeg, which is fine and just what's
> wanted, but they are written at a very low quality setting. This makes
> small files but terrible compression artefacts. If have read and reread
> all documentation but could not find a way to tell Ghostscript to encode
> those Jpegs at 90 or 95 % quality - they look something like 70 %.
already quantised data is really bad.
> Is there any command option I can use?
I would also reccomend using Ghostscript directly rather than using a
script (or batch file) in order to be sure that it does not set any
other controls (eg Image downsampling).
Ken
Thomas Kaiser
Dec 10, 2011, 11:17:04 AM12/10/11
to
Axel Berger schrieb in <news:4EE3646C...@Gmx.De>
Regards,
Thomas
> If have read and reread all documentation but could not find a way to
> tell Ghostscript to encode those Jpegs at 90 or 95 % quality - they
> look something like 70 %.
>
> Is there any command option I can use?
Google for "ghostscript dctencode quality".
> tell Ghostscript to encode those Jpegs at 90 or 95 % quality - they
> look something like 70 %.
>
> Is there any command option I can use?
Regards,
Thomas
Axel Berger
Dec 11, 2011, 7:17:40 AM12/11/11
to
Thomas Kaiser wrote:
> Google for "ghostscript dctencode quality".
ken wrote:
> Google for "ghostscript dctencode quality".
> -dColorImageFilter=/FlateEncode -dGrayImageFilter=/FlateEncode
Thank you. Googling confirmed my suspicion of the default setting being
75% and came up with ken's solution too. It works, but there is a
problem:
ps2pdf14 normally leaves all raster graphics well alone and only touches
them when needed. Setting
-dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode
(the second without the first does nothing) converts all graphics
leading to huge files for no benefit. Some of the solutions found speak
of changing the quality factor for DCTEncode. This sounds right, I want
to leave what ps2pdf does and when it does it and only change how it
does it if and when. There is talk about an image parameter dictionary
but no details and nothing said about how and where to invoke it.
Danke
Axel
Thomas Kaiser
Dec 11, 2011, 8:26:07 AM12/11/11
to
Axel Berger schrieb in <news:4EE49F64...@Gmx.De>
would recommend defining an own preset like 'screen' or 'prepress' with
an optimized QFactor value and specify this preset on the command line
with -dPDFSETTINGS=/new-preset).
Or you could do it on the fly by using the -c switch:
gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
For details have a look at
http://www.ghostscript.com/doc/current/Ps2pdf.htm
Regards,
Thomas
> Some of the solutions found speak of changing the quality factor for
> DCTEncode. This sounds right, I want to leave what ps2pdf does and
> when it does it and only change how it does it if and when. There is
> talk about an image parameter dictionary but no details and nothing
> said about how and where to invoke it.
You could either adjust the default settings by altering gs_pdfwr.ps (I
> DCTEncode. This sounds right, I want to leave what ps2pdf does and
> when it does it and only change how it does it if and when. There is
> talk about an image parameter dictionary but no details and nothing
> said about how and where to invoke it.
would recommend defining an own preset like 'screen' or 'prepress' with
an optimized QFactor value and specify this preset on the command line
with -dPDFSETTINGS=/new-preset).
Or you could do it on the fly by using the -c switch:
gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
For details have a look at
http://www.ghostscript.com/doc/current/Ps2pdf.htm
Regards,
Thomas
Axel Berger
Dec 11, 2011, 4:06:32 PM12/11/11
to
Thomas Kaiser wrote:
> by altering gs_pdfwr.ps
There is no such file on my system. I had already tried a text search
for things like /QFactor without success. This is where I'd prefer to
go, if I could find the right place.
> -dPDFSETTINGS=/new-preset
This works, but it makes files bigger that already are PDF 1.4. ps2pdf14
normally leaves all images alone except those incompatible with version
1.4 and I want to keep it that way.
> Or you could do it on the fly by using the -c switch:
> gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
I tried that through the ps2pdf14.bat interface and it didn't work. I
may have to dig in, go through all those batches and make the complete
command line myself in the end.
I had read and reread that at least twenty times. Now, after the
twenty-first time, I also tried
-dDefaultRenderingIntent=/prepress
but that does nothing at all.
Danke
Axel
> by altering gs_pdfwr.ps
There is no such file on my system. I had already tried a text search
for things like /QFactor without success. This is where I'd prefer to
go, if I could find the right place.
> -dPDFSETTINGS=/new-preset
This works, but it makes files bigger that already are PDF 1.4. ps2pdf14
normally leaves all images alone except those incompatible with version
1.4 and I want to keep it that way.
> Or you could do it on the fly by using the -c switch:
> gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
may have to dig in, go through all those batches and make the complete
command line myself in the end.
I had read and reread that at least twenty times. Now, after the
twenty-first time, I also tried
-dDefaultRenderingIntent=/prepress
but that does nothing at all.
Danke
Axel
Thomas Kaiser
Dec 11, 2011, 5:32:31 PM12/11/11
to
Axel Berger schrieb in <news:4EE51B58...@Gmx.De>
Have you had a look inside gs's lib directory? Compare with
http://www.netzwelt.de/install-log/4016-ghostscript.html
>> -dPDFSETTINGS=/new-preset
>
> This works
This won't work unless you define a new preset in the file mentioned
above. Otherwise it will be silently ignored and defaults used.
>> Or you could do it on the fly by using the -c switch:
>> gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
>
> I tried that through the ps2pdf14.bat interface and it didn't work.
Sorry, no interest in Windows :-)
Regards,
Thomas
Have you had a look inside gs's lib directory? Compare with
http://www.netzwelt.de/install-log/4016-ghostscript.html
>> -dPDFSETTINGS=/new-preset
>
> This works
This won't work unless you define a new preset in the file mentioned
above. Otherwise it will be silently ignored and defaults used.
>> Or you could do it on the fly by using the -c switch:
>> gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
>
> I tried that through the ps2pdf14.bat interface and it didn't work.
Regards,
Thomas
ken
Dec 12, 2011, 2:55:40 AM12/12/11
to
In article <slrnjeabrv.193...@phg-online.de>,
Thomas...@phg-online.de says...
if the file exists (which depends on the distribution if this is Linux),
changing it will have no effect. You need to both modify the file *and*
tell Ghostscript to use the 'on-disk' files rather than the ROM files,
using the -I switch.
> >> Or you could do it on the fly by using the -c switch:
> >> gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
> >
> > I tried that through the ps2pdf14.bat interface and it didn't work.
>
> Sorry, no interest in Windows :-)
The same is quite likely also tru of the Linux script. For serious sue
of Ghostscript and pdfwrite, do not use the batch files.
Ken
Thomas...@phg-online.de says...
>
> Axel Berger schrieb in <news:4EE51B58...@Gmx.De>
> > Thomas Kaiser wrote:
> >> by altering gs_pdfwr.ps
> >
> > There is no such file on my system.
>
> Have you had a look inside gs's lib directory? Compare with
>
> http://www.netzwelt.de/install-log/4016-ghostscript.html
Ghostscript now builds all it support files into a ROM file system, even
> Axel Berger schrieb in <news:4EE51B58...@Gmx.De>
> > Thomas Kaiser wrote:
> >> by altering gs_pdfwr.ps
> >
> > There is no such file on my system.
>
> Have you had a look inside gs's lib directory? Compare with
>
> http://www.netzwelt.de/install-log/4016-ghostscript.html
if the file exists (which depends on the distribution if this is Linux),
changing it will have no effect. You need to both modify the file *and*
tell Ghostscript to use the 'on-disk' files rather than the ROM files,
using the -I switch.
> >> Or you could do it on the fly by using the -c switch:
> >> gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
> >
> > I tried that through the ps2pdf14.bat interface and it didn't work.
>
> Sorry, no interest in Windows :-)
of Ghostscript and pdfwrite, do not use the batch files.
Ken
Thomas Kaiser
Dec 12, 2011, 3:21:37 AM12/12/11
to
ken schrieb in <news:MPG.294fc3d9c...@usenet.plus.net>
quick tests (using the MacPorts version of GhostScript 9.0.4 on MacOS X)
and changed the QFactor value inside gs_pdfwr.ps which produced the
expected results:
-rw-r--r-- 1 tk tk 53927 11 Dez 14:05 test-neu-2.pdf
-rw-r--r-- 1 tk tk 64733 11 Dez 14:05 test-neu.pdf
-rw-r--r-- 1 tk tk 110735 11 Dez 14:04 test-normal.pdf
The original PDF contained just one single image in flate compression.
The results used DCTEncoding with different quality.
One more question: Does the build process takes care about keeping the
contents of the "ROM files" in sync with the files that will be
(possibly) distributed into the file system? Or might there be any side
effect of using the -I switch when I want to use the files in the FS
instead?
>> >> Or you could do it on the fly by using the -c switch:
>> >> gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
>> >
>> > I tried that through the ps2pdf14.bat interface and it didn't work.
>>
>> Sorry, no interest in Windows :-)
>
> The same is quite likely also tru of the Linux script.
MacOS X and Solaris. I use GhostScript on linux normally just for
checking something before filing bugreports (endianess and the like)
> For serious sue of Ghostscript and pdfwrite, do not use the batch
> files.
ACK, you are right.
Regards,
Thomas
> Thomas...@phg-online.de says...
>>
>> Axel Berger schrieb in <news:4EE51B58...@Gmx.De>
>> > Thomas Kaiser wrote:
>> >> by altering gs_pdfwr.ps
>> >
>> > There is no such file on my system.
>>
>> Have you had a look inside gs's lib directory? Compare with
>>
>> http://www.netzwelt.de/install-log/4016-ghostscript.html
>
> Ghostscript now builds all it support files into a ROM file system, even
> if the file exists (which depends on the distribution if this is Linux),
> changing it will have no effect. You need to both modify the file *and*
> tell Ghostscript to use the 'on-disk' files rather than the ROM files,
> using the -I switch.
Good to know... and obvisouly not true on every platform. I did three
>>
>> Axel Berger schrieb in <news:4EE51B58...@Gmx.De>
>> > Thomas Kaiser wrote:
>> >> by altering gs_pdfwr.ps
>> >
>> > There is no such file on my system.
>>
>> Have you had a look inside gs's lib directory? Compare with
>>
>> http://www.netzwelt.de/install-log/4016-ghostscript.html
>
> Ghostscript now builds all it support files into a ROM file system, even
> if the file exists (which depends on the distribution if this is Linux),
> changing it will have no effect. You need to both modify the file *and*
> tell Ghostscript to use the 'on-disk' files rather than the ROM files,
> using the -I switch.
quick tests (using the MacPorts version of GhostScript 9.0.4 on MacOS X)
and changed the QFactor value inside gs_pdfwr.ps which produced the
expected results:
-rw-r--r-- 1 tk tk 53927 11 Dez 14:05 test-neu-2.pdf
-rw-r--r-- 1 tk tk 64733 11 Dez 14:05 test-neu.pdf
-rw-r--r-- 1 tk tk 110735 11 Dez 14:04 test-normal.pdf
The original PDF contained just one single image in flate compression.
The results used DCTEncoding with different quality.
One more question: Does the build process takes care about keeping the
contents of the "ROM files" in sync with the files that will be
(possibly) distributed into the file system? Or might there be any side
effect of using the -I switch when I want to use the files in the FS
instead?
>> >> Or you could do it on the fly by using the -c switch:
>> >> gs ... -c '.setpdfwrite << //QFactor 0.15 ... >>' ...
>> >
>> > I tried that through the ps2pdf14.bat interface and it didn't work.
>>
>> Sorry, no interest in Windows :-)
>
> The same is quite likely also tru of the Linux script.
checking something before filing bugreports (endianess and the like)
> For serious sue of Ghostscript and pdfwrite, do not use the batch
> files.
Regards,
Thomas
Axel Berger
Dec 12, 2011, 4:32:06 AM12/12/11
to
Thomas Kaiser wrote:
> >> -dPDFSETTINGS=/new-preset
> > This works
> This won't work unless you define a new preset
Of course. What I meant is the command works, what I actually used was
> >> -dPDFSETTINGS=/new-preset
> > This works
> This won't work unless you define a new preset
/prepress.
> >> by altering gs_pdfwr.ps
> > There is no such file on my system.
> Have you had a look inside gs's lib directory?
directory of version 8.63. What I'm currently using is the binaries of
9.02 with the lib of 8.71. In 9.02 the format of the *.bat files is
changed incompatibly and won't run in my Win98SE.
So to sum up, getting good (or at least as good as the source) graphics
for the price of bigger files works fine in two different ways. What
that breaks is the leaving-alone of all images that already conform to
version 1.4. Ps2pdf14 as-is does just that and only converts the
incompatible ones.
> I did three quick tests (using the MacPorts version of
> GhostScript 9.0.4 on MacOS X) and changed the QFactor value
> inside gs_pdfwr.ps which produced the expected results:
>
> -rw-r--r-- 1 tk tk 53927 11 Dez 14:05 test-neu-2.pdf
> -rw-r--r-- 1 tk tk 64733 11 Dez 14:05 test-neu.pdf
> -rw-r--r-- 1 tk tk 110735 11 Dez 14:04 test-normal.pdf
through ps2pdf14 with the settings of test-normal.pdf, does it get
bigger? If yes, that's not what I'm looking for.
Danke
Axel
bugbear
Dec 12, 2011, 4:36:21 AM12/12/11
to
if only for google search terms:
sub mkpdf {
my ($dst, $ps) = @_;
# Valid values are in the range 0 to 1,000,000. A value less than 1
# improves image quality but decreases compression; a value greater than 1
# increases compression but degrades image quality. Default value: 1.0.
my $im_param = <<EOF;
<<
/AutoFilterGrayImages false
/GrayImageFilter /DCTEncode
/GrayImageDict << /QFactor 0.25 /Blend 1 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >>
/ColorImageFilter /DCTEncode
/ColorImageDict << /QFactor 0.25 /Blend 1 /HSamples [2 1 1 2] /VSamples [2 1 1 2] >>
/MonoImageFilter /CCITTFaxEncode
>> setdistillerparams
EOF
`gs -dCompatibilityLevel=1.2 -dSAFER -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite '-sOutputFile=$dst' -dSAFER -c .setpdfwrite '${im_param}' -f $ps`;
}
BugBear
Axel Berger
Dec 12, 2011, 4:55:17 AM12/12/11
to
bugbear wrote:
> You may find this fragment from one of my perl scripts helpful,
I do, inasmuch as it provides me with a complete working command line
> You may find this fragment from one of my perl scripts helpful,
for invoking gs directly. This has to be better than going through a
bunch of scripts I don't half understand in the first place. I think I
have found the culprit in the old gs_pdfwr.ps too. It seems to be this
line in the /default configuration and only there:
/Optimize false % override
Danke
Axel
Thomas Kaiser
Dec 12, 2011, 5:30:41 AM12/12/11
to
Axel Berger schrieb in <news:4EE5CA16...@Gmx.De>
just wanted to clarify where to look for if you want to adjust the
quality level of DCTEncoding within GhostScript (which shed some light
on interesting details due to Ken providing gs internals :-)
I don't understand your whole approach of running PDFs through ps2pdf14
and let JPEG2000 images being recompressed as JPEG (since this will
decrease image quality). Why don't you use PDF 1.5 instead (not altering
already JPEG2000 compressed content)?
Regards,
Thomas
> The real test is this: If you take your test-neu-2.pdf and run it
> through ps2pdf14 with the settings of test-normal.pdf, does it get
> bigger?
I don't care about ps2pdf14 at all (especially your .bat version). I
> through ps2pdf14 with the settings of test-normal.pdf, does it get
> bigger?
just wanted to clarify where to look for if you want to adjust the
quality level of DCTEncoding within GhostScript (which shed some light
on interesting details due to Ken providing gs internals :-)
I don't understand your whole approach of running PDFs through ps2pdf14
and let JPEG2000 images being recompressed as JPEG (since this will
decrease image quality). Why don't you use PDF 1.5 instead (not altering
already JPEG2000 compressed content)?
Regards,
Thomas
ken
Dec 12, 2011, 6:26:52 AM12/12/11
to
In article <slrnjebech.1af...@phg-online.de>,
Thomas...@phg-online.de says...
> Good to know... and obvisouly not true on every platform.
The code we dliver is the same on all platforms, but that doesn't stop
distributions from changing it....
> One more question: Does the build process takes care about keeping the
> contents of the "ROM files" in sync with the files that will be
> (possibly) distributed into the file system?
The ROM files are built from the files on disk. So we change the ROM
versions by altering the source files and rebuilding. Anyone building
from source shuld see the same.
> Or might there be any side
> effect of using the -I switch when I want to use the files in the FS
> instead?
If you use -I to point at different resource files, then all the
resource files found there will be used in preference to the ones in the
ROM file system. The search mechanism will proceed down its various
fallbacks when looking for files, so it will eventually find its way to
the ROM if no other source exists.
Ken
Thomas...@phg-online.de says...
> Good to know... and obvisouly not true on every platform.
distributions from changing it....
> One more question: Does the build process takes care about keeping the
> contents of the "ROM files" in sync with the files that will be
> (possibly) distributed into the file system?
versions by altering the source files and rebuilding. Anyone building
from source shuld see the same.
> Or might there be any side
> effect of using the -I switch when I want to use the files in the FS
> instead?
resource files found there will be used in preference to the ones in the
ROM file system. The search mechanism will proceed down its various
fallbacks when looking for files, so it will eventually find its way to
the ROM if no other source exists.
Ken
ken
Dec 12, 2011, 6:28:13 AM12/12/11
to
In article <4EE5CA16...@Gmx.De>, Axel....@Gmx.De says...
> So to sum up, getting good (or at least as good as the source)
graphics
> for the price of bigger files works fine in two different ways. What
> that breaks is the leaving-alone of all images that already conform to
> version 1.4.
That doesn't happen. *ALL* images are decompressed into a raw stream and
recompressed according to the various settings.
Ken
> So to sum up, getting good (or at least as good as the source)
graphics
> for the price of bigger files works fine in two different ways. What
> that breaks is the leaving-alone of all images that already conform to
> version 1.4.
recompressed according to the various settings.
Ken
ken
Dec 12, 2011, 6:30:03 AM12/12/11
to
In article <slrnjeblug.1c5...@phg-online.de>,
Thomas...@phg-online.de says...
> I don't understand your whole approach of running PDFs through
ps2pdf14
> and let JPEG2000 images being recompressed as JPEG (since this will
> decrease image quality). Why don't you use PDF 1.5 instead (not altering
> already JPEG2000 compressed content)?
On GS+pdfwrite the JPEG2000 image *will* still be converted. JPEG2000
encoders are not free, there are royalties to be paid on the coder.
Ken
Thomas...@phg-online.de says...
> I don't understand your whole approach of running PDFs through
ps2pdf14
> and let JPEG2000 images being recompressed as JPEG (since this will
> decrease image quality). Why don't you use PDF 1.5 instead (not altering
> already JPEG2000 compressed content)?
encoders are not free, there are royalties to be paid on the coder.
Ken
Thomas Kaiser
Dec 12, 2011, 7:40:50 AM12/12/11
to
ken wrote in <news:MPG.294ff6188...@usenet.plus.net>
called PassThroughJPEG2000Images? Adobe introduced a decade ago the
PassThroughJPEGImages distiller parameter to prevent recompression of
DCT encoded image contents. Would be nice if the way gs handles already
compressed images changes in the future. But if section 3.8 in
http://ghostscript.com/doc/current/Projects.htm
is still valid this is not that easy?
Regards,
Thomas
> Thomas...@phg-online.de says...
>
>> I don't understand your whole approach of running PDFs through
>> ps2pdf14 and let JPEG2000 images being recompressed as JPEG (since
>> this will decrease image quality). Why don't you use PDF 1.5 instead
>> (not altering already JPEG2000 compressed content)?
>
> On GS+pdfwrite the JPEG2000 image *will* still be converted. JPEG2000
> encoders are not free, there are royalties to be paid on the coder.
Understood. So maybe it would be a good idea to implement a parameter
>
>> I don't understand your whole approach of running PDFs through
>> ps2pdf14 and let JPEG2000 images being recompressed as JPEG (since
>> this will decrease image quality). Why don't you use PDF 1.5 instead
>> (not altering already JPEG2000 compressed content)?
>
> On GS+pdfwrite the JPEG2000 image *will* still be converted. JPEG2000
> encoders are not free, there are royalties to be paid on the coder.
called PassThroughJPEG2000Images? Adobe introduced a decade ago the
PassThroughJPEGImages distiller parameter to prevent recompression of
DCT encoded image contents. Would be nice if the way gs handles already
compressed images changes in the future. But if section 3.8 in
http://ghostscript.com/doc/current/Projects.htm
is still valid this is not that easy?
Regards,
Thomas
bugbear
Dec 12, 2011, 9:04:26 AM12/12/11
to
http://pages.cs.wisc.edu/~ghost/doc/AFPL/6.50/Ps2pdf.htm
It names a large number of control parameters,
and points to the "official" Adobe document
describing their semantics.
BugBear
ken
Dec 12, 2011, 4:48:35 PM12/12/11
to
In article <slrnjebtii.20t...@phg-online.de>,
Thomas...@phg-online.de says...
> Understood. So maybe it would be a good idea to implement a parameter
> called PassThroughJPEG2000Images?
There's already an open enhancement request, no idea when/if it will get
done.
> is still valid this is not that easy?
No, its not easy. In fact its not currently possible.
Ken
Thomas...@phg-online.de says...
> Understood. So maybe it would be a good idea to implement a parameter
> called PassThroughJPEG2000Images?
done.
> is still valid this is not that easy?
Ken
0 new messages