While testing my proposed fix for Bug #688210 I discovered that psdrgb no longer generates rgb data for page bitmaps. The data looks completely off. For instance, the first line of the red plane of tiger.eps’s background at 72dpi is: 31 6a 00 60 00 60 00 60 00 70 00 70 00 70 a1 53 e9 06 01 00 00 00 00 00 00 0f d8 01 00 00 00 00 04 50 02 78 45 52 e2 f8 03 50 03 50 f5 52 02 78 28 52 05 78 ff 77 09 50 01 50 04 78 02 78 09 50 e9 05 06 00 00 00 00 00 0e 0f d8 01 00 00 00 00 f1 52 00 70 00 70 00 70 d7 d8 e1 56 88 d0 cb f2 50 6a 00 60 00 60 00 60 00 70 00 70 00 70 36 f8 e9 05 0e 00 00 00 00 00 28 0f d8 01 00 00 00 00 e9 06 04 00 00 00 00 00 58 0f d8 01 00 00 00 00 06 50 00 70 00 70 00 70 02 78 f4 51 e9 56 08 50 58 6a 00 60 00 60 00 60 79 04 03 00 00 00 00 00 38 10 d8 01 00 00 00 00 79 06 03 00 00 00 00 00 68 10 d8 01 00 00 00 00 01 0b 60 0a 00 00 00 00 02 00 00 00 00 00 00 00 01 0b 60 0a 00 00 00 00 02 00 00 00 00 00 00 00 01 08 60 0a 00 00 00 00 c8 ad ce 01 00 00 00 00 00 0c 60 0a 00 00 00 00 00 00 00 00 00 00 00 00 d0 14 00 00 10 03 00 00 40 6b 9f 00 00 00 00 00 01 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e9 06 04 00 ff ff ff ff 90 0f d8 01 00 00 00 00 e9 06 04 00 ff ff ff ff 90 0f d8 01 00 00 00 00 01 70 5a d3 fe d2 00 70 30 6a 00 60 00 60 00 60 04 50 04 78 01 50 04 50 00 78 04 78 f4 52 03 50 01 78 05 78 ff 77 09 50 f6 52 00 70 00 70 00 70 04 50 08 78 01 50 04 50 00 78 00 78 04 78 02 78 09 50 24 50 04 50 08 50 04 50 08 50 00 70 00 70 04 50 00 70 00 70 00 70 38 6a 00 60 00 60 00 60 03 50 00 78 22 50 7f 78 01 50 f6 52 02 78 07 50 ff 78 55 53 02 78 07 50 01 0b 40 0a ff 7f 00 00 fb ff 00 00 00 00 00 00 81 0f 55 03 01 00 00 00 40 ba 54 00 00 00 00 00 81 0f 50 03 01 00 00 00 3f bc 54 00 00 00 00 00 e9 06 0d 00 00 00 00 00 70 10 d8 01 00 00 00 00 e9 06 0e 00 00 00 00 00 90 10 d8 01 00 00 00 00 06 50 04 50 03 50 f8 77 51 53 04 50 ff 78 50 53 22 50 01 78 50 53 00 78 81 0f 52 03 01 00 00 00 fc b7 54 00 00 00 00 00 e9 06 01 00 00 00 00 00 b0 10 d8 01 00 00 00 00 05 50 02 78 07 50 03 78 03 78 ff 77 09 50 f6 52 01 78 07 50 02 78 03 78 ff 77 09 50 the green and blue planes look similar. (That used to match the pcre: /^(D6 ){612}$/ as of gs 9.05.) It might be a memory corruption issue. The psdcmyk device, OTOH, works perfectly.
(Note: I'm testing this on master as of e21f69e10d; the two changes since should not be relevant to psd.) After compiling with: :; ./autogen.sh ; ./configure --with-x --with-drivers=ALL CFLAGS='-O0 -g3 -march=native' ; make debug ; make I ran: :; for ij in psd{rgb,cmyk}; do ./debugbin/gs -sDEVICE=${ij} -sOutputFile=tiger.${ij} -dBATCH -dNOPAUSE examples/tiger.eps ; done The tiger.psdcmyk was fine but the tiger.psdrgb had corrupted output as I described in the opening comment. Debugging shows that the octets in the output match what the values that psd_write_image_data() gets from unpacked = params.data[data_pos]; (around line 1350), so the bug occurs in gx_downscaler_get_bits_rectangle().
I see the bug. The code does: memcpy(unpacked, sep_line, xc->width); to copy each line from unpacked to sep_line, but memcpy takes: void *memcpy(void *dest, const void *src, size_t n); so it is actually copying uninitialized data from sep_line to unpacked. I’ll attach a patch.
Created attachment 8621 [details] Fix psdrgb. Commit 60640aeb33 got the arguments to memcpy(3) backwards.
With that patch (which does indeed look correct), I get a completely black output.
Yes, it is black. But that is because gx_downscaler_get_bits_rectangle() returns an all-zero buffer. Which it gets from mem_planar_get_bits_rectangle().
I have a fix - just testing it now.
Fixed in: commit fad17657f6f583dbdef5a634d0f11dd79e446ffe Author: Robin Watts <robin.watts@artifex.com> Date: Fri May 25 17:55:31 2012 +0100 Bug 693070: psdrgb wasn't giving corrupted output. There were actually 2 bugs in here. The first one was spotted and fixed by James Cloos - many thanks; the arguments to memcpy were reversed. The second one was to do with the fact that postscript operation now thinks it has 14 colors. When we encode/decode, we were packing the colors into a word in such a way that we were losing the interesting ones off the top. Reverse the order of packing, and all is well. This still leaves an "interesting" fact about this device; we loop: for (chan_idx = 0; chan_idx < num_comp; chan_idx++) ... for (j = 0; j < xc->height; j++) ... get_bits_rectangle So, in the case where we have n components, and more than 1 band we'll be rendering the entire file n times - despite the fact that we request all the colors each time! Many thanks!
Give Ghent_Output_Suite_V3.0/Patches/08_DeviceN/081_DeviceN-Support_5c_x3.pdf a try with fad17657f6f58; I get: **** Error reading a content stream. The page may be incomplete. **** Warning: File has unbalanced q/Q operators (too many q's) **** This file had errors that were repaired or ignored. **** Please notify the author of the software that produced this **** file that it does not conform to Adobe's published PDF **** specification. with that revision and psdrgb. With my patch for psd16, it doesn't error out but the resulting rgb psd has bad data (it outputs a 8BIM/0x3EF header (specfying the equiv of the spot color) even though it (correctly) skipped the spot color name header. Only the psdrgb is broken; psdcmyk continues to work well with spot colors, as does my psdcmyk16.
Spot color support with RGB (an additive colorspace) don't really make much sense -- the primary reason for creating spot color planes is to properly honor the overprint (and OPM overprint mode) settings of PS or PDF. Overprint is specified to only work with subtractive colorspaces (CMYK). IMHO, we should remove the spot color support from the psdrgb device (use the alternate tint transform as with all other conforming DeviceRGB devices). We need Michael Vrhel to review this for validity.
Before today’s commit the coded didn’t try to do spot colors with psdrgb; commit fad17657f6f58 tweaks things just right to make gs try to half-support them (by outputting a (corrupt) DisplayInfo struct and the extra plane, but without a spot color name struct.) Before that gs only output the three planes which it should.
I'm confused here. On friday I was sure I was getting believable images out (for no-spot color files) with psdrgb, but today they appear to be solid black. Try as I might I can't spot what I've changed, and even backtracking through git hasn't helped. I am therefore stopping work on this until I can confer with Michael when he returns tomorrow. I'll put a patch with the latest state I have on bug 688210.
Master, as was noted, now generates black output for psdrgb. This patch gets it closer to usable. With this, it now always generates three color planes and results which look recognizable, although the colors are off. As an example, tiger.eps looks blue; it seems that the blue plane is (or nearly is) a copy of the green plane. Still better than current master. The patch tries to stop all use of devn when the psd device is ADDITIVE (as per psdrgb); it changes nothing if the psd device is SUBTRACTIVE (as per psdcmyk).
Created attachment 8643 [details] partial fix for master’s all black psrgb output Don’t use additional planes when the psd device is ADDITIVE. (Doesn’t change the status quo when the psd device is SUBTRACTIVE. Or any other !ADDITIVE, if they exist....)
Comment on attachment 8621 [details] Fix psdrgb. This older patch already was included in another commit to master.
I'm assigning this to Robin since he has been working on it.
Created attachment 8648 [details] Fix psdrgb. I figured it out. With my change (which avoids all-black output from psdrgb), commit fad17657f6f583dbd’s Reversing of the order of packing means that instead of RGB output gs generates BGR output. Hense the blue tiger. With this patch psdgb works fine. This should git am on master. Please am and push. Thanks.
Created attachment 10245 [details] 0001-Bug-693070-Solve-psdrgb-output-being-black.patch Slightly updated form of James' patch.
If Michael is happy with this patch, we can commit it and close the bug.
Assigning to Marcos to test Robin's patch via comparison to ppmraw.
Some of our test files generate an error with the psdrgb device. For example: bin/gs -o test.psd -sDEVICE=psdrgb ./tests_private/comparefiles/Bug692200.pdf generates: GPL Ghostscript 9.11 (2013-08-30) Copyright (C) 2013 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Processing pages 1 through 121. Page 1 Error: /undefined in --setpagedevice-- Operand stack: --dict:8/8(L)-- false --dict:6/6(L)-- Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1918 1 3 %oparray_pop 1917 1 3 %oparray_pop 1901 1 3 %oparray_pop --nostringval-- --nostringval-- 2 1 121 --nostringval-- %for_pos_int_continue --nostringval-- 1880 2 7 %oparray_pop --nostringval-- Dictionary stack: --dict:1171/1684(ro)(G)-- --dict:1/20(G)-- --dict:82/200(L)-- --dict:82/200(L)-- --dict:114/127(ro)(G)-- --dict:279/300(ro)(G)-- --dict:26/32(L)-- Current allocation mode is local GPL Ghostscript 9.11: Unrecoverable error, exit code 1 Exit 1 This happens with the patched and unpatched code.
This was my worry with this device. The changes for planar support with psdcmyk were significant. I will take over this bug for now and look into it shortly after I finish up my transparency work.
Created attachment 10302 [details] screenshot.png Files that do not produce errors generate PSD files that are clearly not correct. See the attached screenshot.png for tiger.eps converted with this command line: bin/gs -sDEVICE=psdrgb -o test.psd ./examples/tiger.eps
Created attachment 10303 [details] 0001-Bug-693070-Solve-psdrgb-output-being-black.patch Fixed patch that should solve the blueness of tiger. Stupid mistake on my part, sorry.
With Robin's updated patch some of the regression files are now correctly ripped to psdrgb, however many are not. I've attached three screenshots showing the psdrgb output (left), ppmraw output (center), and the pixel differences (right).
(In reply to comment #24) > With Robin's updated patch some of the regression files are now correctly > ripped to psdrgb, however many are not. I've attached three screenshots > showing the psdrgb output (left), ppmraw output (center), and the pixel > differences (right). Also the error mentioned in comment #20 still applies, to approximately 2200 of the 3000 input files.
I think this issue is serious enough that at least an attempt should be made to fix it before the next release.
This device is broken more than this bug suggests. Running tiger with the current head results in a black image. Will start working to see what is going on but can't guarantee that this will be resolved for the next release.
Michael asked me to bisect Ghostscript to see where this problem started. Using the command line: bin/gs -sDEVICE=psdrgb -o test.psd ./examples/tiger.eps With commit 60640aeb33b18f9a9fcd76fc6f1083d7c7635f24 the output went from correct to black and white vertical lines. With commit fad17657f6f583dbdef5a634d0f11dd79e446ffe the output went from black and white vertical lines to entirely black.
(In reply to Marcos H. Woehrmann from comment #20) > Some of our test files generate an error with the psdrgb device. This issue started with 37e07e95a5588c2feaba60bbf506a7a9e433a43c.
Commit http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=b5b03bde360a7ba625a4c40a936c4e2fd5a32359 should fix the errors Marcos reported in comment 20.
Black output fixed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8e8a9c4265c3346055ecfc8025880cab28e268de