[Gimp-print-devel] Adding native YCbCr support?

[Solomon Peachy]

I'd like to get rid of the RGB->YCbCr hack I put into the dyesub driver
to support the newer Canon SELPHY printers, by adding core support for
the YCbCr colorspace.

But I'm not quite sure how to go about this. Would I need to
essentially add a map to/from everything else?

- Solomon

[Robert Krawitz]

Post by Solomon Peachy
I'd like to get rid of the RGB->YCbCr hack I put into the dyesub driver
to support the newer Canon SELPHY printers, by adding core support for
the YCbCr colorspace.
But I'm not quite sure how to go about this. Would I need to
essentially add a map to/from everything else?

To do it right, yes.

We could also decide that we won't support all NxN conversions; we'll
support certain input color spaces, but not all. I don't know what
good YCbCr=>CMYK would be. But we could handle YCbCr=>YCbCr by simple
passthrough.

[Solomon Peachy]

Post by Robert Krawitz
We could also decide that we won't support all NxN conversions; we'll
support certain input color spaces, but not all. I don't know what
good YCbCr=>CMYK would be. But we could handle YCbCr=>YCbCr by simple
passthrough.

I don't know if there's any point in supporting YCbCr as an input, as
I've only seen one family of printers that use it (for reasons I still
cannot fathom..) and I've never seen it as an actual on-disk output
format by an application, only as an output for video display. CUPS
doesn't support it either.

But in a more general sense, is chaining conversions a viable (if
inefficient) strategy here? instead of N->YCbCr, would N->RGB->YCbCr
(and YCbCr->RGB->N) be an option?

- Solomon

[Robert Krawitz]

Post by Solomon Peachy

Post by Robert Krawitz
We could also decide that we won't support all NxN conversions; we'll
support certain input color spaces, but not all. I don't know what
good YCbCr=>CMYK would be. But we could handle YCbCr=>YCbCr by simple
passthrough.

I don't know if there's any point in supporting YCbCr as an input, as
I've only seen one family of printers that use it (for reasons I still
cannot fathom..) and I've never seen it as an actual on-disk output
format by an application, only as an output for video display. CUPS
doesn't support it either.
But in a more general sense, is chaining conversions a viable (if
inefficient) strategy here? instead of N->YCbCr, would N->RGB->YCbCr
(and YCbCr->RGB->N) be an option?

If it doesn't clobber performance too badly, sure. Gutenprint's doing
all of this in 16 bits, so you probably won't lose too much going that
way.

[Solomon Peachy]

Post by Robert Krawitz
If it doesn't clobber performance too badly, sure. Gutenprint's doing
all of this in 16 bits, so you probably won't lose too much going that
way.

Earlier tonight I figured out how to get the SelphyNeo models to accept
CMY data. So I think I'm going to scrap the YCbCr stuff altogether.

- Solomon