a few facts

[julesg at newebmail.com (Jules Gilbert)]

I realized I omitted something important -- sorry.


This process should not be regarded as lossless; but lossless compressor's can readily be constructed using this method.


Here is how:


Be compressing a buffer containing an imperfect representation of the client data; XOR that imperfect buffer to the actual client buffer;  

Send the map (compress it first!) of the XOR'ed differences.

Of course everything you want to send costs (in space) and the budget cannot exceed the size of the original input buffer.






  ----- Original Message ----- 
  From: Jules Gilbert 
  To: discuss at blu.org 
  Sent: Sunday, August 15, 2004 10:52 PM
  Subject: a few facts


  I did do one demo at MIT in 1996; 


  Also while I am not willing to bring floppies in and do a public demo; I have offered to show certain BLU folks a demo, off-line from a meeting, to video tape the demo, and then to show the video tape at a BLU meeting.


  I don't know yet whether the people I am talking to will agree to this -- and won't know until next week or later, (at least this is my best information at this moment.)


  Also, you guys should simply build the model I described.  IT COMPRESS'ES.  It's not powerful and it's not efficient, but it works.


  Let me try and show you why, because apparently some participants here have a little trouble understanding basic vector algebra.


  First, the client vector (the original buffer) is random;  that won't produce much of value when curve-fit.


  Now, building the monotonic vector merely transforms the X-component (completely random,) to the Y-component, because now the randomness is tied to the Y attribute.  Graph it if you don't get this.  Of course each term used in the curve fit doesn't do much, because the coefficients 'lock' on the largest non-linearity;


  This is why, after the subtraction of the approximation, the residue line has one major discontinuity for each term.  Remember, we are not trying to reduce a 1GB to 1byte here, each curve fit (and subsequent subtraction) simply reduces the magnitude of the residue remaining to be compressed.


  I am sorry to observe these dynamics; I was hoping for someone to come forward and say, I built it and I have the following issues -- or -- I observed ...  

  Here's a little more info; maybe this will help get the right person going...


  The subtractive operation can be replaced by an XOR;  That's less intuitive and doesn't process the left-most three-bit column field as well, but it does substanially improve the remaining right-columns;  Also, doing this to say 128 cells, each 1 bit wide;

  And by applying this process to each vector concurrently, then making a new vector from the residue of each Y'th row produces data with much better characteristics;


  Today my best perpetual compressor's don't use floating point, but (except for the Y[zero] row of course, where no improvement can be obtained,) building a "cross-hatch" vector set has big advantages.


  I am pretty busy these days, (and I don't do compression work any more -- the fighting is just ugly, not why I went into programming at all) but if someone is interested in this stuff, please email me.

  --jg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blu.org/pipermail/discuss/attachments/20040815/334958a7/attachment.html>