Path: csiph.com!x330-a1.tempe.blueboxinc.net!aioe.org!goblin1!goblin.stu.neva.ru!news2.arglkargh.de!news.n-ix.net!news.belwue.de!rz.uni-karlsruhe.de!feed.news.schlund.de!schlund.de!news.online.de!not-for-mail From: human Newsgroups: comp.compression Subject: Re: removing predictable crap from poor quality jpegs Date: Mon, 09 May 2011 23:06:28 +0200 Organization: humanity Lines: 47 Message-ID: <4DC85754.598B1F2F@elfavo.com> References: <877ha8xeex.fsf@bazspaz.fatphil.org> <06670647-eea6-489e-8ec2-ec89d1e712cf@j28g2000vbp.googlegroups.com> <87y62nx1vx.fsf@bazspaz.fatphil.org> <425999b8-260b-44d1-9591-282d22c89566@a10g2000vbz.googlegroups.com> <4DC28B80.F82CF30E@elfavo.com> <946afd41-cc84-4339-b13a-1ac83d8a5fc0@s14g2000vbi.googlegroups.com> <4DC3E870.7D929774@elfavo.com> <4DC64BB1.77617120@elfavo.com> <4DC6C852.C7ABB529@elfavo.com> <6af5e3ba-bf14-451b-b246-dacd9de84473@o7g2000vbn.googlegroups.com> <4DC7AB04.58968C72@elfavo.com> <4DC7DD6D.271AC0F3@elfavo.com> <4DC83C01.DE816412@elfavo.com> NNTP-Posting-Host: port-92-195-112-46.dynamic.qsc.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: online.de 1304975121 3108 92.195.112.46 (9 May 2011 21:05:21 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Mon, 9 May 2011 21:05:21 +0000 (UTC) X-Mailer: Mozilla 4.78 [de] (Windows NT 5.0; U) X-Accept-Language: de Xref: x330-a1.tempe.blueboxinc.net comp.compression:242 Thomas Richter wrote: > > Look, as already indicated, JPEG does *not* address the problem. > JPEG is lossy, or to be precise, the only part that has found wide > adoption in the photography market is lossy. The lossless part is absent > and hasn't been adopted there at all (neither in your software, btw). See my other post, it is ok that it hasn't been adopted because it is obsolete. We do have a seamlessly integrated lossless mode since v8. > In the medical market it has been superceeded by JPEG 2000 a while ago > since this market required higher quality and better loss control. So in > the digital movie market. All not end user markets, of course, but in > the professional area. What you call "professional area" here is a speculative domain, so that fits perfectly. They use unreal technologies, because they themselves are unreal. You are healed by nature, or by consciousness, while the medical market is just a fake for clueless people, so again, this fits perfectly. > However, as you might have noticed, the higher ends of the photography > consumer ("prosumer") market are moving away from JPEG, and use its > "loss" as an argument for pushing proprietary formats. Addressing this > market by a lossy(!) IJG code is not the right approach to begin with. Speculative domain, unreal, nice fit. > > In any case, our decoder will remain capable of reading existing > > JPEG image files indefinitely. > > I don't think it is capable of reading even parts of the existing JPEG > images today, to be precise. It doesn't support the lossless branch (at > least not the versions I have), and the versions I know require a > compile time decision for 12bpp, leave alone that it doesn't support > JPEG files encoded in 15444 or 29199, which are also JPEG files. Or > JPEG-LS, for that matter, which is just another standard. So well, this > "promise" is already not true, and never has been true. You have not understood. With "existing JPEG images" it means files created with prior JPEG versions in real use. Again: Your standard papers are not the reality. The lossless branch is obsolete, as mentioned, and "JPEG-LS", for that matter, is also obsolete. ciao human