Hi-res picture packer?
gnudutch
I'm looking for a program that I used in the past for compressing hi-
res pictures. I think the name was "Hi-res picture packer" or
something similar. I thought it was from Nibble magazine, but after
purchasing the complete archives I am unable to find the program.
(There is a "Super Hi-res picture packer" which may explain my
confusion)
I've seen other programs that can pack pictures, including Beagle Bros
scrunch. But the one I want is different because it was menu driven
and it turned the hi-res screens into binary files that you can BRUN.
It also featured a pleasant reveal effect. It was terrific for
spicing up Applesoft programs.
Does anybody remember this beast? It ran fine under ProDOS and it was
from the 1989-1990 time frame.
Thanks for any help,
--g
ict@ccess
There were no packed pictures that could be BRUN that I know of, as
that would mean the decompression algorithm would need to be included
with the picture, and that extra overhead would kind of defeat the
space savings from a decompressed file to begin with. There are a
number of ways to make a graphic BRUNnable. The simplest would be to
put a small header at the beginning of each graphic like this:
$1FED: 2C 54 C0 2C 57 C0 2C 52 C0 2C 50 C0 20 C FD 2C 51 C0 60
The graphic starts at $2000-$3FFF for page 1 and $4000-$5FFF for page
2. If you would like the graphics to start on page 2 then a slight
change to the header:
$3FED: 2C 55 C0 2C 57 C0 2C 52 C0 2C 50 C0 20 C FD 2C 51 C0 60
Then to save the graphic
BSAVE graphic,A$1FED,L$2013
There is also a way to insert this code into the screen holes within
the graphic itself so the file is no longer than $2000 bytes, I have
that program as well that allows you to do this.
If you want higher compression, I wrote a graphics compression program
that compresses a little better than Scrunch and saves on average 2-3
extra blocks under Prodos or 4-6 sectors under Dos3.3
I have also expanded the compression algorithm to handle double hi-res
graphics and can save from 3-7 blocks under Prodos over Double Scrunch
Rob
gnudutch
> There were no packed pictures that could be BRUN that I know of, as
> that would mean the decompression algorithm would need to be included
> with the picture, and that extra overhead would kind of defeat the
> space savings from a decompressed file to begin with.
Yup I don't know how they did it but it was able to crunch the 17
block image into less than 10 blocks including the BRUN loader. I know
I'm not imagining this because I made slide show discs this way that
carried over 20 pics each. The nice part was being able to BRUN them
because the Beagle type loaders are too cumbersome. And the loader
would even draw the picture in with a nice wipe effect.
> There are a
> number of ways to make a graphic BRUNnable. The simplest would be to
> put a small header at the beginning of each graphic like this:
>
> $1FED: 2C 54 C0 2C 57 C0 2C 52 C0 2C 50 C0 20 C FD 2C 51 C0 60
Thanks, I've seen this trick but it seems mostly a novelty, since
there is no space savings.
> If you want higher compression, I wrote a graphics compression program
> that compresses a little better than Scrunch and saves on average 2-3
> extra blocks under Prodos or 4-6 sectors under Dos3.3
>
> I have also expanded the compression algorithm to handle double hi-res
> graphics and can save from 3-7 blocks under Prodos over Double Scrunch
>
> Rob
Yeah I'd love to see your work, could you point me to it?
--g
Charles
Do you have a memory of typing it in from scratch?
Maybe it was included on an issue of Softdisk?
gnudutch
>The program "Hi-Res Picture Packer" by Mike Dorffer was included in the
>next to last issue (December 1988) of Compute!'s Apple Applications. It
>runs and displays a menu letting you Load or Pack a standard picture,
>Load a packed picture, change the disk drive, CATALOG a disk, and QUIT.
>You can load a picture, pack it and then save it to disk saving valuable
>space. The picture is then BRUNable but loads the image onto HGR2. You
>can also load the picture by BLOADing it and then doing a CALL 24576.
>Before doing the CALL 24576, you can do a POKE 24585, 32 * page to load
>it onto either Hi-res page 1 or 2. It runs under DOS 3.3 or ProDOS. I
>don't know about a "reveal effect", but it does everything else that you
>mention and I believe is what you are looking for.
Thanks Dan!!!
--g
ict@ccess
I tried to send you my Hires packer, but your email bounced back.
Send me an email if you are still interested.
Rob
ict@ccess
> Send me an email if you are still interested.
>
> Rob
Anyone wanting to download my version of Hires and Dbl Hires (only one
program) picture packer can try here
http://216.197.169.245/Apple%20II%20Programs/compression.zip
Here is what my program can do.
It can compress both single res and dbl res graphics.
Works under Prodos and Dos 3.3 (the compression/decompression part
does but the file loader works under Prodos only)
Fairly high compression.
can compress all or any part of the screen you designate
can be used to compress animated sequences in the same spot on a
screen. Due to the way the pixels are drawn to the screen, for
instance, if the first frame contains say, a background, only the
pixels in the second frame that have changed from the first frame, are
compressed in an animated sequence. So, the background would not need
to be redrawn in the 2nd frame. This allows for very high compression
of the animated sequence.
Very fast load and decompression due to file size. Should be able to
load and decompress a graphic faster than loading an uncompressed
graphic from a hard drive.
Rob
ict@ccess
> Send me an email if you are still interested.
>
> Rob
Anyone wanting to download my version of Hires and Dbl Hires (only one
adamhall
Nick Westgate
> Can't seem to decompress this file.
@Adam: Are you on Vista? Anyway, 7-zip will unzip the archive.
@Rob: What was this zipped with? The zip app has a bug.
Coincidentally this bug only affects Vista's unzip app
(AFAIK) and I recently debugged an open source zip library
that created archives with the same problem.
Cheers,
Nick.
John B. Matthews
> Can't seem to decompress this file.
>
> <http://216.197.169.245/Apple%20II%20Programs/compression.zip>
Looks OK here.
$ curl http://216.197.169.245/Apple%20II%20Programs/compression.zip >
compression.zip
$ unzip -l compression.zip
Archive: compression.zip
Length Date Time Name
-------- ---- ---- ----
0 07-18-09 00:14 compressors/
143360 07-19-09 11:07 compressors/BeagleGraphics.dsk
143360 01-24-08 17:47 compressors/HiresPicPac.dsk
819264 07-23-09 11:04 compressors/MyDblCruncher.2mg
143360 07-23-09 11:36 compressors/MyDblCruncher.dsk
143360 07-18-09 00:19 compressors/PicPacDoubleRes.dsk
2708 07-23-09 11:39 compressors/Readme
143360 12-09-96 12:36 compressors/SiliconSalad.dsk
-------- -------
1538772 8 files
$ unzip -t compression.zip
Archive: compression.zip
testing: compressors/ OK
testing: compressors/BeagleGraphics.dsk OK
testing: compressors/HiresPicPac.dsk OK
testing: compressors/MyDblCruncher.2mg OK
testing: compressors/MyDblCruncher.dsk OK
testing: compressors/PicPacDoubleRes.dsk OK
testing: compressors/Readme OK
testing: compressors/SiliconSalad.dsk OK
No errors detected in compressed data of compression.zip.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Nick Westgate
> Looks OK here.
Yep, *nix unzip will be fine.
AFAIK only Vista doesn't like this.
("This" being the "external file attributes" byte for the directory
having the directory bit not set. Most unzip apps ignore this, but
Vista sees it as a directory and a zero-length file, giving a
potential conflict during the unzip.)
Cheers,
Nick.
adamhall
It was on a mac , just the regular uncompress program that comes with
Finder. Say the archive is corrupt.
winston19842005
Hall" <Adam Hall> wrote:
I just get "Error 1 - operation not permitted" using the standard "Archive
Utility" of Mac OS X.
If you install "Stuffit Expander", that works...
John B. Matthews
<498b4f2b-cdd7-4e79...@a38g2000yqc.googlegroups.com>,
Nick Westgate <nick.w...@gmail.com> wrote:
> On Jun 29, 11:45 pm, "John B. Matthews" <nos...@nospam.invalid> wrote:
> > Looks OK here.
>
> Yep, *nix unzip will be fine.
> AFAIK only Vista doesn't like this.
I think Adam's on Mac OS X, where unzip from the command line works.
> ("This" being the "external file attributes" byte for the directory
> having the directory bit not set. Most unzip apps ignore this, but
> Vista sees it as a directory and a zero-length file, giving a
> potential conflict during the unzip.)
Interesting! Mac OS X's Desktop/Finder has a problem with these zips,
too.
Nick Westgate
> too.
Actually, after checking the zip APPNOTE docs again, the above is a
misdiagnosis, as this file has the directory bit, but also has a bunch
of others set in the field I mentioned.
"The Unarchiver", which Sean recommends recently "Added support for
zip archives created by ZipIt." which is what created this archive I
think.
Cheers,
Nick.
Andy McFadden
> Archive: compression.zip
> Length Date Time Name
> -------- ---- ---- ----
> 143360 01-24-08 17:47 compressors/HiresPicPac.dsk
You need to use "-v" to see the interesting part:
Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
143360 Implode 60517 58% 07-19-09 11:07 57c98c50 compressors/BeagleGraphics.dsk
143360 Implode 65726 54% 01-24-08 17:47 d0bace05 compressors/HiresPicPac.dsk
...
Note the method is "Implode", which went out of vogue many years ago
after Unisys got twitchy about LZW.
It'd be more portable -- and 50KB smaller -- if the common Deflate
algorithm were used.
--
Send mail to fad...@fadden.com (Andy McFadden) - http://www.fadden.com/
Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/
winstonsmith
> John B. Matthews <nos...@nospam.invalid> wrote:
>
> > $ unzip -l compression.zip
> > Archive: compression.zip
> > Length Date Time Name
> > -------- ---- ---- ----
> > 143360 07-19-09 11:07 compressors/BeagleGraphics.dsk
> > 143360 01-24-08 17:47 compressors/HiresPicPac.dsk
>
> You need to use "-v" to see the interesting part:
>
> Length Method Size Ratio Date Time CRC-32 Name
> -------- ------ ------- ----- ---- ---- ------ ----
> 143360 Implode 60517 58% 07-19-09 11:07 57c98c50 compressors/BeagleGraphics.dsk
> 143360 Implode 65726 54% 01-24-08 17:47 d0bace05 compressors/HiresPicPac.dsk
> ...
>
> Note the method is "Implode", which went out of vogue many years ago
> after Unisys got twitchy about LZW.
>
> It'd be more portable -- and 50KB smaller -- if the common Deflate
> algorithm were used.
>
Yes, but then I wouldn't be able to use my Dezip program I wrote for
the TI-99 back in 1989 on it!
I gave up when v2.04 came out - the memory usage was just too much for
32k! I already had to use an overlay and store half of one of the
stacks in VDP RAM... I almost tackled it again about 10 years ago, but
thought better of it...
Andy McFadden
> I'm looking for a program that I used in the past for compressing hi-
> res pictures.
Just for fun I tried applying LZSS to hi-res images. I compared the
results to the "axe packer" from the posted disk images, which appears
to do the typical RLE on alternate bytes.
It did pretty much what you'd expect: better on "complex" images, not
as well on "simple" images. Anything with a solid color background and
relatively little activity does well with RLE, and the relatively short
match lengths in LZSS (max 18) can't compete. I tried increasing the
match length while decreasing the maximum match distance to keep the total
encoding at 16 bits, which helped for some images but not others.
Interestingly, splitting the image into odd/even sections and compressing
them produced poor results. I think splitting reduces the lengths
of each run, and if you compress the halves individually you're
restarting the compressor halfway through.
I suspect performing a first pass with 1- or 2-byte RLE and a second with
LZSS would work pretty well. The LZSS decoder is very simple, making it
well-suited for this application.
Another possibility is LZB, which can use variable-length matches to
great effect, but the decoder is not so simple.
ict@ccess
Sorry I didn't get back to the forums sooner. Was on a bit of a
holiday. :)
I used ZipIt on a Mac. I used the implosion method first which stated
it was more compatible, but my Mac under OSX couldn't even decompress
it, then I changed the compression to deflate, and it works on my Mac
now.
My PC crashed, so I will have to reinstall the OS to get it back up
and running, but normally I would have used WinZip to compress to a
zip file.
Rob
Nick Westgate
> Sorry I didn't get back to the forums sooner. Was on a bit of a
> holiday. :)
Good for you. ;-)
> I used ZipIt on a Mac. I used the implosion method first which stated
> it was more compatible, but my Mac under OSX couldn't even decompress
> it, then I changed the compression to deflate, and it works on my Mac
> now.
Yeah, I saw that it was ZipIt, and Andy worked out that it was
imploded. It produced strange results on Vista too, though the files
were accessable.
Cheers,
Nick.