Guido Vollbeding <gu...@jpegclub.org> writes:
> The term JPEG FILE INTERCHANGE FORMAT (JFIF) primarily refers to
> the range of supported color space encodings, and it will be
> redefined by IJG in the upcoming IJG JPEG 9a release, see
Just for the record, JFIF was not invented by IJG, and I don't believe
that you get to redefine it. The original spec is perfectly clear that
there is exactly one color space allowed in JFIF files. (Well, two if
you count greyscale.) If you try to extend this you'll just end up
creating incompatibilities with non-IJG implementations.
In general, I'm quite disturbed that you seem to be willing to introduce
file format incompatibilities with other implementations (and with older
copies of the IJG code for that matter). This flies in the face of what
IJG was founded to accomplish, namely promote universal compatibility
of JPEG files.
I took a quick look at the referenced Debian bug, and I'm in agreement
with the "this is not a bug" position. Although the complainant is of
the opinion that djpeg should be able to read any JPEG file, that's
utter nonsense. It has never been intended to deal with CMYK data.
The proposed patch involving somebody's hack-and-slash conversion to
RGB just betrays complete ignorance of what CMYK is used for in the
real world. (I will note that I rejected similar patches back when
I was actively maintaining libjpeg.) In practice, if you want to deal
with CMYK, you really need a file format like TIFF that is able to
carry the necessary auxiliary info about which CMYK inks are meant.
JFIF can't do this, and that's fine --- it was never meant to be all
things to all people.
regards, tom lane
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
