Dear Alan
xli is not going to have any information about the image except what it
gets from libjpeg. What should it display when libjpeg gives it CMYK
output? If I take the conversion formula from this proposed patch and put
it into xli instead, I'll have something satisfactory for the immediate
purpose. But putting the code in the library gives other programs the
opportunity to reuse it, and gives me identical results. How is that bad?
If the formula itself is bad, where's the correct one? What formula would
you use to display an image in a viewer that is dependent on libjpeg for
all of its information about the image, in the case that libjpeg produces
CMYK output?
You simply have to accept the fact that CMYK is not JFIF,
so you can't use it for common image interchange,
because there is no standard comparable to IEC 61966-2-1 for it!
I have elaborated why we can't use the given approximate formula
in libjpeg reference code.
The problem can only be handled in an appropriate color management
framework, which is system/application dependent and is not aspect
of a core image codec library like libjpeg.
If somebody wants to make CMYK interchangeable, than he has to
invest an effort to define something like IEC 61966-2-1, again see
here:
http://www.doc88.com/p-694270296039.html
Obviously nobody has done this so far for CMYK, so there is no
solution for handling CMYK in an image codec like libjpeg other
than given.
We are IJG, and we don't participate in botch and mess production,
sorry. There is enough such stuff already. We aim for clarity.
Regards
Guido
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
