JPEG conversion
Bowie Bailey
on the Apple IIgs?
If not, would someone be willing to write one?
For those not familiar, JPEG is a somewhat lossy picture compression format
for 24-bit pictures that generally comes out about 1/4 the size of GIFs.
-Bowie Bailey / b...@springs.cis.ufl.edu
Trent Corney
>Does there exist a format to convert/display the JPEG/TFIF picture format
>on the Apple IIgs?
>
>If not, would someone be willing to write one?
I know of a person that is/was trying to get something like that done for
the GS. But, with his classes starting again, I don't know if he will have
the time to go through and see if he squashed all the bugs. I do know that
on my Zipped GS, it took well over 20 minutes to decompress an 84K picture
into GIF format, and at that the GIF header was messed up.
If you are interested, let me know and I will ask him if it is ok for me to
give out his address so you all can reach him.
--------------------------------------------------------------------------
ProLine: trentc@pro-calgary GEnie: T.Corney
Internet: tre...@pro-calgary.cts.com CIS: 70561,50
UUCP: crash!pro-calgary!trentc
--------------------------------------------------------------------------
The Unknown User
In article <ag4...@pro-calgary.cts.com> tre...@pro-calgary.cts.com (Trent Corney) writes:
>I know of a person that is/was trying to get something like that done for
>the GS. But, with his classes starting again, I don't know if he will have
>the time to go through and see if he squashed all the bugs. I do know that
>on my Zipped GS, it took well over 20 minutes to decompress an 84K picture
>into GIF format, and at that the GIF header was messed up.
Was he just porting (not meant to belittle) the UNIX jpeg2gif
program I've heard about?
Why convert it to GIF format anyway? Why not just have a viewer of
JPEG files?
Is the JPEG format incredibly more complex than the GIF format?
It has always seemed to me that GIF file _creation_ on the GS is what takes
tons and tons of time.. especially seeing what LordHighGiffer does with
GIF viewing. So possibly a program that only viewed JPEGs directly
would be fast enough?
I haven't seen JPEG pictures around, so am not personally in need
of a JPEG viewer. It would probably be a useful utility to have around once
in a while though.
--
/unk...@ucscb.ucsc.edu Apple IIGS Forever! CHEAP CD info-mail me\
|WANT to help get INFOCOM GAMES RERELEASED & ULTIMA VI GS written? - mail me.|
\ Ich Bin Ein Springfielder /
Brian Tao
>
> Is the JPEG format incredibly more complex than the GIF format?
> It has always seemed to me that GIF file _creation_ on the GS is what takes
> tons and tons of time.. especially seeing what LordHighGiffer does with
> GIF viewing. So possibly a program that only viewed JPEGs directly
> would be fast enough?
I don't know if you are familiar with the JPEG lossy compression
method, but it is *quite* math-intensive. The portion of JPEG that gets
most of the work done uses DCT (discrete cosine transforms) applied to
the raster data in chunks of 8x8 matrices. The transformed matrix has
much less variance than the original, and the resulting data is then
compressed using a lossless algorithm like Huffman. To decode, you just
un-Huffman the matrix and then apply a reverse DCT to the matrices. That's
the basic gist of it. Like I said, very math-intensive. The DCT is a form
of Fourier transform, so it appears to be a perfect job to throw at the
NCS/DSP card... ;-)
--
Brian T. Tao =*8-) | ta...@pnet91.cts.com |"Though this be
Dept. of Exobiology | - or - | madness, yet there
University of Toronto | tcom...@bluffs.scar.utoronto.ca | is method in't."
Scott Gentry
> Was he just porting (not meant to belittle) the UNIX jpeg2gif
>program I've heard about?
> Why convert it to GIF format anyway? Why not just have a viewer of
>JPEG files?
> Is the JPEG format incredibly more complex than the GIF format?
Depends.
>It has always seemed to me that GIF file _creation_ on the GS is what takes
>tons and tons of time.. especially seeing what LordHighGiffer does with
>GIF viewing. So possibly a program that only viewed JPEGs directly
>would be fast enough?
GFL on 24-bit (32-bit with alpha channel) JPEG'd pictures. I've seen some
that are absolutely huge (AH for short -- is a term I just made up for
pictures that take up more memory than a target computer is capable of
supporting). With some tricks (at even a greater loss of resolution --
remember, JPEG is a lossy compression method), you should be able to get the
picture into a IIGS, but I don't know if the processing time justifies the
output. Granted, I'm being subjective, but I've filled up memory and
swap space on my workstation before. With all the above in mind, I would
like to see a decompressor/display utility -- but not before TIFF support.
--
*******************************************************************************
* W. Scott Gentry | uucp: uunet!ingr!ne1300!brnded!scott | I didn't *
* Intergraph Corporation| America Online: AFL Scott | mean it! *
*******************************************************************************
Trent Corney
> Was he just porting (not meant to belittle) the UNIX jpeg2gif
>program I've heard about?
>
Yes, he was porting some C code across to the GS platform. From what I have
been told and seen about the code, it doesn't just allow you to decompress the
JPEG pic into GIF format, but also a few others. I believe that TIFF and one
other format is supported as well. But, right now the only format useful to GS
users is as a GIF.
> Why convert it to GIF format anyway? Why not just have a viewer of
>JPEG files?
>
> Is the JPEG format incredibly more complex than the GIF format?
>It has always seemed to me that GIF file _creation_ on the GS is what takes
>tons and tons of time.. especially seeing what LordHighGiffer does with
>GIF viewing. So possibly a program that only viewed JPEGs directly
>would be fast enough?
>
You can't view JPEG compressed pics directly, because they are just that,
in compressed format. What JPEG is used for is compressing 24 bit pics and the
like. I have seen some 4+ meg pics when done in 24 bit targa and the like! So,
JPEG was developed to help with the storage of these pics. Simplest way to sum
up JPEG would be to say that it is a user adjustable compression utility for
24 bit pictures. By that I mean that the better the compression, the more the
picture clarity loss. So, if you want to keep the clarity of the pic, you can
use only 10% compression if you choose. Or, if space is a factor, you can have
the program squish it down to as little as say 100K.
tuu
In article <ar4...@pro-calgary.cts.com> tre...@pro-calgary.cts.com (Trent Corney) writes:
>You can't view JPEG compressed pics directly, because they are just that,
>in compressed format.
I can certainly see why a JPEG -> GIF converter is useful, since there are
already GIF converters on basically every computer under the sun.
That still doesn't answer why someone doesn't write a direct JPEG
converter. (LordHighJPEGGer, anyone?)
--
/unk...@ucscb.ucsc.edu 1-900-DAVEFAN (hahahaha) Apple IIGS Forever!\
|WANT to get INFOCOM GAMES RERELEASED | Also will pass on -UNIX GS- info |
\& ULTIMA VI GS written? ---mail me | CHEAP CD info - mail me /
David Seah
>
>In article <ar4...@pro-calgary.cts.com> tre...@pro-calgary.cts.com (Trent Corney) writes:
>>You can't view JPEG compressed pics directly, because they are just that,
>>in compressed format.
> OF COURSE they are in compressed format. But so are GIF files.
>I can certainly see why a JPEG -> GIF converter is useful, since there are
>already GIF converters on basically every computer under the sun.
> That still doesn't answer why someone doesn't write a direct JPEG
>converter. (LordHighJPEGGer, anyone?)
It would be quite a challenge. Have you ever looked into what a JPEG
converter would entail? First, you need a fast Discrete Cosine Transform
package. Then, you need a lot of memory, as a JPEG file can contain tens of
thousands of colors. Then you need to write a color quantizer/ditherer to
kerplunk it into 256 colors suitable for GIF-a-fying. Alternatively, find
the best 16 colors (per scanline or otherwise) and jam it into a 320x200
sized box. Add a ZipGSX to sweeten the deal.
Certainly, it can be done -- since when is anything impossible? Personally,
I'm leary of anything that involves coding trig functions in assembly
language. There are a number of other discouraging factors, such as memory
requirements, speed of decompression, why-bother-if-you-have-only-64000-
pixels-anyway, and the all-important "What if it sucks after I've finished
writing it?"
You know, if you can just massage the JPEG into the Visionary GS RAW format,
there are a number of programs that are capable of converting it into 3200
pics (Allison and Prism come to mind). So, get the JPEG source, glomp on it
until it can spit out raw data, reduce it down to RAW format...it almost
sounds doable, doesn't it?
"Sure it's possible, if someone else does it",
--
Dave Seah ^..^ | University of Rochester, Dept. of Electrical Engineering |
graduate student | Apple II Art & Graphics Forum Consultant, America Online |
////// Internet: se...@ee.rochester.edu ////// America Online: AFC DaveS //////
Kevin S Green
until recently and might/must have missed an announcement.
--
Kevin S. Green / luc...@world.std.com / {xylogics;uunet}!world!lucifer
/America Online: Gargoth
Todd P. Whitesel
>Has Lord High Giffer come out yet. I've been semi-out of the loop
>until recently and might/must have missed an announcement.
No, you haven't missed an announcement. There hasn't been one.
LHG has been waiting for BinSCII II -- which has been waiting for my class load
to lighten up. I just got Orca/M 2.0, and it is almost midterms week -- this is
usually when I get more work done, because the homework grind is interrupted.
Seeing as how I have already joined the ranks of vaporware authors (aarrgghh),
I am not about to make any promises about when either BinSCII II or LHG will
be ready. I will reveal this much though: the "seed" LHG I've been mailing
out was merely a prototype. The _real_ LHG will have a desktop interface,
totally rewritten core routines and better configurability, and will FULLY
support the VOC. (hint hint)
Todd Whitesel
toddpw @ tybalt.caltech.edu
James L. Brookes
se...@ee.rochester.edu (David Seah) writes:
[stuff about writing JPEG convertor axed]
>You know, if you can just massage the JPEG into the Visionary GS RAW format,
>there are a number of programs that are capable of converting it into 3200
>pics (Allison and Prism come to mind). So, get the JPEG source, glomp on it
>until it can spit out raw data, reduce it down to RAW format...it almost
>sounds doable, doesn't it?
see why I should be limited to 16 colors when I port the pic to another
system. Also, there exist other convertors (some GIF=>256, 3200) which
do a better job (IMHO) than Allison 3200. Any chance someone can write a
raw => GIF? Is there any place I can get the spec on a RAW file? (as far
as I know it's three SHRs of Red, Green and Blue).
>"Sure it's possible, if someone else does it",
>Dave Seah ^..^ | University of Rochester, Dept. of Electrical Engineering |
>graduate student | Apple II Art & Graphics Forum Consultant, America Online
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
| James Brookes | Oggnet: House of Games, User #209 |
|``What, me worry?'' - A. E. Neuman | Usenet: bb...@cleveland.freenet.edu |
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
tuu
In article <1992Jan30.0...@cco.caltech.edu> tod...@cco.caltech.edu (Todd P. Whitesel) writes:
>LHG has been waiting for BinSCII II -- which has been waiting for my class load
Do you mean they have some interconnection, or that Binscii II is just
higher up on the importance scale?
>I will reveal this much though: the "seed" LHG I've been mailing
>out was merely a prototype. The _real_ LHG will have a desktop interface,
>totally rewritten core routines and better configurability, and will FULLY
>support the VOC. (hint hint)
Say it ain't so, Joe. Say it ain't so.
The seed LHG is just so darn easy to use and "invisible". (Hopefully
you'll write an LHG Finder Extension for 6.0? I.e. just double click on a
GIF, and it's decoded.. just as now with the seed, but it'd always be in
memory... Deatherage's IR loads in Finder Extensions, so I'd like to be able
to load it in "permanently" the times I use it)
Unless the core routines are _even faster_, I can see using the
"seed" over the "real" release.
James L. Brookes
>>Has Lord High Giffer come out yet. I've been semi-out of the loop
>>until recently and might/must have missed an announcement.
>No, you haven't missed an announcement. There hasn't been one.
>this is usually when I get more work done, because the homework grind is
>interrupted.
>Seeing as how I have already joined the ranks of vaporware authors (aarrgghh),
>I am not about to make any promises about when either BinSCII II or LHG will
>out was merely a prototype. The _real_ LHG will have a desktop interface,
>totally rewritten core routines and better configurability, and will FULLY
>support the VOC. (hint hint)
feature that would save up to as large an APF file as possible? (I don't
remember the max size of an APF right now). Hopefully DG will soon
have the capability to load in large-as-memory-allows pics soon :-)
Speaking of which, is there any chance we could get DG supporting the VOC?
That would be _very_ cool. The VOC is way too neat a card to suffer the
lack of software support it does...
Todd P. Whitesel
>Ooohhhh...VOC support would be truely awesome. How about a "Save as APF"
>feature that would save up to as large an APF file as possible? (I don't
Eventually I plan to add that. One of the basic goals of LHG is to remove the
size restrictions imposed by other people's brain dead software.
As for DG, you'll have to ask them about it...
Todd P. Whitesel
>Do you mean they have some interconnection, or that Binscii II is just
>higher up on the importance scale?
sort of. B2 was originally supposed to be finished by October (!!) but my
classwork got in the way. B2 is also much closer to being finished, whereas
LHG still needs plenty of new code. I try to focus my work in order to keep
from getting mixed up, and this sometimes has the bad side effect of slowing
me down overall. I think it makes up for that because it lets me do much
higher quality code since I am able to keep all the details straight.
> The seed LHG is just so darn easy to use and "invisible". (Hopefully
>you'll write an LHG Finder Extension for 6.0? I.e. just double click on a
[...]
> Unless the core routines are _even faster_, I can see using the
>"seed" over the "real" release.
You silly person. The desktop interface will only come up if you launch LHG
directly. It will still support finder icon operation the way it does now,
and will even let you play with the conversion in a more reasonable fashion
than the "click for gray scale" approach I hacked into the seed version.
Depending on how the tool starting issues work out, it will probably also
let you drop out of the slide show and into the desktop interface, with the
current picture still loaded.
BTW all picture viewing will still be full-screen with realtime scrolling.
I am not quite ready to tackle graphics windows yet. The main reason for
having the desktop interface is to provide SFMultiGet boxes and to allow
windows with conversion controls and a menu bar.
Jawaid Bazyar
>Seeing as how I have already joined the ranks of vaporware authors (aarrgghh),
>I am not about to make any promises about when either BinSCII II or LHG will
>be ready. I will reveal this much though: the "seed" LHG I've been mailing
>out was merely a prototype. The _real_ LHG will have a desktop interface,
>totally rewritten core routines and better configurability, and will FULLY
>support the VOC. (hint hint)
Desktop interface? I sure hope you allow a full range of command-
line options so I can zip-quick view gifs from GNO... i.e., don't make
me mess with menus and stuff. It sure it nice to be able to 'gif *'
and have at it.
--
Jawaid Bazyar | Ask me about the GNO Multitasking Environment
Procyon, Inc. | for the Apple IIgs! (314) 334-7078
baz...@cs.uiuc.edu | 1005 N. Kingshighway, Suite 309
--Apple II Forever!-- | Cape Girardeau, MO 63701
Todd P. Whitesel
> Desktop interface? I sure hope you allow a full range of command-
>line options so I can zip-quick view gifs from GNO... i.e., don't make
>me mess with menus and stuff. It sure it nice to be able to 'gif *'
>and have at it.
The current "seed" version can already do that. It just doesn't have any
command line options. Those are easy to add of course -- one of the things
that still needs to be done to BinSCII II is I need to rewrite the options
parser code for the last time. LHG uses a custom .ROOT I developed that
looks for a finder message if argc == 0 (which Mike's C_STARTUP code passes
if there is no shell string). The finder message is then parsed and a dummy
argc/argv is created and passed to main. I'm really glad I thought of it.
I can already type 'lordhighgiffer lum.gif kei.gif eve4.gif cdp1.gif' from
Orca and it works great. However it does not like PROSEL because PROSEL
fires up QuickDraw and GrafOff's it before running EXE's. I need to add
code to check for extraordinary tool conditions (some guy from Zip named
Dave gave me a lot of grief about it not running from ProSEL).
Todd Whitesel
toddpw @ tybalt.caltech.edu
P.S. The decompression _is_ going to get a bit faster, and the color
cruncher will get smarter, and possibly much faster also. GAWD I wish
there were 8 days in a week.
Trent Corney
> OF COURSE they are in compressed format. But so are GIF files.
>I can certainly see why a JPEG -> GIF converter is useful, since there are
>already GIF converters on basically every computer under the sun.
> That still doesn't answer why someone doesn't write a direct JPEG
>converter. (LordHighJPEGGer, anyone?)
Yes, GIF files are compressed as well, but the 2 use very different
compression methods. Not to mention that the JPEG method is much more
complex. I believe someone posted a brief way on what exactly JPEG does to
a picture. To state it again, JPEG is a compression format for 24 bit
pictures. It allows the user to select the amount of compression based upon
the amount of clarity loss that is acceptable. Hence, the more compression,
the smaller the file, BUT you will lose picture quality.
I don't see your point about the time involved to make the picture. Even
displaying GIF pictures there is a wait involved. Have you ever seen
SuperConvert 3.0? Some GIF pics take a while to convert.
Maybe this will help you understand the concept better. You know that
ShrinkIt is used to archive files/disks, right? Why can't you run the .SHK
or .BXY version of the program in the archive then? Same thing with the
JPEG. JPEG is not a picture type in sense, but a compression method.
tuu
In article <au4...@pro-calgary.cts.com> tre...@pro-calgary.cts.com (Trent Corney) writes:
>I don't see your point about the time involved to make the picture. Even
>displaying GIF pictures there is a wait involved. Have you ever seen
>SuperConvert 3.0? Some GIF pics take a while to convert.
AAAAH.. jpeg2gif would take a long time on the GS.. I surmise this
because all of the GIF makers I've seen have been really slow. There is an
added step there that is not necessary.. i.e. jpeg -> gif -> screen. Going
from jpeg -> screen would be a lot faster.
Have you seen LordHighGiffer? It's fast.
>Maybe this will help you understand the concept better. You know that
>ShrinkIt is used to archive files/disks, right? Why can't you run the .SHK
>or .BXY version of the program in the archive then? Same thing with the
>JPEG. JPEG is not a picture type in sense, but a compression method.
God, I understand all of this. You don't understand that GIF and JPEG
are conceptually very very similar: ways of encoding pictures in a machine
independent form.
You wouldn't get confused if I talked about a "GIF viewer" because
you've seen them already. You're getting confused about a "JPEG viewer" because
you've never seen one (at least on a II).
I'm not saying it wouldn't be slow.. I don't KNOW whether it would
be slow. People said GIF conversion would be putt-putt slow, then came
LHG (seed version at least), which proved it amazingly wrong.
--
/unk...@ucscb.ucsc.edu Apple IIGS Forever!\
|WANT to get INFOCOM GAMES RERELEASED | Also will pass on -UNIX GS- |
\& ULTIMA VI GS written? ---mail me | & CHEAP CD info - mail me /
Bob Lindabury, SysAdm
> > Why convert it to GIF format anyway? Why not just have a viewer of
> >JPEG files?
> >
> You can't view JPEG compressed pics directly, because they are just that,
> in compressed format. What JPEG is used for is compressing 24 bit pics and th
> like. I have seen some 4+ meg pics when done in 24 bit targa and the like! So
> JPEG was developed to help with the storage of these pics. Simplest way to su
> up JPEG would be to say that it is a user adjustable compression utility for
> 24 bit pictures. By that I mean that the better the compression, the more the
> picture clarity loss. So, if you want to keep the clarity of the pic, you can
> use only 10% compression if you choose. Or, if space is a factor, you can hav
> the program squish it down to as little as say 100K.
Yes, but converting the images to GIF is next to useless on the GS.
In fact, there aren't too many ways to really view a deep-color image
on the GS in it's true glory. I would have to say the closest you
can come to reasonably viewing such images would be the 3200 color
mode. Might just as well convert them to that rather than 256 GIF
images. Maybe both 3200 and GIF should be supported. 16 color just
isn't going to hack it.
-- Bob
The Graphics BBS 908/469-0049 "It's better than a sharp stick in the eye!"
============================================================================
InterNet: bo...@graphics.rent.com | Raven Enterprises
UUCP: ...rutgers!bobsbox!graphics!bobl | 25 Raven Avenue
BitNet: bobl%graphics.rent.com@pucc | Piscataway, NJ 08854
Home #: 908/560-7353 | 908/271-8878
James L. Brookes
<massive smiley>
>Todd Whitesel
>toddpw @ tybalt.caltech.edu
>P.S. The decompression _is_ going to get a bit faster, and the color
>cruncher will get smarter, and possibly much faster also. GAWD I wish
>there were 8 days in a week.
Rocky J Giovinazzo
>In article <au4...@pro-calgary.cts.com> tre...@pro-calgary.cts.com (Trent Corney) writes:
>>I don't see your point about the time involved to make the picture. Even
>>displaying GIF pictures there is a wait involved. Have you ever seen
>>SuperConvert 3.0? Some GIF pics take a while to convert.
> AAAAH.. jpeg2gif would take a long time on the GS.. I surmise this
>because all of the GIF makers I've seen have been really slow. There is an
>added step there that is not necessary.. i.e. jpeg -> gif -> screen. Going
>from jpeg -> screen would be a lot faster.
Jpeg2gif might take a while on a GS, but not on the back-end
(making the gif). GifSave, unlike the infamous SHRConvert, takes
a few seconds to a minute to create a gif file (as opposed to 5-10 or more
minutes with SHR convert). The time consuming part would be in fact
on the jpeg-> screen end IMHO.
Rocky Giovinazzo
Todd P. Whitesel
>Hm, 'lum' 'kei' 'eve'? What are they?
Just some of my test pictures... nothing special :)
>>P.S. The decompression _is_ going to get a bit faster, and the color
>Faster??? Not that I have any objections, or anything :-)
YupPERS! There's a story to this one, and I feel like flicking a bit more,
so here 'tis.
When I was at Microsoft interviewing for last summer's job, one of the
interviewers had me describe the "giffer" in as much technical detail
as possible in 40 minutes (!!). Now since I had recently finished the
bulk of the program, I had put it on my resume as a project and this guy
had seen it.
When I got to the bit-unpacking section, I mentioned that there was another
algorithm I was looking into, which was a bit tricker to write but would be
faster and easier to interface to. The microsoft guy made a comment to the
effect of "what would it take to convince you that it's actually faster" and
from his tone of voice I got the distinct feeling that he really thought it
would be, as if he'd worked on something like this before.
I answered that I'd have to actually try writing some code and working out
the timing, and then actually put the change in and see what the difference
was. Anyway, before I left that day I had gotten a job offer from this guy's
manager (who was my last, and previously unscheduled, interview).
While I was at microsoft over the summer working for this guy's group, I
did some more scratch work on the un-bitpacking algorithm. According to
my cycle count, it should easily beat the old method; however the actual
speed gain is uncertain, since I don't really know how much of the total
time is being spent doing that. Some simple estimates I did gave me a figure
of about 10%, so it is definitely worth doing. It also allows me to handle
the memory allocation any way I want, and is the key to making LHG's memory
requirements reasonable when you are loading large pictures, so I am going to
do it even if the speedup is unnoticeable.
James L. Brookes
GNO with maybe 1.5 meg free) I wasn't able to open an 800k Gif. I guess
seed lhg requires the original Gif and the expanded bitmap to be in memory
at once...(I seem to remember something about that).BTW, did you ever get my mail? I tried the address above but got no
response...surely you aren't too busy to answer your mail? :-)
Shawn W Platkus
Hey Todd,
What about Lord Low Giffer that was going to be the stripped down pre-release
version of LHG? Heck from what it sounds like, it would be a lot better than
what's out now even without an interface.
--
_______ __ _____ ________ __ _ __ __ ______
\\// _ // || // || | || | || // || || // @ecn.purdue.edu
//____// ||_ //===||_ ||_ ||<< ||_ ||_ /=====/
_//_ _||/__/ _// _||/ _||/_ _|| \\_ _||/___||/ _____//
Rocky J Giovinazzo
>In article <au4...@pro-calgary.cts.com> tre...@pro-calgary.cts.com (Trent Corney) writes:
>>I don't see your point about the time involved to make the picture. Even
>>displaying GIF pictures there is a wait involved. Have you ever seen
>>SuperConvert 3.0? Some GIF pics take a while to convert.
> AAAAH.. jpeg2gif would take a long time on the GS.. I surmise this
>because all of the GIF makers I've seen have been really slow. There is an
>added step there that is not necessary.. i.e. jpeg -> gif -> screen. Going
>from jpeg -> screen would be a lot faster.
Trent Corney
bo...@graphics.rent.com (Bob Lindabury, SysAdm) writes:
>Yes, but converting the images to GIF is next to useless on the GS.
>In fact, there aren't too many ways to really view a deep-color image
>on the GS in it's true glory. I would have to say the closest you
>can come to reasonably viewing such images would be the 3200 color
>mode. Might just as well convert them to that rather than 256 GIF
>images. Maybe both 3200 and GIF should be supported. 16 color just
>isn't going to hack it.
But, JPEG doesn't support 3200 pics. 3200 pics are a GS specific thing and
JPEG is a computer independant format, just like GIF is.
Trent Corney
> AAAAH.. jpeg2gif would take a long time on the GS.. I surmise this
>because all of the GIF makers I've seen have been really slow. There is an
>added step there that is not necessary.. i.e. jpeg -> gif -> screen. Going
>from jpeg -> screen would be a lot faster.
Yes, going from JPEG to the screen directly would be faster. It would have
to be seeing as you are not doing one step. But, the machines requirements
would kill you! I have seen some 8+ MB 24 bit pictures, so you would need
more than that amount of RAM to undo the JPEG pic to the screen. Let's see,
8 megs for the pic, more RAM for the op. sys., and still more RAM to
actually run the program in. So, we are talking in the 10+ meg level. I
Also, you would have to have a very fast math co-processor seeing as the
JPEG compression deals with cosign mathmatical functions. Even on a 486
processor JPEG seems "slow" (and that chip has the math co-processor built
in.)
> Have you seen LordHighGiffer? It's fast.
Nope, only seen reference to it on here from you and a few others.
> God, I understand all of this. You don't understand that GIF and JPEG
>are conceptually very very similar: ways of encoding pictures in a machine
>independent form.
> You wouldn't get confused if I talked about a "GIF viewer" because
>you've seen them already. You're getting confused about a "JPEG viewer" because
>you've never seen one (at least on a II).
> I'm not saying it wouldn't be slow.. I don't KNOW whether it would
>be slow. People said GIF conversion would be putt-putt slow, then came
>LHG (seed version at least), which proved it amazingly wrong.
I don't think that GIF and JPEG are that similar. For one, JPEG deals with
the picture by breaking it up into grids. Doesn't GIF read and compress the
pictures line by line? Two very different methods. And, depending on the
user settings with JPEG, you could have anywhere from say 12 grids, all the
way up to who knows how many. I just don't see a "JPEG viewer" on the
horizon.
Todd P. Whitesel
>Ahhh...that's good. With 2.25 meg (all DAs INITs and CDEVs inactive, from
>GNO with maybe 1.5 meg free) I wasn't able to open an 800k Gif. I guess
>seed lhg requires the original Gif and the expanded bitmap to be in memory
>at once...(I seem to remember something about that).
You got it. I warned you about that at AnimeCon.
>BTW, did you ever get my mail? I tried the address above but got no
>response...surely you aren't too busy to answer your mail? :-)
More like I'm avoiding it. Mail I can't whip off an answer to right away
tends to sit in my mailbox, until some evening when I really feel like
flicking and I just go through and clean out the whole thing.
Dave Huang
> AAAAH.. jpeg2gif would take a long time on the GS.. I surmise this
>because all of the GIF makers I've seen have been really slow. There is an
>added step there that is not necessary.. i.e. jpeg -> gif -> screen. Going
>from jpeg -> screen would be a lot faster.
Plus, the pictures you get out of a jpeg -> gif -> screen conversion
probably aren't gonna be as good as a jpeg -> screen conversion, since
you're quantizing down to 256 colors for the GIF conversion, and then
down to 16 for displaying it on the screen. Also, JPEG -> 3200 color pics
generally look better than GIF -> 3200 color pics (I've been messing around
with JPEG -> 3200 on the local Unix box... mainly a small shell script
to run individual scanlines through 'ppmquant' to make sure they don't have
more than 16 colors, then writing them out into a 3200 color pic format).
> Have you seen LordHighGiffer? It's fast.
Yes... very :-)
>/unk...@ucscb.ucsc.edu Apple IIGS
Forever!\
--
David Huang |
Internet: da...@ccwf.cc.utexas.edu | "Microwaves: They're not just
UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | for cooking anymore."
America Online: DrWho29 |
Todd P. Whitesel
>What about Lord Low Giffer that was going to be the stripped down pre-release
>version of LHG? Heck from what it sounds like, it would be a lot better than
>what's out now even without an interface.
Weeelll... Over the summer it also dawned on me (as I tried to work out the
actual mechanics of the "memory management scheme of the gods") that LLG was
really LHG 0.5 -- so there wasn't any point in scrabbling together a piece of
crap program called LLG when I should instead get the basic LHG working and
then make frequent small updates to it.
In other words, LHG changed and got more modest, to the point where LLG had
no place in more project lineup. LLG ended up waiting for Binscii II anyway,
and that still isn't finished (lack of time, not lack of ideas). argh.
Rocky J Giovinazzo
>In <8ZcFFB...@graphics.rent.com>
>bo...@graphics.rent.com (Bob Lindabury, SysAdm) writes:
>>Yes, but converting the images to GIF is next to useless on the GS.
>>In fact, there aren't too many ways to really view a deep-color image
>>on the GS in it's true glory. I would have to say the closest you
>>can come to reasonably viewing such images would be the 3200 color
>>mode. Might just as well convert them to that rather than 256 GIF
>>images. Maybe both 3200 and GIF should be supported. 16 color just
>>isn't going to hack it.
>But, JPEG doesn't support 3200 pics. 3200 pics are a GS specific thing and
>JPEG is a computer independant format, just like GIF is.
It seems to me that the point was that jpeg's should be viewed on the GS in
3200 color mode -- not whether 3200 color pictures can be stored in jpeg format.
Rocky Giovinazzo
Scott Gentry
>
>Actually, I'd really like to see a Visionary RAW => GIF convertor. I don't
>see why I should be limited to 16 colors when I port the pic to another
>system.
There is no such thing as Visionary RAW. The format is titled Allison raw
image document. An Allison raw image document is comprised of three planes,
each 32000 bytes. In order, the planes are Red, Green, and Blue. Each
32000 byte plane represents a pixel map of its component color.
>Also, there exist other convertors (some GIF=>256, 3200) which
>do a better job (IMHO) than Allison 3200. Any chance someone can write a
>raw => GIF?
There is a good chance. :-) What'cha gonna display it on? Gonna process it
with PRISM?
IMHO, there's a better chance Allison will get better
200 palette processing and 16 palette processing. But then, what do I know?
I'm only the author. Unfortunately, I'm probably going to block processing
of raw images on systems without a "Visionary", "Enhanced Vision Plus", or
AST Vision Plus installed. Why?
BTW, if RWP ever releases TGE library disk number 2, the hot setup for your
GIF processing dreams is to save a GIF to Allison format, then process it
with Allison. Yields some pretty nice pictures. On a commercial network
system, I've uploaded several processed in this manner.
Is there any place I can get the spec on a RAW file? (as far
>as I know it's three SHRs of Red, Green and Blue).
See above.
--
*******************************************************************************
* W. Scott Gentry | uucp: uunet!ingr!ne1300!brnded!scott | I didn't *
* Intergraph Corporation| America Online: AFL Scott | mean it! *
*******************************************************************************
Bob Lindabury, SysAdmin
Yes, the point actually was that there are going to be a *ton* of 24-bit
JPEG images all over the place soon and that people should be working on
a way to read JPEG and convert them to 3200 or 3201 formats for viewing
on the GS rather than the very limiting (256 color) GIF format.
-- Bob
InterNet: bo...@bobsbox.rent.com | Raven Enterprises
UUCP: ...rutgers!bobsbox!bobl | 25 Raven Avenue
BitNet: bobl%bobsbox.rent.com@pucc | Piscataway, NJ 08854
Home #: 908/560-7353 | 908/271-8878
Dave Huang
>have to be seeing as you are not doing one step. But, the machines
>requirements would kill you! I have seen some 8+ MB 24 bit pictures,
>so you would need more than that amount of RAM to undo the JPEG pic to
>the screen. Let's see, 8 megs for the pic, more RAM for the op. sys.,
>and still more RAM to actually run the program in. So, we are talking
>in the 10+ meg level.
Well, I'm not entirely sure about the JFIF/JPEG format, but I am
pretty sure that you don't need to keep the whole uncompressed picture
in RAM all at once. I've done a few tests on the Sun Sparcstations
here, and a JPEG that unpacks to about 1 MB uses approximately 800K of
RAM at once. It should be possible to uncompress a few scanlines at a
time, quantize them down so they take less RAM, uncompress a few more,
etc..
> I Also, you would have to have a very fast math
>co-processor seeing as the JPEG compression deals with cosign
>mathmatical functions. Even on a 486 processor JPEG seems "slow" (and
>that chip has the math co-processor built in.)
Yeah, this will probably be the main problem with a JPEG
converter/viewer on a II... the discrete cosine transforms that it
uses chomp a lot of CPU time.
>I don't think that GIF and JPEG are that similar. For one, JPEG deals
>with the picture by breaking it up into grids. Doesn't GIF read and
>compress the pictures line by line? Two very different methods. And,
>depending on the user settings with JPEG, you could have anywhere from
>say 12 grids, all the way up to who knows how many. I just don't see a
>"JPEG viewer" on the horizon.
I was pretty sure that JPEG broke the picture into 8x8 grids, and
the quality setting just determined how much of the transformed image
data to keep... It's definitely possible though, since JPEG viewers
are available for other platforms. Other than the lack of CPU power, I
don't see why one couldn't be written for the GS...
>--------------------------------------------------------------------------
>ProLine: trentc@pro-calgary GEnie: T.Corney
>Internet: tre...@pro-calgary.cts.com CIS: 70561,50
>UUCP: crash!pro-calgary!trentc
>--------------------------------------------------------------------------
Todd P. Whitesel
> Yeah, this will probably be the main problem with a JPEG
>converter/viewer on a II... the discrete cosine transforms that it
>uses chomp a lot of CPU time.
It's not as bad as you think. The angles are fixed, so you can precompute a
table of cosine values. It is the multiply-accumulate operations that take
all the time, even on fast systems. Chips that are pipelined for heavy-duty
floating point performance can be programmed to do the 8x8 transforms a lot
faster than your conventional floating point coprocessor will. No one in their
right mind is going to write a JPEG converter that does actual cosines on the
fly.
Does anyone know what kind of precision is involved? If we burn some memory,
we can probably table-ize the multiplies, at least partially.
James L. Brookes
From: sc...@ne3005.ingr.com (Scott Gentry)
>bb...@cleveland.Freenet.Edu (James L. Brookes) writes:
>>Also, there exist other convertors (some GIF=>256, 3200) which
>>do a better job (IMHO) than Allison 3200. Any chance someone can write a
>>raw => GIF?
>There is a good chance. :-) What'cha gonna display it on? Gonna process it
>with PRISM?
support - like our Mac IIx upstairs, or my friends 386. Also, there are
other conversion utilities besides Prism.
>IMHO, there's a better chance Allison will get better
>200 palette processing and 16 palette processing. But then, what do I know?
>I'm only the author. Unfortunately, I'm probably going to block processing
>of raw images on systems without a "Visionary", "Enhanced Vision Plus", or
>AST Vision Plus installed. Why?
for the Visionary only/AST only. Although, you might want to consider
releasing a stand-alone for converting GIFs to 16 color...just a thought.
>BTW, if RWP ever releases TGE library disk number 2, the hot setup for your
>GIF processing dreams is to save a GIF to Allison format, then process it
>with Allison. Yields some pretty nice pictures. On a commercial network
>system, I've uploaded several processed in this manner.
for almost a year now...(and I've heard of Prism for longer! :-).
>>Is there any place I can get the spec on a RAW file? (as far
>>as I know it's three SHRs of Red, Green and Blue).
>See above.
for me :-). And, coupled with pbmtogif, it does the gif conversion pretty
nicely. Although, it would be nice to get pbmtogif on my GS so I don't
have to ul/dl all of the pics at 2400 bps (espically laborious when you
have 96k files to deal with...)
>--
>******************************************************************************
>* W. Scott Gentry | uucp: uunet!ingr!ne1300!brnded!scott | I didn't *
>******************************************************************************