Re: JPEG [JFIF, really] compression

[P3D Larry Berlin <lberlin@xxxxxxxxx>]

>Date: Mon, 01 Sep 1997
>From: P3D John Ohrt  writes:
>
>>P3D Ol' Three-Eyes wrote:
>> The big largely unexplored area for jpeg is the matter of compression
engines.
>> You could easily make one that did decent compression of cartoons [sudden
>> color boundaries instead of gradual changes] or ones that did a decent job
>> of compressing side-by-side stereo images.
>>
>> It's all a small matter of programming....
>........................................
>My experrience is that an optimizing engine will at least get you a 10%
reduction
>in file size over the default much of the time.  (Remember the default may well
>be the optimal choice on some occassions.)  Personally, I think the quality may
>be a bit better, but I don't know how one would ever measure that!

******  The optimization being sought isn't of reduced file size, but decent
compression with minimal loss in the circumstance of stereo pairs.

>
>A couple of things to avoid are borders and titles etc because they force an
>overall compromise on parameter selection.  Strictly speaking, it could be
argued
>that the "pair" of images in a .jps does compromise quality because of the
>artificial discontinuity where the images meet.  However the scenes are highly
>similar which should give rise to other efficiencies.

*****  The similarity probably doesn't make a huge difference since the
optimizing is done in little areas. The problem is designing the compression
to function in a non-linear fashion.

For example, in an ideal situation, and JPG may not be that environment at
this time, you would identify and maintain continuity of any sharp
delineations. That would keep the juction between two images sharp and
maintain the individuality of titles and significant contrasts. Then
operating within the defined areas, colors and textures are compressed in
such a way that reconstruction duplicates from one side to the other, any
reconstruction pattern that is used. In other words, the existing squares
that JPG uses, would be duplicated from side to side so no retinal rivalry
develops at any level of compression. 

In order to maintain such a thing, the software needs to create an
underlying map of similar points. Once identified in each image, and it
could be done automatically by zone comparisons, related to the contrast
line identification, the images can be *pinned* as it were to a virtual
substrate. compression would take place on both sides simultaneously, zone
by identified zone. The virtual substrate would provide the steering so each
side gets the same treatment. Current methods assume no area similarities
and do the whole thing in a random fashion using a simplistic regular grid.
For stereo, the virtual substrate would provide the function of the previous
grid system.

I don't think this is possible in today's defined JPG, but should it be
possible even if someone just imitates JPG and writes something totally new
intended for stereo, it would be very worthwhile. The secret is in
guaranteeing identical treatment to the defined circumstance of stereo
pairs. Once that is done, you could compress beyond the point of image
recognition and still get a stereo image where what's left is faithfully
applied to each side, to some averaged depth factor. I wouldn't want to use
that extreme an amount of compression, but if the method worked to that
level, I would definitely trust it at normal usage levels.

>
>So since .jpeg is designed for photo quality images, I think your first step is
>to invent a new spec designed for cartoon-like images.


****  That's called vector graphics... and doesn't really do the job for
stereo. We need a system intended for photo type images but able to
recognize and maintain image structures.

Larry Berlin

Email: lberlin@xxxxxxxxx
http://www.sonic.net/~lberlin/
http://3dzine.simplenet.com/


------------------------------