[XviD-devel] Idea for encoding iframes (or images for that matter)

[Christoph Lampert]

Hi Ricardo,

as you seem to have noticed, there are millions of way to encode images, 
and even more for video. But what you describe has nothing to do with 
MPEG. I also can't see how encoding image blocks in quad-trees is supposed 
to _compress_ the image. If you really go down to pixel resolution, and 
get 1 vector per pixel? 

Anyway, if you really are interested in MPEG-4, you should definitely 
start the way I described. You will need background before you can improve 
it. 
If you are more interested in your own ideas, not connected to MPEG, maybe 
xvid-devel isn't the right place for a discussion, but rather the 
comp.compression newsgroup.

chl


On Sat, 7 Aug 2004, Ricardo Garcia wrote:
> Hi again. 
> 
> I have a few ideas in my mind about encoding.
> 
> Warning: wacko scientist talk below. Research in Image Processing
> recommended.
> 
> The ideas are about making quadtree encodings for I-frames (or who
> knows, B-frames too, and maybe implement a mixture of both,
> N-dimensional encoding after processing all frames, who knows?).
> 
> But I have to know if it would be MPEG4 compatible (in theory i hope it
> is, because I read that MPEG4 is extendable - or was that H.264? Argh
> can't remember). or the heck if it works we could .
> 
> My idea is that a greyscale block could be also seen as a 3D plane in
> space. The average value would be the center of mass of the finite
> plane. However, we can define a perpendicular vector coming from that
> center, and so we can rotate the plane in 3D to approximate our image.
> 
> A simple gradient could be stored with just 2 vectors. 
> 
> Now,
> Split the square in quadrants, and re-calculate the center of mass and
> rotation for each, storind their difference to the quadtree.  
> 
> Repeat the recursion until you get to pixel resolution. 
> 
> Actually, it would be done backwards. Start with 2x2 areas, calculate
> the vectors, recalculate in pyramid scheme, and once you get the
> definition pyramid (quadtree actually), calculate the diference as i
> explained at first.
> 
> I really don't know if wavelets do something like this, I just know
> that they split the image in frequency-scale quadrants, and re-apply
> recursively to the upper half.
> 
> Does anybody know if my idea has been already
> implemented/tested/reported as complete failure?
> 
> Well, at least I know that it "looks" faster than applying DCT, or full
> wavelets. What do you think?
> 
> One idea would be having for the "global" plane, two vectors (one x,
> one y - or maybe one x-y) for bending and twisting the image plane. The
> vectors could be the coefficients for wavelets or polynomials,
> whatever. So we could start with a *simple* profile for this, and later
> other guys (codecs) could improve their analysis and provide more
> efficient vectors.
> 
> If anybody is interested in the idea, he's free to try it and publish
> the codec as open source (GPL or LGPL, LPGL preferredly ;-) ).
> 
> Anyway, this is the reason why i was interested in the "how it works"
> algorithm of divx/xvid.
> 
> What do you think?
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail 
> _______________________________________________
> XviD-devel mailing list
> XviD-devel at xvid.org
> http://list.xvid.org/mailman/listinfo/xvid-devel
>