🚀 go-pugleaf

jmd@nesos.ugr.es (Javier Mateos Delgado) writes:
> I'm looking for a program to perform AC rediction for suppression
> of block-to-block disontinuities in decoded JPEG images as defined
> in the ISO DIS 10918-1 Requerements abd guidelines. Annex K.8.

Old versions (v3 and v4) of the free IJG code included a module to
do interblock smoothing along the lines suggested by K.8.  However,
the capability was never really useful and it's been dropped in v5.

What the spec fails to make clear is that K.8-style smoothing is only
useful under very limited circumstances.  You have to know the DC
coefficients pretty accurately, since they are the basis of the
prediction.  But you don't know the AC coefficients accurately
(otherwise you wouldn't be bothering to estimate them).  Furthermore,
it turns out that you do want to know the large AC coefficients,
because those won't be predicted correctly: the whole point of K.8 is
to assume that the target block is smooth, ie, only small AC values.

One possible way that these conditions could be met is in low-quality
baseline JPEG work (if DC is quantized much more finely than the AC
coefficients).  In theory you could predict the AC values to better
accuracy than their quantization level.  That was what the IJG code
was intended for.  But, as I said, it never seemed to work very well,
so we dropped it.  Low-quality work has never been a big interest area
for most of our users anyway.

What the JPEG spec authors actually *intended* K.8 to be used for is
estimating small-value AC coefficients during early scans of progressive
JPEG display.  If you send DC first and then use successive approximation
for AC, the conditions for K.8 applicability are met.  It turns out that
K.8 works pretty nicely in this scenario: it gets rid of obvious
blockiness and lets you postpone sending the low-order AC bits.  Note
that in this situation, you are only interested in estimating bits that
will eventually be received anyway: thus you can work with quantized
coefficient values, which is why K.8.2 is written as it is.

We're probably going to put K.8 code back into the IJG decoder's next
release, but in a form that can only be used with progressive decoding.

			regards, tom lane
			organizer, Independent JPEG Group