Bug 687327 - gs 8.14, ps2epsi fails on too "red" images
Summary: gs 8.14, ps2epsi fails on too "red" images
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Color (show other bugs)
Version: 8.14
Hardware: Sun Solaris
: P3 normal
Assignee: Michael Vrhel
URL:
Keywords: bountiable
Depends on:
Blocks:
 
Reported: 2004-02-27 08:47 UTC by Hans Werner Strube
Modified: 2011-08-01 03:49 UTC (History)
5 users (show)

See Also:
Customer:
Word Size: ---


Attachments
PS file with 12 equal red text lines (4.23 KB, application/postscript)
2004-03-03 09:11 UTC, Hans Werner Strube
Details
PS file with 12 text lines of different color (4.24 KB, application/postscript)
2004-03-03 09:13 UTC, Hans Werner Strube
Details
PS file with 12 text lines of different color (4.24 KB, application/postscript)
2004-03-03 09:17 UTC, Hans Werner Strube
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Werner Strube 2004-02-27 08:47:02 UTC
Although the core dump and preview bugs of ps2epsi (e.g., 686909)
have been fixed in gs 8.14, there are ps files which fail in
the preview part, outputting the message "blank page!!".
The resulting epsi file then lacks the whole initial part up to
(and including) the %%EndPreview line.
The first example I found contained nothing but several equal lines
of red text, made by xfig. Manually editing this and other files,
I found that the bug occurs whenever all parts of the image
have a "red" component equal to 1 (the green and blue values are
unimportant): these are treated as "white" in the bitmap.
If other colors are present (which prevent total failure), the
BoundingBox may be too small, if such "red=1" colors were present
near the margin.
Thus the color quantization of the preview bitmap seems to be
the reason.
Comment 1 Hans Werner Strube 2004-03-01 08:28:34 UTC
The bug is not due to the color quantization but to the color-to-gray
conversion. Closer inspection of the preview bitmap shows that the gray
value is simply formed from the red-component value alone, completely
neglecting the green and blue components.
It would not help to use "bg" and "bb" in addition to "br" for a better
gray estimate in src/gdevmem.c, mem_mapped_map_rgb_color(), "Gray scale
conversion", since bg and bb have no reasonable values there. Obviously,
the color-to-gray conversion happens somewhere before the call to
mem_mapped_map_rgb_color().

When the lib/ps2epsi.ps from gs8.14 is used with gs7.04, it works correctly!
Comment 2 Jack Moffitt 2004-03-03 08:40:56 UTC
Please attach the sample files that you are trying to convert.
Comment 3 Hans Werner Strube 2004-03-03 09:11:09 UTC
Created attachment 520 [details]
PS file with 12 equal red text lines

Here is a PS file with all red text content. Will be treated as blank
(all white) by ps2epsi of 8.14.
Comment 4 Hans Werner Strube 2004-03-03 09:13:35 UTC
Created attachment 521 [details]
PS file with 12 text lines of different color

This is hand-edited from the previous attachment "allred.ps", showing
the effect of different colors. All text with red component 1 is treated
like white in the preview (gray) bitmap, thus the bounding box is too
small and the epsi file truncated.
Comment 5 Hans Werner Strube 2004-03-03 09:17:59 UTC
Created attachment 522 [details]
PS file with 12 text lines of different color

Correction: the last two lines of attachment 521 [details] should read
"RGB: 1 0 0"; here comes a correction.
Comment 6 Hin-Tak Leung 2005-08-03 07:00:54 UTC
Took a quick look with gs 8.51 - the submitted description of the bug is 
somewhat vague and incorrect. The problem here is that ghostscript doesn't 
seen to be able to calculate the bounding box parameter in the DSC comment, 
nor generate the embedded eps preview bitmap. 
Comment 7 Hans Werner Strube 2005-08-03 07:47:57 UTC
The incorrect bounding box or - in the extreme case - a totally missing 
("blank") preview bitmap are what I realized first, too. But from my described
experiments I concluded that these effects are *caused* by the misintepretation
of red as white and ignoring the green and blue components. Thus an all-red
image is seen as "blank." What is "vague" here?
Comment 8 Hin-Tak Leung 2005-08-03 08:05:29 UTC
(comment 7) - my comment 6 was mostly referring to comment 1 being 
misleading. The boundbox and preview are both calculated in 
lib/ps2epsi.ps.
Comment 9 Timothy Osborn 2007-08-15 05:37:43 UTC
I have verified that this problem still occurs in the latest build (r8191).
Comment 10 Ken Sharp 2008-03-10 10:45:13 UTC
The actual problem is with the memory device (gsdevmem.c), when set to produce
gray scale output (gdevmem.c & gdevm8.c).

The device sets dev->color_info.num_components to 1, interestingly the memory
device's mem_mapped_map_rgb_color method uses the num_components field to decide
whether its getting an RGB or gray scale value from the interpreter. This seems
odd to me, since it has already set num_components to 1, it will never see RGB
values...

Indeed, this is the problem, gxcmap.c determines that the device has set
num_components to 1 and so, on receiving a RGB colour, only passes the red
component to it (this too seems 'odd' behaviour to me, surely this should
converrt to gray ?). Since we only ever see the red component, we can only ever
use this for conversion to the palette (effectively gray scale). Whenever R=255
this means we set the gray value to 0, white, no matter what the other channel
values.

A simple fix in gsdevmem.c, gs_initialize_wordimagedevice, removing the code
which sets the num_components field to 1 works for me, but this is not my area
and I'm unsure what side-effects this might have. 

As this is not really a ps2epsi problem, but really a colour problem, or
possibly a bug in the memory device, I'm re-assigning it to Ralph (having
checked with him first).

Comment 11 Masaki Ushizaka 2009-08-18 04:32:27 UTC
Reproduced with r9999 on Ubuntu 9.04.
Comment 12 Jeff Nowakowski 2011-02-12 15:39:25 UTC
I'm starting work on this as part of the bounty program.
Comment 13 Ray Johnston 2011-02-12 16:43:00 UTC
The first thing to do is to see if this is still a problem -- GPL Ghostscript
9.01 was released last week. 9.00 introduced an entirely new color pipeline
(ICC profile based), and 9.01 includes some fixes/refinement of parts of it.
Comment 14 Jeff Nowakowski 2011-02-12 18:00:28 UTC
I confirmed that this bug still exists with the 9.01 release on my Debian system. I also confirmed that it works in 7.04, as indicated in the original report, on my Debian system.
Comment 15 Shailesh Mistry 2011-07-10 19:05:34 UTC
Please can you confirm the command line and options you are using to reproduce this bug.
Comment 16 Alex Cherepanov 2011-08-01 03:49:53 UTC
Ghostscript works correctly since v. 9.00.
Current development version is also OK.