The Photoshop raster output device (gdevpsd.c) should be extended to support deep color. That is, support for 48 bit RGB and 64 bit CMYK (both 16 bits per component) as well as 16 bpc grayscale and "DeviceN" separation output. This is useful for high-quality graphic arts and photography workflow.
Is there a device that currently has support for both 8bit and 16bit which could be used as an example for what needs to be done to the psd device to accomplish this enhancement?
Enhancement still missing in Ghostscript 9.03
Grrr. Below is a patch to add psdrgb16 and psdcmyk16 devices, which do 16 bits/component. It works fine for cmyk. For rgb it generates the same broken images that current master does.... ☹ (Either the switch to planar or the addition of the downscaler broke psdrgb.)
The downscaler only supports 8bpp as source for downscaling. James, if I'm understanding your comment correctly you're saying that the current psdcmyk device is broken in some way, which we clearly aren't seeing in our testing. Could you open a new bug and attach a command line/file that shows the problem please? Thanks.
Created attachment 8620 [details] Add 16 bit/component psd devices. • psdrgb16 creates 48-bit rgb files. • psdcmyk16 creates 64+ bit cmyk (plus spot, as applicable) files.
> The downscaler only supports 8bpp as source for downscaling. Well that’s annoying. ☺ How do you want the 16-bit devices to handle that? Abort if downscaling? Output 8-bit if downscaling? Something else? > you’re saying that the current psdcmyk device is broken > Could you open a new bug... I already opened Bug #693070. I’ll update it with a CL.
(In reply to comment #6) > > The downscaler only supports 8bpp as source for downscaling. > Well that’s annoying. ☺ I can probably update it to 16bpp too if required. > How do you want the 16-bit devices to handle that? Abort if downscaling? > Output 8-bit if downscaling? Something else? Probably in 16bit mode they should return a rangecheck error if the downscale factor is anything other than 1. > > you’re saying that the current psdcmyk device is broken > > Could you open a new bug... > > I already opened Bug #693070. I’ll update it with a CL. Thanks!
Created attachment 8622 [details] Get psdrgb working Like psdcmyk, psdrgb expects 14 planes, but was claiming 3 in its const psd_device gs_psdrgb_device.
Created attachment 8624 [details] Add 16 bit/component psd devices. • psdrgb16 creates 48-bit rgb files. • psdcmyk16 creates 64+ bit cmyk (plus spot, as applicable) files. Given that the downscaler can only handle eight bit planes, a rangecheck error is generated when combining psdrgb16 or psdcmyk16 with a DownScaleFactor other than unity. (This combines attachment #8620 [details], attachment #8622 [details] and the request to generate a rangecheck as per above. This does not include and therefore depends on the memcpy(3) patch from Bug #693070 attachment #8621 [details].)
Comment on attachment 8622 [details] Get psdrgb working I got a 500 server error when I tried to obsolete the first two patches as part of the submission of the third patch, so doing the obsoletes one at a time....
Created attachment 8625 [details] Add 16 bit/component psd devices. • psdrgb16 creates 48-bit rgb files. • psdcmyk16 creates 64+ bit cmyk (plus spot, as applicable) files. Given that the downscaler can only handle eight bit planes, a rangecheck error is generated when combining psdrgb16 or psdcmyk16 with a DownScaleFactor other than unity. (Rebased to master fad17657f6 to avoid conflicts.)
Created attachment 8628 [details] 0001-Updated-Add-16-bit-component-psd-devices.patch This is an updated version of James' patch, with the required tweaks to make it work with the new 16bit mode in the downscaler. This (no fault of James!) leaves psdrgb and psdrgb16 behaviour broken in the spot color cases.
Created attachment 8644 [details] Add 16 bit/component psd devices. This further refines the 16 bit per component patch for psd. It includes the changes Robin added after he pushed 16 bit support into the downscaler. Combined with the patch I just posted to bug #693070 (attachment #8643 [details]) this generated sixteen bit output which matches the existing eight bit output for both rgb and cmyk, without harming the output from the existing eight bit devices. Without that other patch the psdrgb16 output is a partial progression from the existing psdrgb output, but otherwise the last paragraph still applies. Master’s psdrgb bug should not prevent this patch from landing. Please apply!
Can anyone provide an ETA for how much longer this will languish? (Just feeling a little ignored is all. ☺)
Sorry James. We are interested in this, but both Michael and I (the 2 most recent people to have had our fingers in the psd device) are busy with other work at the moment. Michael is scheduled to look back at the psdcmyk and psdrgb devices soon, specifically to ensure that the psdrgb device behaves itself in all cases - your patches on the other bug will no doubt help with that. Once the device settles down, I'm sure we'll then look at your 16bit patches. Sorry for not working quite as fast as you (or we!) would like, but commercial considerations mean we have to work to different priorities. I can't give an exact timescale for when Michael will be free to look at the psdrgb device though, sorry.
Robin was quite gracious in his response and doesn't bring up the reality of Artifex Software priorities... We prioritize reported customer bugs first, then bugs that are easy, or are likely to affect a paying/supported customer next. Enhancement bugs are less important since we aren't "wrong" in the resulting output. Adding deep color support is clearly an enhancement. At this time, we don't have any paying/supported customers using the 'psd' format, much less customers requesting > 8 bit support. A comment from a free user that says: > Can anyone provide an ETA for how much longer this will languish? > (Just feeling a little ignored is all. ☺) This just tends to irritate some of us. At this point we don't have any paying supported customers interested in this, so it isn't really a priority. Thus, review and incorporation of any proposed changes (and any bounty) for enhancements take a back seat to work that pays the bills.
So, it seems my attempt at humour fell flat. I guess we all can’t mix comedy into coding as well as Larry.... That said, a willingness to pay for something does give the impression that it is a higher priority. If that is not the case, perhaps the docs could reflect the reality a bit more. And it is not as though other P3 (or higher) bounties have not been paying out. This patch affects only the psd driver, has no regressions over 9.05, the (free) patch in bug #693070 fixes master’s regression from 9.05. Perhaps the fact that I was hoping to use this to pay off a vendor left me less patient. Apologies for that. Please let me know when this hit the radar.
(In reply to comment #17) > So, it seems my attempt at humour fell flat. I guess we all can’t mix comedy > into coding as well as Larry.... > > That said, a willingness to pay for something does give the impression that it > is a higher priority. If that is not the case, perhaps the docs could reflect > the reality a bit more. > > And it is not as though other P3 (or higher) bounties have not been paying out. > > This patch affects only the psd driver, has no regressions over 9.05, the > (free) patch in bug #693070 fixes master’s regression from 9.05. > > Perhaps the fact that I was hoping to use this to pay off a vendor left me less > patient. Apologies for that. > > Please let me know when this hit the radar. I consider this our fault and it is fine to receive the P3 bounty now and we'll trust you to follow up when and if we find problems. If you don't know how to apply for the bounty please email me. Note Miles will be on vacation next week so likely it won't be processed until the Monday after next.
> it is fine to receive the P3 bounty now Thank you. > and we'll trust you to follow up when and if we find problems. I shall do so.
This 16 bit improvement has been rotting on my desk probably unnoticed (sorry), seems worth getting this in since much of the work is done. Changing assignment to Michael.
Let me know if you need anything more from me.
This was committed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=416a5ebe1f7435f6dc8894576f40a8f247ed386c Note that there was quite a bit of work still to do to make sure the transparency code worked properly. The above patch associated with the bug was not sufficient.