When a transfer function is used by a device, or an ExtGState, colors in images can be wrong due to the transfer function being applied more than once. I will attach a simplified test case for this, but this was originally from customer 532 with a PDF ATS file WWTW61EC_PDFACT.pdf (a version of the QL ATS produced using "PDF Factory". In the reduced file, without a transfer function, the colors on the left and right parts match, but when a transfer function is used that "lightens" the colors, the right rectangle is much lighter. If a clist is in place, this only occurs in bands that have transparency. Depending on the source image, the transfer function may be applied when the image is processed and then again when the pdf14 compositor uses the image method to perform the pdf14_put_image when the pdf14 device is popped.
Created attachment 11578 [details] Bug695904.pdf File that has a TR at the start. The colors on the left and right of the small dark rectangle should be the same. Very evident with banding, eg.: gswin32c -sDEVICE=pgmraw -o xt.pgm -dMaxBitmap=10 -dBandHeight=128 Bug695904.pdf
Created attachment 11579 [details] TF.ps Transfer function that can be used for testing as well. eg.: gswin32c -sDEVICE=pgmraw -o x.pgm -dMaxBitmap=0 -dBandHeight=128 TF.ps \ Bug695904.pdf
Fixed in commit 64188c8e3615de788ad916b7d14e24e98d9c289c and sent to the customer as a patch to their code. Note that the fix does *NOT* address the arcane handling of transfer functions as described in PDF 1.7 Ref Manual section 7.6.4. A new, enhancement bug will be opened to track that issue, but it is not a customer issue (yet). Since it has worked this way for so long, I doubt it will be an issue for customers any time soon.