Tom Lane wrote: > > 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
Here's what happens in the real world: on rare occasions, I encounter jpeg files that I can't view because someone has put YCCK/CMYK in them. I present you with a simplified version of the problem: forget djpeg; ln -sf jpegtopnm /usr/bin/djpeg solved that. Now the only remaining problem is that "xli *.jpg" randomly fails on a small percentage of jpegs found in the wild. What's the correct solution to that? 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? -- Alan Curry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
