Menu
▾
▴
gimp-print-devel
|
From: Solomon P. <pi...@sh...> - 2019-09-12 02:47:31
Attachments:
signature.asc
|
I'm trying to (finally) hunt down the root cause of persistant (and
consistant) reports of dyesub color output not aligning with
$OfficialManufacturerDriver.
Due to these reports mostly centering on native-CMY dyesub models, my
working hypothesis is that the problems are due to differences in the
RGB->CMY conversion.
Along those lines, nearly all of the models that expect YMC data rely on
single-channel mappings (ie R->C, G->M, B->Y) - Sometimes it's as simple
as inverting the R/G/B values, but usually it's some form of fixed LUT.
So, to test my theory, what I'm ultimately trying to come up with is the
"sum total LUT" that Gutenprint uses to transform the input data to the
output data, and figure out how it's ultimately derived. Unfortunately,
Gutenprint's internal complexity is getting me twisted into mobius
pretzels.
Here's a simplified version of what the dyesub driver does:
0 setup_page_dimensions_resolutions_etc
1 foreach ink_channels:
2 stp_channel_add(channel) # CMY in this case
3 stp_color_init(256) # ie 8bpp
4 stp_set_float_parameter("AppGammaScale", 1.0)
5 foreach input row:
6 src = stp_color_get_row()
7 dest = malloc()
8 memcpy(dest, src)
9 foreach printer_specific_curve # optional
10 stp_set_curve_parameter(name, curve)
11 printer_header()
12 foreach printer_output_row
13 emit_formatted_output_row()
14 printer_footer()
15 profit
At (1-3), we set up the output channel mappings and initialize the color
subsystem. At this point, an LUT is created. When dumped, it reports
itself as RGB->RGB, and its mappings show that we map 8bpp RGB input
into a linear 16bpp RGB working space.
(4) and (9-10) are interesting, leading to my first questions:
* Does these calls have any effect, given that they both occur after
stp_color_init() and/or the stp_color_get_row() calls?
* Are these applied curves absolute, replacing the existing curve
rather than applying on top of it?
At (6), we get an output row buffer that is comprised of 16bpp YMC data,
which is downscaled linearly (/=257) in (13). (This is a direct
inversion of the input brightness correction LUT). This leads to my big
questions:
* How/when is the RGB->YMC conversion done?
* Is the output of stp_color_get_row() still linear 16bpp?
* If no, how is it de-linearized?
* If yes, are there just 256 discrete levels?
Trying to map the code flow out has given me quite a headache. :)
Thanks,
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
|
|
From: Solomon P. <pi...@sh...> - 2019-09-12 03:35:24
Attachments:
signature.asc
|
On Wed, Sep 11, 2019 at 10:47:19PM -0400, Solomon Peachy wrote:
> 1 foreach ink_channels:
> 2 stp_channel_add(channel) # CMY in this case
> 3 stp_color_init(256) # ie 8bpp
> 4 stp_set_float_parameter("AppGammaScale", 1.0)
>
> (4) and (9-10) are interesting, leading to my first questions:
>
> * Does these calls have any effect, given that they both occur after
> stp_color_init() and/or the stp_color_get_row() calls?
Moving AppGammaScale above stp_color_init() changed the LUT channel
curves to be completely linear. This is probably the smoking gun.
Looks like this bass-ackwards order was my doing, in commit bdf7edde3,
in April of 2018 -- I incorrectly copied the changes made to the color
laser driver.
I want to correct this, but it's going to affect the output of every
dyesub model we support.
If the hanful of test prints I've made so fare are any indication, it's
definitely for the better (color test charts are visibly improved) but
it's still a non-trivial change in output.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
|
|
From: Solomon P. <pi...@sh...> - 2019-09-13 14:01:07
Attachments:
signature.asc
|
On Wed, Sep 11, 2019 at 11:35:15PM -0400, Solomon Peachy wrote: > If the hanful of test prints I've made so fare are any indication, it's > definitely for the better (color test charts are visibly improved) but > it's still a non-trivial change in output. I've now tested five printers from three manufacturers; the output is visibly improved with all of them, with better contrast and tonal range across the board. As an added bonus, when using the manufacturer ICC profiles the outputs are finally consistent with each other! So I've commited the change. But since this change represents a significant change in output, I added an option to revert to the old behavior, defaulting to off. If the user enables "LegacyDyesubGamma", the dyesub driver will revert to the old behavior. ...I still need to document this change in the NEWS file though. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: Solomon P. <pi...@sh...> - 2019-09-12 11:19:49
Attachments:
signature.asc
|
On Wed, Sep 11, 2019 at 10:47:19PM -0400, Solomon Peachy wrote:
> 0 setup_page_dimensions_resolutions_etc
> 1 foreach ink_channels:
> 2 stp_channel_add(channel) # CMY in this case
> 3 stp_color_init(256) # ie 8bpp
> 4 stp_set_float_parameter("AppGammaScale", 1.0)
> 5 foreach input row:
> 6 src = stp_color_get_row()
> 7 dest = malloc()
> 8 memcpy(dest, src)
> 9 foreach printer_specific_curve # optional
> 10 stp_set_curve_parameter(name, curve)
> (4) and (9-10) are interesting, leading to my first questions:
>
> * Does these calls have any effect, given that they both occur after
> stp_color_init() and/or the stp_color_get_row() calls?
To follow up to myself about (9-10), it looks like this call sequence
was rearranged in commit f406f9715, way back in Sep 2006, and from what
I can tell, making effectively into no-ops.
Here are the models affected by this goof:
* Olympus P200, P300, P400
* Canon Selphy series (all)
* Sony UP-DP10
It seems prudent to re-arrange these into a more appropriate position,
so the calls can actually do something now, but IMO the existing curves
in there should be disabled until the AppGammaScale change can be
evaluated more closely.
(On the other hand, only the Selphy series matters now, as media for the
others has been effectively unobtanium for the better part of a
decade.. when you can even find media it's so expensive that it's
arguably cheaper to just replace the printer instead..)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
|
|
From: Robert K. <rl...@al...> - 2019-09-14 00:11:13
|
On Fri, 13 Sep 2019 10:00:50 -0400, Solomon Peachy wrote: > On Wed, Sep 11, 2019 at 11:35:15PM -0400, Solomon Peachy wrote: >> If the hanful of test prints I've made so fare are any indication, it's >> definitely for the better (color test charts are visibly improved) but >> it's still a non-trivial change in output. > > I've now tested five printers from three manufacturers; the output is > visibly improved with all of them, with better contrast and tonal range > across the board. This sounds very much like the problem we had with color laser printers early on, and as I recall. I'm not a huge fan of changing color output of stable printers during a release train, but this is more of a bug, and I think fixing it is the right thing to do. > As an added bonus, when using the manufacturer ICC profiles the outputs > are finally consistent with each other! > > So I've commited the change. > > But since this change represents a significant change in output, I added > an option to revert to the old behavior, defaulting to off. If the > user enables "LegacyDyesubGamma", the dyesub driver will revert to the > old behavior. > > ...I still need to document this change in the NEWS file though. -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Solomon P. <pi...@sh...> - 2019-09-19 11:38:07
Attachments:
signature.asc
|
On Fri, Sep 13, 2019 at 08:11:02PM -0400, Robert Krawitz wrote: > This sounds very much like the problem we had with color laser > printers early on, and as I recall. Yep! But I screwed up porting your fixes to the dyesub family.. > I'm not a huge fan of changing color output of stable printers during > a release train, but this is more of a bug, and I think fixing it is > the right thing to do. So do you think we should keep the option of using the old behaviour? On a related note, I've contemplating just ripping out support in the dyesub driver for per-printer curves. They haven't actually worked since 2006, and what few exist are invalid in light of the gamma curve change. IMO standard ICC profiles should be used instead. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: Stuart T R. <st...@st...> - 2019-09-17 10:09:05
|
Sorry if this has been covered but I am wondering if it is possible to use the CP900 wirelessly and if so how should I configure it? Stuart -- Website: https://www.stella-maris.org.uk or: https//www.broadstairs.org |
|
From: Solomon P. <pi...@sh...> - 2019-09-17 11:17:31
Attachments:
signature.asc
|
On Tue, Sep 17, 2019 at 10:49:53AM +0100, Stuart T Rogers wrote: > Sorry if this has been covered but I am wondering if it is possible to use > the CP900 wirelessly and if so how should I configure it? There is a tool called 'selphy.go' that works by sending over a jpeg. I forked it a while ago to fix some bugs; you can find that verison here: http://git.shaftnet.org/cgit/users/pizza/public/selphy_go.git/ As it directly sends over jpeg data, it can't be integrated into a traditional CUPS-based printing stack. (WiFi printing on these these things is a total mess. I'll spare you the mini history lesson / rant..) - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
|
From: Robert K. <rl...@al...> - 2019-09-19 11:57:37
|
On Thu, 19 Sep 2019 07:37:56 -0400, Solomon Peachy wrote: > On Fri, Sep 13, 2019 at 08:11:02PM -0400, Robert Krawitz wrote: >> I'm not a huge fan of changing color output of stable printers during >> a release train, but this is more of a bug, and I think fixing it is >> the right thing to do. > > So do you think we should keep the option of using the old > behaviour? I'm a bit on the fence about it, in this case. It sounds like the behavior was more or less objectively wrong Also, did this behavior regress at some reasonably recent point, or was this the case all along? > On a related note, I've contemplating just ripping out support in the > dyesub driver for per-printer curves. They haven't actually worked > since 2006, and what few exist are invalid in light of the gamma curve > change. IMO standard ICC profiles should be used instead. That sounds reasonable. -- Robert Krawitz <rl...@al...> *** MIT Engineers A Proud Tradition http://mitathletics.com *** Member of the League for Programming Freedom -- http://ProgFree.org Project lead for Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Solomon P. <pi...@sh...> - 2019-09-19 12:26:42
Attachments:
signature.asc
|
On Thu, Sep 19, 2019 at 07:57:27AM -0400, Robert Krawitz wrote: > I'm a bit on the fence about it, in this case. It sounds like the > behavior was more or less objectively wrong I would agree, the behavior is "objectively wrong". But... > Also, did this behavior regress at some reasonably recent point, or > was this the case all along? This bug has been there forever, but one could argue that it "regressed" in 2006, when the per-printer correction curves stopped having any effect. I'm also on the fence too; everyone that's seen the before/after output says the new behavior is clearly better. But it is a major change in output for existing users. Adding an option to enable reverting to the old "wrong" way seemed the best way to get this fix into users hands, while providing a fallback for those that went through the effort of correcting/tuning their own printing flow. - Solomon -- Solomon Peachy pizza at shaftnet dot org High Springs, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum videtur. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X