zane@ddsw1.MCS.COM (Sameer Parekh) (02/17/91)
Which is the best GIF viewer for a //gs? Does the new SHRConvert handle 640 pics without cutting off the edge? (Mine cuts off the right half.) Thanks. -- zane@ddsw1.MCS.COM
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (02/17/91)
zane@ddsw1.MCS.COM (Sameer Parekh) writes: > Which is the best GIF viewer for a //gs? Right now it is GIF3200 by Jonah Stich, available from finer FTP sites. Todd Whitesel toddpw @ tybalt.caltech.edu
unknown@ucscb.UCSC.EDU (The Unknown User) (02/17/91)
In article <1991Feb16.233633.19276@ddsw1.MCS.COM> zane@ddsw1.MCS.COM (Sameer Parekh) writes: > Which is the best GIF viewer for a //gs? Does the new >SHRConvert handle 640 pics without cutting off the edge? (Mine cuts >off the right half.) The new SHRConvert will NOT handle GIFs.. I believe that's because Jason Harper's scared that CompuServe will sue for some royalty payments or something.. (Not that I'm saying he's being ridiculous or anything).. That's since CompuServe invented the standard and I believe has patents/copyrights/whatever on part of it.. Right now the best one is by Jonah Stitch.. (GIF3200).. Unfortunately it's kinda annoying currently to view a big GIF as you have to give it offsets beforehand.. A new version (coming out I do not know when) will be better... There's also a faster GIFfer to come out hopefully soon.. By Todd Whitesell I think... "Lord High Giffer" -- /Apple II(GS) Forever! unknown@ucscb.ucsc.edu MAIL ME FOR INFO ABOUT CHEAP CDs\ \WRITE TO ORIGIN ABOUT ULTIMA VI //e and IIGS! Mail me for addresses, & info. /
daveh@ccwf.cc.utexas.edu (David H. Huang) (02/18/91)
In article <1991Feb16.233633.19276@ddsw1.MCS.COM> zane@ddsw1.MCS.COM (Sameer Parekh) writes: > > Which is the best GIF viewer for a //gs? Does the new >SHRConvert handle 640 pics without cutting off the edge? (Mine cuts >off the right half.) The new SHRConvert (SuperConvert) doesn't have a GIF option, due to some kind of legal thing about the LZW algorithms, I think. SHRConvert cuts off the edge of the picture because it has a limit of 64K/picture. Currently, the only decent GIF viewer for the GS is Jonah Stitch's GIF3200. It's relatively fast, supports 3200 colors, and you can view any size picture, although there is no scrolling yet, you have to pick which 320x200 section of the picture you want to view beforehand. Also, Todd Whitesel is working on a GIF viewer, and it sounds better than GIF3200. Todd can definitely provide more info about it than I can, since I've never seen the program before... -- David Huang | Internet: daveh@ccwf.cc.utexas.edu | "Slight accidents with funny rays UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | can have serious consequences" America Online: DrWho29 |
scott@brnded.ne1300.ingr.com (Scott Gentry) (02/22/91)
daveh@ccwf.cc.utexas.edu (David H. Huang) writes: >In article <1991Feb16.233633.19276@ddsw1.MCS.COM> zane@ddsw1.MCS.COM (Sameer Parekh) writes: >> >> Which is the best GIF viewer for a //gs? Does the new >>SHRConvert handle 640 pics without cutting off the edge? (Mine cuts >>off the right half.) >The new SHRConvert (SuperConvert) doesn't have a GIF option, due to >some kind of legal thing about the LZW algorithms, I think. SHRConvert >cuts off the edge of the picture because it has a limit of >64K/picture. > According to posts on America Online in the Seven Hills Software Direct Connect area, SuperConvert is indeed going to support GIF format pictures. It was mentioned that Seven Hills has secured permission to use LZW without too much trouble. The reporter of this information was Dave Hecker of Seven Hills. It is unknown if uncompressed pixelmaps larger than 64k will be supported via a scrolling, resize, or full res. option. It is also unknown if Jason will increase the speed of decompression/compression. What is known, however, is that Jason has done alot of homework while working on SuperConvert. It's a very useful program (however, I've only got a beta from Seven Hills so I could make sure I could ask questions about it during an online conference, and I'm unclear about final features except those mentioned here). I'm very impressed with the quality of pictures generated under SuperConvert. When it's released, I think it will be a very hot thing to have. Hope this clears up misconceptions about the product. -- ******************************************************************************* * W. Scott Gentry | uucp: uunet!ingr!ne1300!brnded!scott | I didn't * * Intergraph Corporation| America Online: AFL Scott | mean it! * *******************************************************************************
zane@ddsw1.MCS.COM (Sameer Parekh) (02/24/91)
Thanks for the info about the GIF viewers. . .could someone post Jonah Stitch's GIF3200? I don't have FTP access. . .(Or mail it to me.) Thanks again. -- zane@ddsw1.MCS.COM
isbell@athena.mit.edu (Charles L Isbell) (02/25/91)
zane@ddsw1.MCS.COM (Sameer Parekh) writes: > Thanks for the info about the GIF viewers. . .could someone >post Jonah Stitch's GIF3200? I don't have FTP access. . .(Or mail it to me.) >Thanks again. Speaking of GIF3200, sometimes, after I view a picture and click to dismiss it, my machine crashes. Here's what usually happens: the picture clears, a Standard File Dialog outline is drawn, the text box for the name of the file appears in the lower left hand corner, my 3.5" is accessed, then BEEP, I'm in the monitor. This happens regularly but randomly. Is this a known bug or is it just me? Peace. Charles Isbell -- "I'm the man you think you are.... If you want | "Don't just adopt opinions, to know what I'll do, figure out what you'll do. | develop them." I'll do the same thing--only more of it." | -- Charles Isbell, -- Malcolm X | AXIOM
taob@pnet91.cts.com (Brian Tao) (02/26/91)
From daveh@ccwf.cc.utexas.edu (David H. Huang): > SHRConvert cuts off the edge of the picture because it has a limit > of 64K/picture. Currently, the only decent GIF viewer for the GS ... ^^^^^^^^^^^ You mean no one has done anything about that stupid restriction? What's the technical reason behind that anyway? Does it have something to do with QuickDraw II, or the APF graphic file format? I would love to view those 800x600x16 GIF's without having to chop it up. Brian T. Tao *B-) | t569taob@bluffs.scar.utoronto.ca | "Though this be U of Metro Toronto | - or - | madness, yet there Scarberia, ON | taob@pnet91.cts.com | is method in 't."
kolesar@plains.NoDak.edu (Joe Kolesar) (02/26/91)
So is Jonah gonna add a scroll option to GIF3200, even if it's just for grey scaled pics? That would be a nice option to see. -- Jeff Kolesar kolesar@plains.nodak.edu "Choosy mothers choose GIF" Cleared by Iraqi Censors "No matter where you are, there you go" Disclaimer: Do you actually think I wrote this? Send flames to /dev/null
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (02/26/91)
aarrghhhh... you guys are going to drool over LHG... I hate it but I have to get my real world stuff in order for a week and then I can get the demo release finished and out. Todd Whitesel toddpw @ tybalt.caltech.edu
daveh@ccwf.cc.utexas.edu (David H. Huang) (02/27/91)
In article <538@generic.UUCP> taob@pnet91.cts.com (Brian Tao) writes: >From daveh@ccwf.cc.utexas.edu (David H. Huang): > >> SHRConvert cuts off the edge of the picture because it has a limit >> of 64K/picture. Currently, the only decent GIF viewer for the GS ... > ^^^^^^^^^^^ > > You mean no one has done anything about that stupid restriction? What's >the technical reason behind that anyway? Does it have something to do with >QuickDraw II, or the APF graphic file format? I would love to view those >800x600x16 GIF's without having to chop it up. QuickDraw II is supposed to handle "pictures" (I forgot the exact term for it) up to 32768x32768. APF doesn't put a limit on the picture size either. I think the reason for the 64K limit is that it's hard to manipulate data that crosses a bank boundary, especially in C. (According to the built in help for SHRConvert 2.1, it was writtin mostly in C with some assembly). >Brian T. Tao *B-) | t569taob@bluffs.scar.utoronto.ca | "Though this be >U of Metro Toronto | - or - | madness, yet there >Scarberia, ON | taob@pnet91.cts.com | is method in 't." -- David Huang | Internet: daveh@ccwf.cc.utexas.edu | "Slight accidents with funny rays UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | can have serious consequences" America Online: DrWho29 |
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (02/27/91)
daveh@ccwf.cc.utexas.edu (David H. Huang) writes: >QuickDraw II is supposed to handle "pictures" (I forgot the exact term >for it) up to 32768x32768. I think the term you want is a mutation of 'pixel image'. QD II's conceptual drawing space is -16K to +16K in both X and Y, for a maximum image of 32768 pixels in each direction. Mac Quickdraw goes out to +/- 32K for a maximum image of 65536 pixels in each direction -- this requires slightly more complex math, and 16K pixels is a hell of a lot already, so QD II enforces a 16K limit and is allowed to neglect some extra overhead as a result. Unfortuneately, there's still some pretty beastly overhead in the rest of the system (region processing). >I think the reason for the 64K limit is that it's hard to >manipulate data that crosses a bank boundary, especially in C. That's totally incorrect. Orca/C may have a couple of bugs when it comes to address calculation but that does not prevent you from working with rather large arrays. If the _commercial_ version of SHRConvert does not go past 64K then I can't possibly respect Jason Harper as a programmer. From day 1, the Lord High GIFfer has been chomping on an 800x600x256color picture as one of it's test cases. Todd Whitesel toddpw @ tybalt.caltech.edu
daveh@ccwf.cc.utexas.edu (David H. Huang) (02/27/91)
In article <1991Feb26.230754.8996@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >daveh@ccwf.cc.utexas.edu (David H. Huang) writes: >>I think the reason for the 64K limit is that it's hard to >>manipulate data that crosses a bank boundary, especially in C. > >That's totally incorrect. Orca/C may have a couple of bugs when it comes to >address calculation but that does not prevent you from working with rather >large arrays. OK... I've never used Orca/C before, so I was just guessing. I've heard stories about problems with arrays>64K, so that's what I wrote... >If the _commercial_ version of SHRConvert does not go past 64K then I can't >possibly respect Jason Harper as a programmer. From day 1, the Lord High >GIFfer has been chomping on an 800x600x256color picture as one of it's test >cases. Great! I hope you can scroll the picture, since selecting which part to view beforehand (like GIF3200 v0.2) is really a pain! >Todd Whitesel >toddpw @ tybalt.caltech.edu -- David Huang | Internet: daveh@ccwf.cc.utexas.edu | "Slight accidents with funny rays UUCP: ...!ut-emx!ccwf.cc.utexas.edu!daveh | can have serious consequences" America Online: DrWho29 |