[gs-bugs] [Bug 692286] Image too light -- not fully opaque

bugzilla-daemon at ghostscript.com bugzilla-daemon at ghostscript.com
Fri Jun 17 06:05:27 UTC 2011


http://bugs.ghostscript.com/show_bug.cgi?id=692286

--- Comment #2 from Michael Vrhel <michael.vrhel at artifex.com> 2011-06-17 06:05:26 UTC ---
Digging further on the clist writing side I am starting to track things down.  

There is a gs_begin_transparency group that occurs.  In
pdf14_clist_create_compositor we find ourselves at line 6400 where we do a call
to update the parameters before we start the group.  You can catch this nicely
by putting a break point at line 6555 in pdf14_clist_update_params,  where we
wait for the detection of a change in opacity.  You will see the opacity set to
0.44000199.  The value is stored in the parameters in c_pdf14trans_write line
5025 (another good breakpoint spot).

Now the bounding box on this group is computed in gxclimag.c line 963 where we
do a call to get_cropping.   The computation actually occurs in
c_pdf14trans_get_cropping around line 7218.   We end up with a bounding box
that is x=1599 y=293  to x=1948  y=611.  Now if you compare that to our image
that is not getting correctly drawn, you will note that we intersect into the y
range with this group, but not with the x range.  We end up doing the push of
the blend parameters at this point across the same bands as the group which is
bands 3 through 7.  So this is why we are setting the alpha value in the group.
 The question for me is now, how is it that the top part of the image (likely
in band 6) is escaping this opacity setting of 0.44 while band 7 is getting hit
with it (both are in the Y range of the blend parameters).  There is likely
another setting of the blend parameters that is not making it to band 7 (a
conjecture at this time).

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.


More information about the gs-bugs mailing list