peraino@gmu90x.gmu.edu (peraino) (08/17/90)
>Date: Thu, 16 Aug 90 11:45:16 -0400 (EDT) >From: Eric Stuyvesant <es2a+@andrew.cmu.edu> >To: periano@gmuvax.BITNET >Subject: Re: HP-48 application problem; a challenge. >The first thing that seems we have to do is crop the GROB so that we have a >sub-GROB that is just the region we have to work with. It seems that any >algorithm that we use for the later parts must do this. > >Now, for to see if the GROB is entirely on or off: Perhaps you could write >a hash function (BYTES?) that could hash the GROB, then somehow see if the >hash number indicated that the GROB were entirely black or entirely white. >Or, instead of a hash function, maybe do a sum of the GROB, and see if it >is consistent with an N by M blank or full GROB. Thanx for the reply, Eric; Working with the GROB may be the way to go, but unfortunately, I don't think it's all that easy. Remember, GROBs are always rounded up to whole bytes, in terms of the dimensions; so in most cases, there's extraneous data in the GROB. For example, if you have a 4 X 4 solid black GROB, you would think it would look like: GROB 4 4 FFFF but because the dimension is rounded to the nearest whole byte, the GROB looks like: GROB 4 4 F0F0F0F0 so we cannot simply checksum or hash the data as-is. >-Eric Stuyvesant >es2a+hp@andrew.cmu.edu ----------------------------------------------------------------------------- Bob Peraino UUCP : uunet!pyrdc!gmu90x!peraino George Mason University INTERNET: peraino@gmuvax.gmu.edu UCIS, Thompson Hall, rm 2 <- BITNET : peraino@gmuvax 4400 University Drive \ PHONE : (703)-323-2549 Fairfax, VA 22030 \- Yeah, they put us in the basement, too. -----------------------------------------------------------------------------
scottb@hpcvia.CV.HP.COM (Scott_Burke) (08/22/90)
Another idea... There are two methods of cropping: by byte, or by pixel. The former is easier, but won't save as much space all the time. The latter method means code must be written to expand a grob from the 4 pixels/byte storage scheme back out to pixel data, so that a finer cropping can be achieved. Then, after cropping, the pixel data would be re-encoded to the standard scheme, and an upper-left corner would be stored along with the sub-grob. I'm not sure what the purpose of the described scheme is--is it part of an archival system?--but if it's for use in an interactive application, the decompress times are unpalatable. The most compression that can be achieved for an interactive program is simply to have a PC program to crop the grob as finely as possible, and then store the grobs that way. Scott. scottb @ hpcvia.cv.hp.com