Bill Allombert wrote: > > Dear Alan, I have forwarded your bug report to the upstream maintainer. > Thanks for taking the time to work on this. > > However, I have a question: how do you generate such JPEG images ? > Would there be benefit for libjpeg to be able to do that ?
I gather from the archived libjpeg-turbo discussion that this weird kind of jpeg is generated by Photoshop when certain options are enabled. I don't know the motivation for creating them that way. I only wish I could take arbitrary jpegs from the wild and feed them to a shell script based on djpeg, without having the occasional failure because one of these YCCK images showed up. The second issue is that I'd also like to be able to run "xli *.jpg" in a directory full of images-not-made-by-me, and not see any failures. That means conversion needs to be done in xli or in the library. With the patched version of the library, I already have xli working (by adding 3 extra lines to request RGB output from the library). Without the patched library, it would be harder. I can appreciate that the YCCK/CMYK formats are non-standard hacks forced upon us by Adobe, and it's not pleasant to admit we need to support them. But the free software community in general has not rejected them. They can be converted by imagemagick, displayed by mozilla, and edited by gimp. The only places where YCCK/CMYK support is missing is in the small and fast alternatives to those programs. I want to fix that. If we're stuck with a djpeg that refuses to decode images with proprietary extensions, not because the extensions aren't understood but because the maintainer objects to the existence of the extensions, then djpeg has become more of a political object than a useful scripting tool. After testing this patch, I became aware of jpegtopnm in the netpbm package, which already handles YCCK. The easy way around this problem will be to just s/djpeg/jpegtopnm/g in all my scripts and apt-get remove libjpeg-progs. But that leaves the followup issue, lack of xli support, unsolved. I'd then have to port this patch (which inside libjpeg is *already working*) to xli. And then xloadimage. And how about xpaint? Making each one of them contain a duplicate of the conversion code would be ridiculous! -- Alan Curry -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
