Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compression > #203 > unrolled thread
| Started by | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| First post | 2011-05-03 13:32 +0300 |
| Last post | 2011-05-12 20:15 +0200 |
| Articles | 20 on this page of 63 — 9 participants |
Back to article view | Back to comp.compression
removing predictable crap from poor quality jpegs Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-03 13:32 +0300
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-03 13:53 +0200
Re: removing predictable crap from poor quality jpegs Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-03 16:09 +0100
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-03 18:10 +0200
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-03 18:32 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-03 06:22 -0700
Re: removing predictable crap from poor quality jpegs Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-05-03 18:03 +0300
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-05 04:18 -0700
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-05 13:35 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-06 00:23 -0700
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-06 14:24 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-06 20:33 +0200
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-08 09:52 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-08 15:27 +0200
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-08 17:55 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-08 07:56 -0700
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-08 18:44 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-08 10:21 -0700
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-09 10:51 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-09 11:49 +0200
Re: removing predictable crap from poor quality jpegs human <noreply@elfavo.com> - 2011-05-09 12:06 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-09 15:29 +0200
Re: removing predictable crap from poor quality jpegs Guido Vollbeding <gv@uc.ag> - 2011-05-09 16:03 +0200
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-09 22:01 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-09 23:24 +0200
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-10 16:45 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-09 04:15 -0700
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-09 14:26 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-09 15:51 +0200
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-09 21:09 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-09 22:28 +0200
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-09 23:06 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-10 17:34 +0200
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-12 15:01 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-09 09:40 -0700
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-09 20:23 +0200
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-09 22:37 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-10 02:27 -0700
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-10 05:01 -0700
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-12 15:51 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-13 05:07 -0700
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-13 14:39 +0200
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-13 15:39 +0200
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-13 16:36 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-13 08:52 -0700
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-13 19:00 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-13 10:07 -0700
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-13 17:25 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-13 10:06 -0700
Re: removing predictable crap from poor quality jpegs Pete Fraser <pfraser@covad.net> - 2011-05-13 18:17 -0700
Re: removing predictable crap from poor quality jpegs Guido Vollbeding <guido@jpegclub.org> - 2011-05-14 09:16 +0200
Re: removing predictable crap from poor quality jpegs Guido Vollbeding <guido@jpegclub.org> - 2011-05-14 10:07 +0200
Re: removing predictable crap from poor quality jpegs Guido Vollbeding <guido@jpegclub.org> - 2011-05-14 19:52 +0200
Re: removing predictable crap from poor quality jpegs Guido Vollbeding <guido@jpegclub.org> - 2011-05-14 21:08 +0200
Re: removing predictable crap from poor quality jpegs Guido Vollbeding <guido@jpegclub.org> - 2011-05-16 08:43 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-16 05:15 -0700
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-16 17:00 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-16 13:02 -0700
Re: removing predictable crap from poor quality jpegs Thomas Richter <thor@math.tu-berlin.de> - 2011-05-17 09:43 +0200
Re: removing predictable crap from poor quality jpegs Sebastian <s.gesemann@gmail.com> - 2011-05-19 02:55 -0700
Re: removing predictable crap from poor quality jpegs Noob <root@127.0.0.1> - 2011-05-20 13:23 +0200
Re: removing predictable crap from poor quality jpegs Pete Fraser <pfraser@covad.net> - 2011-05-20 05:38 -0700
Re: removing predictable crap from poor quality jpegs human <noreplay@elfavo.com> - 2011-05-12 20:15 +0200
Page 1 of 4 [1] 2 3 4 Next page →
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-05-03 13:32 +0300 |
| Subject | removing predictable crap from poor quality jpegs |
| Message-ID | <877ha8xeex.fsf@bazspaz.fatphil.org> |
I have a bunch of images - mostly newspaper image scans - which have been turned into noise by scanning/jpeg-compressing. Random noise I don't care about, but these are showing horrific chess-boarding. Here's a zoomed example. http://fatphil.org/images/crappyjpg.jpg Is there any simple fix to remove the chessboarding? It seems obvious that the chessboarding is the (8,8) coefficient in the DCT, so perhaps I just need to strip all non-zero (8,8) coefficients from the file. Is there a utility that can do that? One that otherwise doesn't change the file would be best. One idea was to use jpegtran -scale 7/8 | jpegtran -scale 8/7 to just remove all of the (x,8) and (8,y) coefficients. Which is more than I need, but probably causes no losses of other frequencies that I would object to. Can anyone see any downsides to that? (The results look like an improvement to me.) On an 'implementation' note, it does look like that noise is a programmatic error in the original jpeg compression code (I have no idea what created it) rather than some horrific scanner/scaling/aliasing artefact. I'm guessing that there was an unsigned integer underflow which tried to put -1 in the (8,8) coefficient and instead put 255 there, so when it was scaled down in the quantizing step, it survived. Have such bugs been known to exist in any common libraries? Phil -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." -- Matthew Vernon
[toc] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-03 13:53 +0200 |
| Message-ID | <4DBFECD7.A3180162@elfavo.com> |
| In reply to | #203 |
Phil Carmody wrote: > > I just need to strip all non-zero (8,8) coefficients from the file. Is > there a utility that can do that? One that otherwise doesn't change > the file would be best. > > One idea was to use jpegtran -scale 7/8 | jpegtran -scale 8/7 to > just remove all of the (x,8) and (8,y) coefficients. Which is more > than I need, but probably causes no losses of other frequencies that > I would object to. Can anyone see any downsides to that? (The results > look like an improvement to me.) That is a good idea for quick application, but there is a better solution. One other (minor) downside of this approach is that it doesn't retain odd image dimensions exactly in the process of rescaling. Here is what I recommend: Write a custom scan script as follows (create a file "scans.txt" for example): # Interleaved DC scan for Y,Cb,Cr: 0,1,2: 0-0, 0, 0 ; # AC scans for all AC coefficients, except the last one: 0: 1-62, 0, 0 ; # Y 1: 1-62, 0, 0 ; # Cb 2: 1-62, 0, 0 ; # Cr Then use the following command: jpegtran -scans scans.txt | jpegtran This will create an intermediate "incomplete" progressive JPEG file in the first stage, which will then be restored to standard sequential JPEG in the second stage (jpegtran might emit warnings). This is for color images. Grayscale is even simpler, you just remove the Cb/Cr parts (component indices 1,2): # DC scan for Y: 0: 0-0, 0, 0 ; # AC scan for all Y AC coefficients, except the last one: 0: 1-62, 0, 0 ; With this approach you can remove any coefficient(s) you want. In your case this just happens to be the last coefficient in the zig-zag sequence (index 63, which appears in "complete" scripts, see file "wizard.txt" in the IJG distribution for more information and examples about scan scripts). ciao human
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-05-03 16:09 +0100 |
| Message-ID | <eZA*OAaCt@news.chiark.greenend.org.uk> |
| In reply to | #204 |
human <noreply@elfavo.com> wrote: > Phil Carmody wrote: > > I just need to strip all non-zero (8,8) coefficients from the file. Is > > there a utility that can do that? One that otherwise doesn't change > > the file would be best. > > > > One idea was to use jpegtran -scale 7/8 | jpegtran -scale 8/7 to > > just remove all of the (x,8) and (8,y) coefficients. Which is more > > than I need, but probably causes no losses of other frequencies that > > I would object to. Can anyone see any downsides to that? (The results > > look like an improvement to me.) > That is a good idea for quick application, but there is a better > solution. > One other (minor) downside of this approach is that it doesn't > retain odd image dimensions exactly in the process of rescaling. > Here is what I recommend: > Write a custom scan script as follows (create a file "scans.txt" > for example): > # Interleaved DC scan for Y,Cb,Cr: > 0,1,2: 0-0, 0, 0 ; > # AC scans for all AC coefficients, except the last one: > 0: 1-62, 0, 0 ; # Y > 1: 1-62, 0, 0 ; # Cb > 2: 1-62, 0, 0 ; # Cr > Then use the following command: > jpegtran -scans scans.txt | jpegtran Wow, I never realised there was such an option. Looking at the wizards.txt file seems to explain enough about such tricks. Many thanks! Phil
[toc] | [prev] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-03 18:10 +0200 |
| Message-ID | <4DC028EF.4A9DE7BD@elfavo.com> |
| In reply to | #207 |
Phil Carmody wrote: > > > Then use the following command: > > > jpegtran -scans scans.txt | jpegtran > > Wow, I never realised there was such an option. Looking at the > wizards.txt file seems to explain enough about such tricks. Yes, there is lots of flexibility by using progressive mode parameters with custom scan script for special applications. But be aware of the constraints when first looking into this. A naive idea may suggest the single line: 0,1,2: 0-62, 0,0 ; to achieve the goal in one sequential step, but this is probably prevented by the constraint checking in the JPEG code. For sequential mode only 0-63 is allowed, and note that progressive mode must always separate DC from AC scans, because the coding models for DC and AC are different anyway. Note further that progressive mode also requires that an AC scan may contain only a single component, whereas DC scans can be interleaved with multiple components. That AC scan restriction is not accidentally chosen, it provides option to the optimized AC coding model with EOBrun symbols spanning multiple blocks (which would not work interleaved). Beside those restrictions, the JPEG code permits notable liberality regarding "incomplete" progressive scan configurations with issue of warnings, which can be useful occasionally as shown here. ciao human
[toc] | [prev] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-03 18:32 +0200 |
| Message-ID | <4DC02E2A.78B80C34@elfavo.com> |
| In reply to | #208 |
> For sequential mode only 0-63 is allowed ... in the scan script. In the SmartScale case (as used in your initial approach) the 63 as Se parameter is overriden automatically inside the JPEG code by the block size derived value, and "excessive" progressive scans are also adapted (reduced) automatically in this case. ciao human
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <s.gesemann@gmail.com> |
|---|---|
| Date | 2011-05-03 06:22 -0700 |
| Message-ID | <06670647-eea6-489e-8ec2-ec89d1e712cf@j28g2000vbp.googlegroups.com> |
| In reply to | #203 |
On 3 Mai, 12:32, Phil Carmody wrote: > > http://fatphil.org/images/crappyjpg.jpg > > Is there any simple fix to remove the chessboarding? It seems obvious > that the chessboarding is the (8,8) coefficient in the DCT, so perhaps > I just need to strip all non-zero (8,8) coefficients from the file. Is > there a utility that can do that? One that otherwise doesn't change > the file would be best. I don't know of a tool that does that. But I agree with you that it should do the trick in theory. > One idea was to use jpegtran -scale 7/8 | jpegtran -scale 8/7 to > just remove all of the (x,8) and (8,y) coefficients. Which is more > than I need, but probably causes no losses of other frequencies that > I would object to. Can anyone see any downsides to that? (The results > look like an improvement to me.) I think a "normal lowpass filter" is preferable. Scaling twice involves a bit of aliasing and imaging and if you want to do it correctly, also lowpass filtering. Just skip the resampling part and apply a lowpass directly. In case you have Matlab or Octave, I would recomment a 2nd order Butterworth filter that is applied bidirectionally -- first in one dimension, then in the other. This way, you have a great control over the cutoff frequency and it's fast. As an alternative, a FIR filter might do. Photoshop as well as Gimp allows you to enter filter coefficients (5x5 or even 7x7). You could try to create a filter that specifically removes the checkerboard: -1 3 -4 3 -1 3 -9 12 -9 3 -4 12 128 12 -4 3 -9 12 -9 3 -1 3 -4 3 -1 (Divisor: 144) This should not blur the image too much but mostly get rid of checkerboard artefacts. > On an 'implementation' note, it does look like that noise is a > programmatic error in the original jpeg compression code (I have no > idea what created it) rather than some horrific scanner/scaling/aliasing > artefact. I think there was lots of high energy noise in the original image. Strong compression means coarse quantization. Sometimes the high frequency coefficient (8,8) was quantized to zero and sometimes it got quantized to some larger nonzero coefficient. Cheers! SG
[toc] | [prev] | [next] | [standalone]
| From | Phil Carmody <thefatphil_demunged@yahoo.co.uk> |
|---|---|
| Date | 2011-05-03 18:03 +0300 |
| Message-ID | <87y62nx1vx.fsf@bazspaz.fatphil.org> |
| In reply to | #205 |
Sebastian <s.gesemann@gmail.com> writes: > On 3 Mai, 12:32, Phil Carmody wrote: > > > > http://fatphil.org/images/crappyjpg.jpg > > > > Is there any simple fix to remove the chessboarding? It seems obvious > > that the chessboarding is the (8,8) coefficient in the DCT, so perhaps > > I just need to strip all non-zero (8,8) coefficients from the file. Is > > there a utility that can do that? One that otherwise doesn't change > > the file would be best. > > I don't know of a tool that does that. But I agree with you that it > should do the trick in theory. > > > One idea was to use jpegtran -scale 7/8 | jpegtran -scale 8/7 to > > just remove all of the (x,8) and (8,y) coefficients. Which is more > > than I need, but probably causes no losses of other frequencies that > > I would object to. Can anyone see any downsides to that? (The results > > look like an improvement to me.) > > I think a "normal lowpass filter" is preferable. Scaling twice > involves a bit of aliasing How can it? Only the frequencies we're interested in are preserved on scaling down, and no frequencies we're not interested in are introduced on scaling up. The operation's purely done in frequency-space. > and imaging and if you want to do it > correctly, also lowpass filtering. Just skip the resampling part and > apply a lowpass directly. > > In case you have Matlab or Octave, I would recomment a 2nd order > Butterworth filter that is applied bidirectionally -- first in one > dimension, then in the other. This way, you have a great control over > the cutoff frequency and it's fast. > > As an alternative, a FIR filter might do. Photoshop as well as Gimp > allows you to enter filter coefficients (5x5 or even 7x7). You could > try to create a filter that specifically removes the checkerboard: > > -1 3 -4 3 -1 > 3 -9 12 -9 3 > -4 12 128 12 -4 > 3 -9 12 -9 3 > -1 3 -4 3 -1 > > (Divisor: 144) > > This should not blur the image too much but mostly get rid of > checkerboard artefacts. I did consider such a filter (or similar). A quick run of the noise reduction function in graphicsmagick (or whatever it's called) wasn't able to completely remove the checkerboard. It of course removed different noise types all over the image, which isn't a bad thing. However, I preferred to just address the artefacts I considered to be the 'bug', as I didn't want to throw away anything I didn't need to. > > On an 'implementation' note, it does look like that noise is a > > programmatic error in the original jpeg compression code (I have no > > idea what created it) rather than some horrific scanner/scaling/aliasing > > artefact. > > I think there was lots of high energy noise in the original image. > Strong compression means coarse quantization. Sometimes the high > frequency coefficient (8,8) was quantized to zero and sometimes it got > quantized to some larger nonzero coefficient. Could be. Thanks for your input. Phil -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." -- Matthew Vernon
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <s.gesemann@gmail.com> |
|---|---|
| Date | 2011-05-05 04:18 -0700 |
| Message-ID | <425999b8-260b-44d1-9591-282d22c89566@a10g2000vbz.googlegroups.com> |
| In reply to | #206 |
On 3 Mai, 17:03, Phil Carmody wrote: > Sebastian writes: > > Phil Carmody wrote: > > > [...] > > > One idea was to use jpegtran -scale 7/8 | jpegtran -scale 8/7 to > > > just remove all of the (x,8) and (8,y) coefficients. Which is more > > > than I need, but probably causes no losses of other frequencies that > > > I would object to. Can anyone see any downsides to that? (The results > > > look like an improvement to me.) > > > I think a "normal lowpass filter" is preferable. Scaling twice > > involves a bit of aliasing > > How can it? Only the frequencies we're interested in are preserved on > scaling down, and no frequencies we're not interested in are introduced > on scaling up. The operation's purely done in frequency-space. 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. Unfortunately, lowpass filtering "in the DCT domain" introduces some new blocking artefacts if blocks are handled independently. > > > [...] > > > On an 'implementation' note, it does look like that noise is a > > > programmatic error in the original jpeg compression code (I have no > > > idea what created it) rather than some horrific scanner/scaling/aliasing > > > artefact. > > > I think there was lots of high energy noise in the original image. I actually meant "lots of high _frequency_ noise". > > Strong compression means coarse quantization. Sometimes the high > > frequency coefficient (8,8) was quantized to zero and sometimes it got > > quantized to some larger nonzero coefficient. SG
[toc] | [prev] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-05 13:35 +0200 |
| Message-ID | <4DC28B80.F82CF30E@elfavo.com> |
| In reply to | #212 |
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
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <s.gesemann@gmail.com> |
|---|---|
| Date | 2011-05-06 00:23 -0700 |
| Message-ID | <946afd41-cc84-4339-b13a-1ac83d8a5fc0@s14g2000vbi.googlegroups.com> |
| In reply to | #213 |
On 5 Mai, 13:35, human wrote: > Sebastian wrote: > > [...] > > 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. If this is a joke, I don't get it. You might want to google for "a pixel is not a square" and brush up your understanding of the sampling theorem. Cheers! SG
[toc] | [prev] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-06 14:24 +0200 |
| Message-ID | <4DC3E870.7D929774@elfavo.com> |
| In reply to | #214 |
Sebastian wrote: > > You might want to google for "a pixel is not a square" and brush up > your understanding of the sampling theorem. Thank you, but I prefer perceived reality over poor theory. ciao human
[toc] | [prev] | [next] | [standalone]
| From | Thomas Richter <thor@math.tu-berlin.de> |
|---|---|
| Date | 2011-05-06 20:33 +0200 |
| Message-ID | <iq1eu5$qlh$1@news.belwue.de> |
| In reply to | #217 |
On 06.05.2011 14:24, human wrote: > Sebastian wrote: >> >> You might want to google for "a pixel is not a square" and brush up >> your understanding of the sampling theorem. > > Thank you, but I prefer perceived reality over poor theory. Guido, I assume you didn't follow Sebastian in first place. At least your response doesn't seem to indicate any understanding. Here is it again: If your goal is to low-pass filter an image, removing high frequency components by eliminating AC components only in a block based design is not a good idea. You still don't remove AC components in the image due to the block boundaries. Thus, this plain and simple filter isn't quite as effective as you seem to advocate it. Of course it is fast, no doubts about it, but this probably not exactly what the user wants - for the problem of the OP, however, it is of course perfect because the error was introduced in the block basis in first place. Nevertheless, block-based filtering and FIR filtering are not the same thing if blocks are in the game. Aliasing due to pixel edges can of course be avoided by proper pre-filtering, i.e. removing frequency components higher than the ones induced by the pixel grid. This can be done by optics alone. Thus, pixels aren't the problem. Blocks are. For some applications at least. So please, relax, and take Sebastian's comment serious. It wouldn't hurt. So long, Thomas
[toc] | [prev] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-08 09:52 +0200 |
| Message-ID | <4DC64BB1.77617120@elfavo.com> |
| In reply to | #219 |
Thomas, your theory wasn't called "poor" by accident. The DCT is a particular phenomenon and is associated with its own theory and set of theorems. The second fundamental theorem explains why the DCT block representation is not worse than the basic pixel representation of digital images. You don't understand this, because you simply don't have the right methods to recognize this, and you are primarily busy with theoretic speculation, that's why you will always fail in reality and jump from one mistake to the next. ciao human
[toc] | [prev] | [next] | [standalone]
| From | Thomas Richter <thor@math.tu-berlin.de> |
|---|---|
| Date | 2011-05-08 15:27 +0200 |
| Message-ID | <iq65na$sjg$1@news.belwue.de> |
| In reply to | #221 |
human schrieb: > Thomas, your theory wasn't called "poor" by accident. > The DCT is a particular phenomenon and is associated > with its own theory and set of theorems. So far, you haven't said anything, neither explained anything. > The second fundamental theorem explains why the DCT > block representation is not worse than the basic > pixel representation of digital images. Which, actually, wasn't the question to begin with. The OP question was answered, what remained was the question how to design a digital filter, and a block based DCT isn't the answer for reasons already indicated. > You don't understand this, because you simply don't > have the right methods to recognize this, and you > are primarily busy with theoretic speculation, > that's why you will always fail in reality and > jump from one mistake to the next. Science is driven by experiments and validation (or falsification), of course, and I agree on these means. I'm not quite sure what you mean by "mistakes" because you haven't been explicit, but you surely have good arguments and and present reasoning and support for these ideas of yours. My reasoning is that of mathematics on one hand, and experiments on the other, and both speak for my point of view. So here are a couple of options I can offer you (and as always - believe it or not - I'm not your enemy. I'm trying to help you to gain some understanding how things work): a) Since you seem to be driven off into the domain of compression and image quality (which wasn't quite the question, see above, but anyhow), I can send you a paper on a couple of subjective experiments colleagues from Lausanne did on various compression methods. Subjective studies using strictly controlled conditions, in a vision lab. I don't have such a lab here and hence cannot do that myself. I just want to give you an impression how things *are* done, and supposed to be done. It's not "I myself looked at a couple of images and my impression is...". Your impression is irrelevant, and so is mine, for exactly the same reasons. Our visions are spoiled, and this should be acknowledged by testing properly, and under conditions that matter. It's not so easy to setup *good* tests, and what I could send you would be a report on such a careful investigation to give you some insight of what people are actually doing (instead of what you believe what they are doing.) b) Probably this forum isn't adequate for presenting your ideas, hence I would like to offer you an opportunity to present your ideas to a better and wider audience instead of just the usual freaks here. As it happens to be, the next JPEG meeting is in Berlin from July 11th to 15th, and I would like to invite you to join us. For two reasons, namely to get you in touch with the serious people and see how they (and I) are working, and to give you an opportunity to present what you have to say to them. Since I'm organizing the meeting this time, I'm also giving you the opportunity to drop the meeting fee for you which is for the social only, so all you would need to cover would be transportation and lodging. Does this sound like an offer? Again, this is not any type of "conspiracy" as you seem to believe. I'm just saying that I'm as open as possible, and to give you an insight of what is going on. Your problem is not that you haven't done anything. Your problem is rather that you don't know what else is going on, and what people actually *do know* and what you do not know. I'm offering you the opportunity to widen a bit your horizon, so to say, and I hope that this works a bit better than just arguing - namely getting under the people and talk to them. So long, Thomas PS: If you have any questions on the meeting - yes, I'm serious, this is not a trick - please contact me by mail. My mail is valid, and if you want to join, I'll try to arrange things for you. Seriously.
[toc] | [prev] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-08 17:55 +0200 |
| Message-ID | <4DC6BD08.79C2123@elfavo.com> |
| In reply to | #222 |
Thomas Richter wrote: > > So far, you haven't said anything, neither explained anything. You wouldn't go to the apes in the zoo to carry on an intelligent conversation, would you? Look, I went to a similar invitation five years ago (the meeting in Geneva) and tried to explain something, and the result was that another mistake was introduced by your crowd. I have tried to prevent that mistake by warning the people who were in contact with me, but the force from certain parties was so strong that nobody kept reason. So I went to other people who listened more carefully and who were able to support my work so that I could get to the results which are available now. And this is only a fraction of the potential that still has to be realized. Something can be found in the available meeting document, but afterwards even more conclusions were found (like the mentioned second fundamental theorem, and more), but they were obviously no more published in the insane zoo neighborhood, but in a more fruitful environment. > Which, actually, wasn't the question to begin with. > The OP question was answered, Yes, and that question was not answered by yours or Sebastians theoretical explanations - it was answered by my straight practical hints, because I know and understand the software he (the OP) is working with. > Science is driven by experiments and validation (or falsification), > ... Your understanding of science is as poor as your understanding of image coding and DCT in particular, and that's why it will be very difficult to carry on a fruitful conversation whith you guys. You are under a major misapprehension to believe that you could help me to gain some understanding how things work. I know how things work in reality, and you are only speculating. So it is you who needs to understand how things really work. I have seen what you are doing, and that is fruitless for real application. It may help yourself, but not me and the work to be done. So that's why a conversation will be difficult: we are just under opposite assumptions. If you are still interested in a meeting, I could talk to my people whether we should engage with you (we operate from Switzerland and Germany, and Berlin is actually nearer to my home than Geneva or Lausanne). But note: I have little interest in seeing your speculations, and you would need to listen to the responsible person. That is of course a learning process. I was also ignorant some time before, so I understand your position. I had to find a master, a guru, who would enlighten me, and that fortunately happened. The question is whether you are prepared to get enlightened - you are unfortunately in a position which is quite far away from that blissful state, that's why I am sceptical. However, there is really no need to see each other as enemies. The term "Transformation" is nice - it does not only appear as core of image coding, but also as core in the science of enlightenment, where it is called the "Transformation of Consciousness". And I would have some very practical and acceptable suggestions for you how we could transform your mistakes into useful features, so that not all your effort would appear wasted - but again, this requires careful attention and readiness from your side. ciao human
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <s.gesemann@gmail.com> |
|---|---|
| Date | 2011-05-08 07:56 -0700 |
| Message-ID | <cd707c8c-0c64-47c5-aa97-62392e5eb5c4@s14g2000vbi.googlegroups.com> |
| In reply to | #221 |
On 8 Mai, 09:52, human wrote: > [...] I don't know what exactly you are talking about. All I see are vague hints at some "particular DCT-related theorems" and comments that suggest to me that you have trouble putting the things you (believe to) know about the DCT into a proper context. All Thomas and I said was that lowpass filtering by (1) partitioning the image into non-overlapping blocks (2) proccessing blocks independently will result in a blocky image. This is because any non-trivial filter would require cross-block interaction. Whether "processing blocks" involves DCT and/or iDCT does not matter at all, actually. Cheers! SG
[toc] | [prev] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-08 18:44 +0200 |
| Message-ID | <4DC6C852.C7ABB529@elfavo.com> |
| In reply to | #223 |
Sebastian The major problem that I have with you is that you did not undergo a process which is called "Transformation of Consciousness". What does that mean? You are not conscious. And of course you don't recognize this because your intellect covers up the consciousness. All I see in your statements is intellectuality, but there is no sign of consiousness. Consciousness is the more essential part, it is deeper than the intellect, and only with consciousness can you use your intellect fruitfully. Without consciousness all your intellect will be fruitless, because it is conditioned by abstract, dead, thoughts which prevent you from seeing the lively reality. Your statements are conditioned by dead theory, you need a fresh look. And that fresh look, which I call consciousness, is beyond the intellect and all thoughts, it is a transcendent quality, timeless, eternal. And due to your conditioned mind without consciousness, you could only react to the original question, but not respond. What is the difference between reaction and response? Re-action is a replication of your accumulated thoughts from the past, response is a spontaneous operation in the present situation. Responsiveness is intelligence, is creativity, otherwise you are only stupid, repetitive. Try to understand. Understanding is consciousness, is intelligence. There is a science of "Transformation of Consciousness", but it is not taught at established schools and universities. And everything what they do works against it rather than support it. That is the problem. But you can find the hints if you are ready and willing. ciao human
[toc] | [prev] | [next] | [standalone]
| From | Sebastian <s.gesemann@gmail.com> |
|---|---|
| Date | 2011-05-08 10:21 -0700 |
| Message-ID | <6af5e3ba-bf14-451b-b246-dacd9de84473@o7g2000vbn.googlegroups.com> |
| In reply to | #225 |
On 8 Mai, 18:44, human wrote: > [...blah...] It seems you did not understand a word of what Thomas and I said recently w.r.t. block-based lowpass filtering. Maybe this is why you did not respond to it and instead speculated about other people's intelligence. SG
[toc] | [prev] | [next] | [standalone]
| From | human <noreply@elfavo.com> |
|---|---|
| Date | 2011-05-09 10:51 +0200 |
| Message-ID | <4DC7AB04.58968C72@elfavo.com> |
| In reply to | #226 |
Sebastian I am responsible for the actual JPEG code and standard development. That responsibility requires great consciousness, so I have little energy left for your intellectual speculation. See the situation: You and Thomas are great intellectual speculators, but you are not responsible for the actual JPEG code and standard development. Make that clear: The official JPEG committee and representatives are not responsible for the actual JPEG code and currently available de-facto standard (which goes beyond the original standard paper). So it appears that either you can be responsible, which requires a large part of your energy, or you can be speculating. Both can hardly go together. I cannot speculate, because I am responsible for the real thing. That is the difficulty. I have expressed my willingness to try a communication, but I cannot give up my responsibility, you have to consider that. There must be someone who takes the responsibility, and I happen to be that person, there is no-one else. You like to speculate, but obviously you don't take responsibility. Try to understand that, we will see how we can meet. ciao human
[toc] | [prev] | [next] | [standalone]
| From | Thomas Richter <thor@math.tu-berlin.de> |
|---|---|
| Date | 2011-05-09 11:49 +0200 |
| Message-ID | <iq8dbq$qra$1@news.belwue.de> |
| In reply to | #227 |
Am 09.05.2011 10:51, schrieb human: > Sebastian > > I am responsible for the actual JPEG code and standard development. No, you aren't. You are, at best, responsible for a specific implementation. The folks responsible for the standard are we. (-; That said, as I already mentioned, I made you an offer. It is all up to you. But please don't lie.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.compression
csiph-web