Red Hat Bugzilla – Bug 166460
image displays in eog, but prints mostly grey
Last modified: 2008-04-09 01:11:55 EDT
Description of problem: The attached image fails to print correctly. Colors all wrong. Prints OK after convertion to .png using gimp. Image looks OK in eog and gimp. Version-Release number of selected component (if applicable): desktop-printing-0.19-2 How reproducible: 100% Steps to Reproduce: 1.lpr sickles_4c_logo.jpg 2. 3. Actual results: Expected results: Ability to print jpg images Additional info:
Created attachment 117957 [details] logo, possibly generated with Adobe Photoshop 7.0
*** Bug 166461 has been marked as a duplicate of this bug. ***
Are you still seeing this problem?
Yes, problem still exists on fully-updated fedora-8 Note: I saved the attachement from #1, but needed to: mv attachment.cgi sickles_4c_logo.jpg to reproduce the test case. My printer is an: HP Officejet_Pro_K550
Please attach the PPD file you are using (/etc/cups/ppd/<queuename>.ppd).
Created attachment 296141 [details] /etc/cups/ppd/Officejet_Pro_K550.ppd
Created attachment 296176 [details] output of /usr/lib/cups/filter/imagetops filter This is the output of the CUPS imagetops filter. It shows the incorrect colours, so the problem lies in imagetops (part of CUPS) or one of its dependencies.
Here's the debug output of that filter. DEBUG: Page = 595x842; 10,36 to 585,833 DEBUG: num_components = 4 DEBUG: jpeg_color_space = JCS_YCCK DEBUG: Converting image to CMYK... DEBUG: JPEG image 750x931x4, 128x128 PPI DEBUG: Before scaling: xppi=128, yppi=128, zoom=0.00 DEBUG: Before scaling: xprint=8.0, yprint=11.1 DEBUG: Image size is 5.9 x 7.3 inches... DEBUG: Auto orientation... DEBUG: xpages = 1x5.86in, ypages = 1x7.27in DEBUG: XPosition=0, YPosition=0, Orientation=0 DEBUG: xprint=6, yprint=7 DEBUG: PageLeft=10, PageRight=585, PageWidth=595 DEBUG: PageBottom=36, PageTop=833, PageLength=842 DEBUG: left=86.56, top=696.34 INFO: Printing page 1...
Reported upstream.
Fix has been committed upstream and will be in 1.3.7.
cups-1.3.6-3.fc8 has been submitted as an update for Fedora 8
cups-1.3.6-3.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update cups'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-2131
cups-1.3.6-3.fc8 doesn't fix the problem, but perhaps thats because #10 says the fix will be in 1.3.7 ?
No, it's because the back-ported fix doesn't work for some reason. OK, thanks for testing.
I've had another look at this, and 1.3.6-3.fc8 fixes the problem that I could originally see. With the new package I get a correct representation of the jpg file in PostScript, whereas I saw wrong colours before. If you have a separate print server, the updated package needs to be installed on the print server not the client. Can you please double-check that you are still seeing the problem with 1.3.6-3.fc8, and attach a test case if different from the attachment in comment #1? Thanks.
I thought I had responded to this already, sorry. I retested with the same tests case from #1, on an fc8 x86_64 platform with the printer directly attached (USB). I still see the same problem when printing with "lpr". Printing from "eog" results in more reasonable colors. using: cups-1.3.6-3.fc8.x86_64 Is there a way I can save the .ps generated by lpr to a file?
Created attachment 299921 [details] imagetops.ps lpr doesn't generate PostScript output itself; it submits the file as-is to CUPS, which applies the imagetops and pstops filters to it because of its file type. I've attached the output I get on Fedora 8, x86_64, with cups-1.3.6-3.fc8, from this command: PPD=Officejet_Pro_K550.ppd / /usr/lib/cups/filter/imagetops 1 tim '' 1 '' < \ sickles_4c_logo.jpg >imagetops.ps It looks correct to me when viewing it with evince. Please try printing it with 'lpr imagetops.ps' and tell me if that gives you correct or incorrect paper output.
(You will shortly see a comment here from Fedora Update System about an updated package -- please ignore that comment.)
Created attachment 300009 [details] image produced locally by imagetops filter
Your version of imagetops from #17 printed ok, using: lpr imagetops.ps Running the command in #17 produced the result in #19, still wrong
If we're running the same command on the same architecture with the same inputs and getting different outputs, either something in the environment is different or they are different executables. What do these commands say?: rpm -q cups cups-libs rpm -V cups sha1sum /usr/lib/cups/filter/imagetops
root@bock:~# rpm -q cups cups-libs cups-1.3.6-3.fc8.x86_64 cups-libs-1.3.6-2.fc8.x86_64 cups-libs-1.3.6-2.fc8.i386 root@bock:~# rpm -V cups S.5....T c /etc/cups/classes.conf S.5....T c /etc/cups/cupsd.conf S.5....T c /etc/cups/printers.conf root@bock:~# sha1sum /usr/lib/cups/filter/imagetops f001ff94625d98213b9b9e4d2bb950700022af74 /usr/lib/cups/filter/imagetops
Created attachment 300052 [details] filter-through-imageps.tar.gz Here is the complete test case I am using. Please try it like this: tar zxf filter-through-imageps.tar.gz cd filter-through-imageps ./filter-through-imageps.sh evince imagetops.ps What result do you get?
evince shows the bad image. the console shows: ellson@bock:~> tar zxf filter-through-imageps.tar.gz ellson@bock:~> cd filter-through-imageps/ ellson@bock:filter-through-imageps> ./filter-through-imageps.sh DEBUG: imagetoraster - copying to temp print file "/tmp/47f380546b059" DEBUG: Page = 595x842; 10,36 to 585,833 DEBUG: num_components = 4 DEBUG: jpeg_color_space = JCS_YCCK DEBUG: Converting image to CMYK... DEBUG: JPEG image 750x931x4, 128x128 PPI DEBUG: Before scaling: xppi=128, yppi=128, zoom=0.00 DEBUG: Before scaling: xprint=8.0, yprint=11.1 DEBUG: Image size is 5.9 x 7.3 inches... DEBUG: Auto orientation... DEBUG: xpages = 1x5.86in, ypages = 1x7.27in DEBUG: XPosition=0, YPosition=0, Orientation=0 DEBUG: xprint=6, yprint=7 DEBUG: PageLeft=10, PageRight=585, PageWidth=595 DEBUG: PageBottom=36, PageTop=833, PageLength=842 DEBUG: left=86.56, top=696.34 INFO: Printing page 1... ellson@bock:filter-through-imageps> evince imagetops.ps
I think this is an fc8 only issue. I get good images on 2 different rawhide machines, x86_64 and i386 i get bad images on 3 different fc8 machines, 2 x86_64 and 1 i386 There is a different version of cups, and /usr/lib/cups/filter/imagetops, on rawhide: root@ontap:~# rpm -q cups cups-libs cups-1.3.6-7.fc9.x86_64 cups-libs-1.3.6-7.fc9.x86_64 cups-libs-1.3.6-7.fc9.i386 root@ontap:~# rpm -V cups S.5....T c /etc/cups/printers.conf SM5....T c /etc/cups/subscriptions.conf root@ontap:~# sha1sum /usr/lib/cups/filter/imagetops 28012257a23d2e35cb62fdc2fe0dba97e1e30894 /usr/lib/cups/filter/imagetops Could cups-1.3.6-7 be pushed to fc8?
No -- for one thing, the devel packages will break non-UTF-8 clients. Besides, it's no good just masking the problem if we can't identify what it is. The only code differences between F-8 and devel are: * don't patch out strict UTF-8 requirement * fix compilation against newer glibc * allow log rotation to be performed by external program No, I think the clue is in the output from imagetops. Here is the output I get from cups-1.3.6-3.fc8: DEBUG: imagetoraster - copying to temp print file "/tmp/47f3a03d68ed0" DEBUG: Page = 595x842; 10,36 to 585,833 DEBUG: Adobe CMYK JPEG detected (inverting color values) DEBUG: num_components = 4 DEBUG: jpeg_color_space = JCS_YCCK DEBUG: Converting image to CMYK... DEBUG: JPEG image 750x931x4, 128x128 PPI DEBUG: Before scaling: xppi=128, yppi=128, zoom=0.00 DEBUG: Before scaling: xprint=8.0, yprint=11.1 DEBUG: Image size is 5.9 x 7.3 inches... DEBUG: Auto orientation... DEBUG: xpages = 1x5.86in, ypages = 1x7.27in DEBUG: XPosition=0, YPosition=0, Orientation=0 DEBUG: xprint=6, yprint=7 DEBUG: PageLeft=10, PageRight=585, PageWidth=595 DEBUG: PageBottom=36, PageTop=833, PageLength=842 DEBUG: left=86.56, top=696.34 INFO: Printing page 1... I'm not sure why imagetops on my system would decide to invert the colours, whereas yours won't -- however, we have already verified that the binary is the same so let's try comparing shared library dependencies. What do you get for 'ldd /usr/lib/cups/filter/imagetops', and for 'rpm -q libjpeg'? Here's what I get: $ ldd /usr/lib/cups/filter/imagetops linux-vdso.so.1 => (0x00007fff727fd000) libcupsimage.so.2 => /usr/lib64/libcupsimage.so.2 (0x00002aaaaaed0000) libcups.so.2 => /usr/lib64/libcups.so.2 (0x00002aaaab0e7000) libgnutls.so.13 => /usr/lib64/libgnutls.so.13 (0x00002aaaab31e000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab5a1000) libm.so.6 => /lib64/libm.so.6 (0x00002aaaab7bc000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaaba3f000) libaudit.so.0 => /lib64/libaudit.so.0 (0x00002aaaabc78000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaabe8d000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaac0a8000) libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00002aaaac400000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002aaaac659000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaac87d000) libz.so.1 => /lib64/libz.so.1 (0x00002aaaaca9f000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaaccb3000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaacee1000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaad174000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaad399000) libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00002aaaad59b000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00002aaaad7e9000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaacb4000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaad9ec000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaadbf1000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaaddf9000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaadffb000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaae211000) $ rpm -q libjpeg libjpeg-6b-39.fc8 libjpeg-6b-39.fc8
ellson@bock:~> ldd /usr/lib/cups/filter/imagetops linux-vdso.so.1 => (0x00007fffafdfe000) libcupsimage.so.2 => /usr/lib64/libcupsimage.so.2 (0x00002aaaaaed0000) libcups.so.2 => /usr/lib64/libcups.so.2 (0x00002aaaab0e7000) libgnutls.so.13 => /usr/lib64/libgnutls.so.13 (0x00002aaaab31e000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00002aaaab5a1000) libm.so.6 => /lib64/libm.so.6 (0x00002aaaab7bc000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002aaaaba3f000) libaudit.so.0 => /lib64/libaudit.so.0 (0x00002aaaabc78000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002aaaabe8d000) libc.so.6 => /lib64/libc.so.6 (0x00002aaaac0a8000) libtiff.so.3 => /usr/lib64/libtiff.so.3 (0x00002aaaac400000) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00002aaaac659000) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00002aaaac87d000) libz.so.1 => /lib64/libz.so.1 (0x00002aaaaca9f000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002aaaaccb3000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaacee1000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaad174000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002aaaad399000) libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00002aaaad59b000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00002aaaad7e9000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaacb4000) libdl.so.2 => /lib64/libdl.so.2 (0x00002aaaad9ec000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaadbf1000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002aaaaddf9000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002aaaadffb000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00002aaaae211000) ellson@bock:~> rpm -q libjpeg libjpeg-6b-39.fc8.x86_64 libjpeg-6b-39.fc8.i386
Is it related to the gcc issue? Is your fc8 system totally vanilla? I get the same problem, consistently on 4 fc8 systems that I've tried, so I don't understand how it can be working for you? Is your gcc upgraded beyond fc8? Did you build your own cups or libjpeg rpms?
OK, the fix went into filter/image-jpeg.c, in libcupsimage.so, which is linked from /usr/lib/cups/filter/imagetops libcupsimage.so comes from cups-libs, which is 1.3.6-2 on my system. I need cups-libs-1.3.6-3 which has not been distributed. Perhaps you made it available earlier in updates-testing, but the instructions in #12 didn't grab cups-libs in addition to cups. cups*1.3.6-3 seems to have gone now.
Ah, I should have spotted that from comment #22, sorry. I'll fix the main package to require an exact match for the libs package, and in future updating just 'cups' will pull in the correct libs packages.
cups-1.3.6-4.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.