Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!news.szaf.org!news.gnuher.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: Thu, 05 May 2011 13:35:28 +0200 Organization: humanity Lines: 23 Message-ID: <4DC28B80.F82CF30E@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> NNTP-Posting-Host: port-92-195-133-109.dynamic.qsc.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: online.de 1304595251 10611 92.195.133.109 (5 May 2011 11:34:11 GMT) X-Complaints-To: abuse@einsundeins.com NNTP-Posting-Date: Thu, 5 May 2011 11:34:11 +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:213 Sebastian wrote: > > I'm not familiar with jpegtran and what "-scale" actually does. It > seems as if high frequency coefficients are simply discarded using "- > scale 7/8" and zero padded using "-scale 8/7" afterwards. In that > case, yes, there is no aliasing / imaging. From description in "transupp.h" in the IJG distribution: * We also provide a lossless-resize option, which is kind of a lossless-crop * operation in the DCT coefficient block domain - it discards higher-order * coefficients and losslessly preserves lower-order coefficients of a * sub-block. > Unfortunately, lowpass > filtering "in the DCT domain" introduces some new blocking artefacts > if blocks are handled independently. You should never use digital images, because capturing images in pixel arrays introduces edges at the pixel boundaries. ciao human