Re: [Libjpeg-turbo-devel] Further research regarding the effectiveness of SmartScale
SIMD-accelerated libjpeg-compatible JPEG codec library
Brought to you by:
dcommander
From: Siarhei S. <sia...@gm...> - 2013-01-16 15:06:08
|
On Wed, 16 Jan 2013 01:13:47 +0100 "Guido Vollbeding" <vol...@in...> wrote: > Hello Siarhei > > Thanks for remarks. > > > Thanks, I see. It's a bit unfortunate that you did not check whether > > your modification to the filter also benefit WebP and not just JPEG 9. > > Otherwise libwebp-0.2.x might have been a bit better now if you > > could report this before the WebP bitstream got finalized. > > I am responsible for and develop substantial technology, and I can't > participate in speculative attempts which are fundamentally flawed, > sorry. > > > The way I see it, lossless compression support is also released in > > WebP (at least months ahead of JPEG 9) and just provides better > > results at the moment. Do you think JPEG has any realistic chance > > to catch up? > > JPEG is real and substantial, WebP is a speculative attempt with > no substance. So WebP is not for me. You may do this, but I won't. > > > One question for clarification. Does JPEG 9 just strictly implement > > JPEG-LS standard in the new code, which deals with lossless > > compression? > > No, JPEG 9 has its own lossless approach. > This is IJG and not affiliated to ISO, so we have nothing more to do > with JPEG-LS than that what is stated in given document: > > Only the part 2 of JPEG-LS ([4]) has a valid specification for > > reversible color transforms, and this is shared by JPEG 9. > > Notice that JPEG 9 does not share anything else with JPEG-LS, though. > > > Thus I can't help you with other details about this, sorry. Thanks a lot for the clarification about the status of JPEG 9 regarding its conformance with the industrial standards. I tried to search a bit and found at least one open source project, which implements the real standard JPEG LS part-2 (ITU T.870/ISO-14495-2): https://github.com/thorfdbg/libjpeg Lossless encoding can be done with: ./jpeg -c -ls 0 -cls inputfile.ppm outputfile.jpg Lossless decoding of these files back to PPM can be done with: ./jpeg -c -cls inputfile.jpg outputfile.ppm Comparing it for encoding http://www.r0k.us/graphics/kodak/kodak/ images with the rest of the lossless codecs mentioned earlier: Total size for JPEG 9 : 12941527 (~12.3 MiB) Total size for WebP 0.2.1 : 11358510 (~10.8 MiB) Total size for patched WebP 0.2.1 : 11245066 (~10.7 MiB) Total size for thorfdbg JPEG-LS : 11195469 (~10.7 MiB) Now I'm really puzzled about the whole purpose of this JPEG 9 exercise. It seems to be inferior to the alternative solutions in every possible way. Why on earth haven't you just implemented the standard JPEG-LS part-2 for lossless encoding in libjpeg, but instead ended up with some sort of NIH junk? > > The biggest practical problem is that, for example, going to > > http://jpegclub.org/kodaksuite/ with both my desktop browser > > and the browser in my smartphone is not very useful. They just > > can't decode these files. For most of the users it means that > > these files are "broken". And this problem just can't be fixed, > > because in many cases JPEG decoder simply can't be upgraded. > > A lot of systems out there in the wild are in maintenance-only > > mode, and may only receive critical security bugfixes at best. > > Adding extra features is out of question there. JPEG decoders > > (baseline variant) are also implemented as hardware accelerators > > in various mobile devices. Hardware is not easily upgradable. > > Last, but not least, there are also various operating systems > > that are not open source friendly. You are not doing a favour > > for a Linux user, who wants, for example, to do some basic photo > > editing, save it to JPEG format and send to his friend, who > > happens to only have a baseline JPEG decoder in his system. > > You are talking nonsense here. IJG has made JPEG popular, and > so IJG is responsible for maintaining it and developing it further. > We cannot care for ignorant people, sorry. > > > JPEG-LS had its chance. And it looks like this chance has been > > wasted long ago. For the casual users, JPEG means just a lossy > > image format produced by their digital cameras. And they > > rightfully expect their systems to successfully handle any file > > with JPEG extension. This can be achieved in two ways: > > 1) Upgrade every JPEG codec in every device in the world to > > handle JPEG-LS variant (but this is practically impossible as > > explained above). > > 2) Simply don't bring a problem upon yourself and don't create > > the problematic files. Forget about anything other than the > > baseline JPEG. And if you really want better compression or > > something else, there are other alternatives. > > You are still talking nonsense here. > We have nothing to do with JPEG-LS and we don't promote it. > This is IJG, we have made JPEG popular, and we are responsible > for its maintenance and further development. > That is what we do, and we are currently at JPEG 9. > We cannot care for ignorant people, sorry. > > > WebP has a clear advantage today. That is, if it does not waste > > its chance. I guess we will see in a decade or so whether it is > > going to be successful or replaced by something else :-) > > WebP is botch. It may be the right thing to deal with for you and > your crowd, but not for me and IJG. > > Kind regards > Guido Vollbeding > Organizer Independent JPEG Group I'm not really sure how to respond and whether any response would contribute to a constructive discussion. Thanks for sharing your opinion. Before leaving, I only want to apologize for posting some bullshit about JPEG-LS without checking the facts, sorry about that. -- Best regards, Siarhei Siamashka |