Re: the basic idea of my codec

> > The major limatation of those devices is lack of coditional jumps. It's
hard
> > to perform any adaptive coding whe you can't adapt...
> > [...]
> > I think (almost sure) it's impossible do do entire decoding process in
GPU.
> > I can't imagine decoding a Huffam on those machines, and arithetic
coders/range
> > coders are far more complex... But I might be wrong.
>
> No. The idea is that a GPU perhaps could help with the heavy transforms,
> i.e.
> the math- and memory-intensive number-crunching.
> The CPU would still do all decoding up until the inverse wavelet
> transforms.
>
> The adaptive transform that you suggested is next to impossible to
> implement
> on a GPU because it requires bookkeeping from one coefficient to the
> next
> and we can not specify the evaluation order.
> However, there are other adaptive transforms that don't require
> bookkeeping
> but that do require conditional jumps.
>
> Your algorithm would be quite complex, because if the adaptivity is
> going
> to be worthwhile there would have to be many kernels.
> Not just different sizes of circles, but also several combinations
> of oval-shaped kernels to achieve the same level of adaptivity as
> a 1-D transform would.

Yup, that's the idea. ;-)
But currently designs is concentrationg on 2D+T version of the algortihm.
Yup, I know, even more kernels. But adaptivity in 2D+T can make the motion
compensation obsolete. I'm designing two variants of algorithm:
1) update then predict
    in this one kerenel would be choosed by analysis of details in lower
resolution step
    pros: no aditional information
    cons: worse adaptivity due to predict then update
2) predict then update
    in this one information which kernel should be used must be embedded
into the bit stream
    pros: simpler and faster decompression
            posibility of compression ratio/decompression complexity tradeof
    cons: lower compression ratio

> > And anyway - you can divide the image into separate red and black blocks
> > (sort of de-interlave process) and you find that kernel matrix has no
> > "holes".
>
> Great.
>
> > But really... why ? why do it on the GPU not CPU ?
>
> If you can, then why not? There would be a substantial performance
> boost.
> Hardware support is already widely available, has added value (i.e.
> games)
> and the price of an able card is reasonable, falling rapidly.

I agree, that running the entire algo on GPU would be enormous speed boost.
But my design principle is simple - best compression ratio. CPUs are getting
faster and faster, so even if the GPU approach would be impossible on
designed alogorithm, in time it's been fully functional - CPU should handle
it (18 months -> dryhstones * 2 ). Of course designing a complex alogirthm
i'm restricting the spectrum of its possible applications... but hey,
embedded CPUs are getting faster too ;-)


> Anyway, this is just a wild thought, not something that I have been
> concentrating on.

I'm apperciating this very much. Comstructive discussions it the bbb (basic
building block) of an algorithm. ;-)


> If you are working on 2-D transform code, please mail it to when it is
> functional.
> I am trying to find ways to compress wavelet coefficients more
> efficiently
> and so far I have concentrated on 1-D non-adaptive transforms.
> Hmm.. sign prediction is going to be fun ...

Have you tried the embedded-zerotree alike transform called tetrary-tree ?
The range of coeficient is compared against 3 ranges named +,0,-. Each of
ranges hane its representative value, which has property of minimal
introduced error (MSE) if it would be choosed as an aproximation. If range
is 0 - the proces is repeated, if its non-zero - you allready have a sign,
and further divisions can be consigered as a binary tree. The tree has
property , that truncation on each step introduces minimal MSE error. The
stream of bits can be easily compacted uning arithmetic coder or range
coder. Simple context modelling would (for example encoding differencies
against the parent) would exploit he coherencies with signal on previous
scales. It's approach i'm going to use. Additionally it can be calulated
adaptivelly ;-).


Currently I'm very busy at work - but I'm doing some small tests and
thinking on 3D transform. If you're interested I can describe my
interlaving, and some simple thoughts about filter bank. The first
functional code should be ready in a month or so.


...and if anyone has a good paper describing how intensity of lume changes
sensitivity to chroma in HVS - i would very much appreciate it.

salutations

Maciej



--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to '[email protected]'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.