On 2 Jul 1996 07:46:11 GMT, in alt.answers Jim Howard wrote: >Archive-name: pictures-faq/part2 >Last-modified: 05 March 1993 > > This is part 2 of the FAQ for the alt.binaries.pictures* hierarchy. > This part of the alt.binaries.pictures FAQ contains "general", or > operating-system independent information. It answers (hopefully) all > the questions you may have about the pictures newsgroups, decoding and > encoding techniques, and picture formats. > > For information on issues of etiquette and posting policy and/or > suggestions, consult part 1 of this posting. > > For information on your particular system and on specific utilities, > consult part 3 of this posting. > > Before posting to these groups for the first time, please check the FAQ > list (this posting - including parts 2 and 3), and also read the newsgroup > news.announce.newusers, which contains many answers to questions about > UseNet in general. > > If you've read previous versions of this FAQ, you'll probably only want > to read anything that has changed since the last distribution. These > changes appear both in this document and in the accompanying "Changes to > the alt.binaries.pictures FAQ". Note that this is a "live" document, and > is always getting important information added or updated. > > >*********************************************************************** > >This file is intended to be a general introduction to the pictures >newsgroups, answering some common questions concerning pictures posted >in those newsgroups, namely how to decode and view them. It is not, of >course, possible to cover everything, but I will try to to get as much >as I can into this file. If you feel something important has been >omitted and you know the subject well, please write me so I can >include the info for future releases. E-mail should be sent to >deej@cadence.com for these purposes. > >Before you miss an important detail contained in this file, let me >"pre-repeat" that many of the programs mentioned in this document are >available for anonymous ftp at bongo.cc.utexas.edu (128.83.186.13), in >the gifstuff directory. Also: there are NO GIF files of any kind at >this site! Save your time and don't bother looking for them! > >OK... on to the real reason you're reading this document... > > >TABLE OF CONTENTS > I. ABOUT THIS FAQ > II. DOWNLOADING AND DECODING FILES > III. COMMON PICTURE TYPES > IV. ENCODING AND UPLOADING FILES > V. ALTERNATE SOURCES FOR PICTURES/HOW-TO'S OF FTP > VI. COMMON PROBLEMS > VII. COPYRIGHT > > >I. ABOUT THIS FAQ > >This FAQ is posted every other Monday to the alt.binaries.pictures >newsgroups and to news.answers. It is also available by anonymous FTP, >from UUCP, or through e-mail by using the services available from a couple >of mail servers. For anonymous FTP access, you can look on either >pit-manager.mit.edu [18.72.1.58] in /pub/usenet/news.answers/pictures-faq >in files "part1.Z", "part2.Z", or "part3.Z", on ftp.cs.ruu.nl >[131.211.80.17] in /pub/NEWS.ANSWERS/pictures-faq for "part1", "part2", or >"part3", on ftp.uu.net [137.39.1.2, 137.39.1.9, or 192.48.96.2] in >/usenet/news.answers/pictures-faq as the files "part1.Z", "part2.Z", or >"part3.Z". >You can get the FAQ via UUCP by retrieving the appropriate part from >"uunet!/archive/usenet/news.answers/pictures-faq/part1", >"uunet!/archive/usenet/news.answers/pictures-faq/part2", or >"uunet!/archive/usenet/news.answers/pictures-faq/part3". > For e-mail access, send a message to mail-server@pit-manager.mit.edu >with the mail body "send usenet/news.answers/pictures-faq/part1" to get the >first part, "send usenet/news.answers/pictures-faq/part2" for the second, >and "send usenet/news.answers/pictures-faq/part3" for the third, or e-mail >to mail-server@cs.ruu.nl with "send NEWS.ANSWERS/pictures-faq/part1", >"send NEWS.ANSWERS/pictures-faq/part2", and/or >"send NEWS.ANSWERS/pictures-faq/part3" in the body of the message. > > >II. DOWNLOADING AND DECODING FILES > > Basic checklist: Alternate checklist: > ---------------- -------------------- > News reader News reader (optional in some cases) > Text file editor "Super-decoder" > UUDECODEr > >By far the most common method of posting files to the pictures >newsgroups is the UUENCODE standard. This program, shipped standard >with most implementations of UNIX, converts binary files into plain-text >ASCII files which can be handled by the mail system. You will need a >version of UUDECODE before anything else in order to view anything >downloaded from the net. If your system does not have a version of >UUDECODE available, you can get one via anonymous ftp from >bongo.cc.utexas.edu, in the gifstuff/uutools directory. > >The format of a uuencoded file consists of an optional "table specification", >which consists of the word "table" alone on a line, followed by one or more >lines containing the characters that will be used in the remaining encoded >data. Following this, the standard requires the line containing only the text >"begin " (where "" is a three-character >numeric string, and "" notes the name of the decoded file - for >example "begin 640 myfile.gif"). This "begin" line is then followed by >several lines of approximately 61 characters, all beginning with a capital >"M", and containing any non-lower-case printing character (and very rarely >resembles anything but absolute gibberish). Optionally, one to two lines >may be blank or contain less than the normal number of characters if those >lines are immediately before the line containing the "end" notation (in this >case, these shorter lines will NOT begin with "M"). The "end" text alone on >a line marks the conclusion of the uuencoded data. Any information that does >not fit into the above classifications are termed as either "headers" or >"trailers", and are not intended to be included in the information to be >decoded. For example, the following represents a valid uuencoded file >(although it contains no useful information - don't bother decoding it!): > >begin 666 bogus.file >MLEHHWHURHUH %$^4653%#$#&^%$$46^%#^%)LKDUHEWFHIUG^$^#DJIUTE&F >M&#H:FNP(ENER(*HNFUHDG(&#&B#HY@#(*@YNUF(&$HU$HF(YSAUHIRY(&YHU >#(*NUFE(YHD7H > >end > >Most decoders are smart enough to ignore anything before the "begin" line >and after the "end" line. > >The first step is to save the file you want to view... in most versions >of the newsreader, this is done by pressing 's' followed immediately (no >spaces usually, although some versions don't care) by a file name. >You will usually be asked if you want to save it in mailbox format; >you should answer 'n'. When saving an article to a file in >mailbox format, the article is sometimes changed in a subtle >way, making it impossible to decode. > >In the case of a single-part file, you can now uudecode the file, >which will create whatever output file is encoded. You can usually >tell if it's a single-part file by looking on the subject line; >standard netiquette is to make something like [03/06] part of the >subject line, which indicates you're on part 3 of a 6-part file. If no >numbers are there, you can usually assume it is a 1-part file. If >not, feel free to write the poster (directly... please don't waste >bandwidth by posting) and request that he/she put this info in the >subject line. Be nice about it! Another way to determine if a file >is a single-parter is if both the uuencode "begin" and "end" lines >(as outlined above in the description of the uuencode format) are >included in the file. > >For multi-part files, life is a little more difficult. If all you >have is a standard UUDECODE program (as opposed to a "smart decoder"), >you will need to trim the headers and trailers out from the rest of the >information. You can either do this by saving each part in its own file >and editting them separately, then concatenate the editted files together >to make one big file (this might be your only choice if your editor can't >handle large files!), or you can save each part in order into one big >file and then edit all the headers and trailers out from that file. >Either way, you'll need to run the result through UUDECODE. You can use >your favorite text editor to strip out header and trailer information. > >There are several "smart decoders" out there that will handle all of >the header/trailer stripping and decoding for you (some will even make >sure that the pieces are in order!) - see part 3 of this posting for >specifics. > >Some articles are actually posted with easy decoding in mind, and contain >UNIX shell script headers/trailers that facilitate easier decoding. This >is often very helpful, as it saves you a lot of work, and can also provide >error checking not available in a "normal" uuencoded posting. These >postings nearly always contain instructions on their use, so I won't >attempt to explain all the details here. There's no set "standard" for >this type of posting anyway - except for MIME. MIME, the Multipurpose >Internet Mail Extensions, proposes a standard for the posting and mailing >of multi-media articles (postings may include pictures, sounds, movies, >or other media types - which may be combined in one article). Public- >domain packages using MIME are available (Metamail, for example). For >more information on MIME and Metamail, contact nsb@bellcore.com. > >Some news readers have an "extract" capability that greatly simplifies >life by automatically decoding articles - this means you don't have to >go to the hassle of saving to a file and then decoding. Newer versions >of rn, nn, and trn can handle this - check the "man" page or ask your >news administrator to find out if you can let your news reader do the >work for you! > >If you're going to download the decoded picture file to a home machine, >or move it around a network, remember that most decoded file outputs are >going to be BINARY files, so set your transfer protocol accordingly. >If you are moving around just the uuencoded data, an ASCII transfer will >work just fine, however (you'll have to decode it eventually, of course). >Note that if you *don't* transfer the decoded file in BINARY mode, >everything will appear to work just fine - until you try to view the >picture. Then you'll get all sorts of undefined results... > > >III. COMMON PICTURE TYPES > > Basic checklist: Alternate checklist: > ---------------- -------------------- > GIF viewer Multi-format viewer > Format conversion tool(s) Format conversion tool(s) > Image manipulation tool(s) > >OK. Now you've got this great picture file from downloading it and >running it through UUDECODE. What is it, and what do you do with it? > >The most common type of picture is the GIF format (which usually has >a .GIF or .gif file suffix). GIF stands for Graphic Interchange Format, >and is a standard format for images that was developed by CompuServe to >be a device-independent method of storing pictures. It includes >Lempel-Ziv-Welch (LZW) compression, which makes the files fairly small. > >JPEG is another standardized image compression mechanism, which stands >for Joint Photographic Experts Group (the original name of the committee >that wrote the standard). It seems more and more common that JPEG-type >pictures (.JPG or .jpg file suffix, usually) are getting posted to the >net. Some claim that JPEG is destined to overtake GIF format in popularity, >because it is the most compact method to store 24-bit data, but mostly due >to the fact that it uses much less space to store the same picture (this is, >in fact, true - I have seen many examples of this phenomenon). This may be >an accurate assessment, but this will probably take a while to happen, as >most people HAVE GIF software/viewers, but lack JPEG equivalents. >Undoubtedly, however, this too shall change, but at this point, JPEG is >recognized as still being in its infancy. But, if you prefer to be on the >leading (bleeding?) edge, it is possible to get software both to view JPEG >pictures, and to convert JPEG to and from other formats, as detailed in >part 3. > >The latest and greatest info about JPEG is included in the Tom Lane's >"JPEG image compression: Frequently Asked Questions" (archive name is >"jpeg-faq"), posted on a regular basis to the alt.binaries.pictures.d, >alt.graphics.pixutils, alt.binaries.pictures.erotica.d, alt.sex.pictures.d, >and news.answers newsgroups. > >Of course, to view a picture of a particular type, you will need a viewer >that supports that type (again, for specifics on viewers for your >particular configuration, see part 3 of this posting). > >There are other types of single-picture files posted to the net, >although they are not as common as GIF or JPEG files. Other than the >difference in the viewing software, the downloading/decoding and >encoding/uploading procedures are identical as for other types of pictures. >Platform-dependent picture types and conversion programs are discussed >in part 3 of this posting. > >Occasionally people get into an argument about which standard is best. >I think the answer is: WHO CARES?!? The only thing I have to say >about this matter is that almost every machine under the sun already >has a program written for it to view GIF files, and if yours doesn't, >shareware or PD source code is available almost everywhere. > >Commonly people post files to the net with a .GL extension. These >files are actually animated picture-shows that can be viewed on a small >number of system types. > >Usually, GL files are huge, so people often compress them with one of >several popular compression/archiving packages. Perhaps the most >common is the PC family's PKZIP package. If a GL file is posted with >a .ZIP extension, you know it's been ZIP'ed. Similarly, if it has a >.Z extension, it's been compressed with the UNIX `compress' utility. >"Uncompression" tools of either type are available for various types of >systems - part 3 has the necessary details. > >Files of a .DL extension are also sometimes posted. These are very >similar to GL files, except in format, so of course it takes different >software to view them (this software is also discussed in part 3). > >Then there's FLI - yet another GL/DL type of file. FLI's are generally >considered poorer quality than either GL or DL, however. > >The table below lists many of the common file types for pictures or >compression formats for different systems. This information may be useful >if you download a tool and then don't know how to decompress it into a >usable form, or as a "quick reference" of file types. Decompressors or >viewers of "unlike" system types exist on some systems - see the particular >system information for details on this aspect. > > File extension File type > -------------- ---------- > ARC ARChive (many OS's support) - compressed file(s) > ARJ Yet another archive format - compressed file(s) > BMP Windows and OS/2 BitMaP picture file > CPT Macintosh CompactPro compressed file. > DIB Windows and OS/2 BitMaP picture file > DL Animated picture file (system independent, for > those with viewers) > FLI Animated picture file (system independent, for > those with viewers) > GIF Graphics Interchange Format - > system independent picture file > GL Animated picture file (system independent, for > those with viewers) > IMG IMaGe - ? picture file > JPG (JPEG) Joint Photography experts Group - system > independent picture file > LZH Amiga LZH - compressed file(s) - LHarc output > MAC (MACP) Macintosh MacPaint - Macintosh picture file > HQX Macintosh BinHex - encoded file > IFF Amiga Interchangeable File Format - Amiga > file interchange (used for many types of binary > data). If it contains a picture file, then > the picture is either an ILBM (InterLeaved > BitMap), HAM (Hold-And-Modify), DHAM (DynaHAM), > or SHAM (Sliced HAM). > IM8 (RAST) Sun RASTer file - Sun picture file > PCX IBM PC Paintbrush - IBM picture file > PICT Macintosh QuickDraw PICTure - Macintosh picture > file > PS (PSID) Encapsulated PostScript/PostScript Image Data - > printer-ready text/picture file > RAW RAW RGB - 24-bit system independent picture file > SEA Macintosh Self-Extracting Archive > SHK Macintosh Shrinkit - compressed file(s) > SIT Macintosh StuffIt - compressed file(s) > TGA TrueVision TarGA file - ? picture file > TIFF Tagged Image Format File - 24-bit system > independent picture file > UUE UNIX UUEncoding - encoded file > XBM X windows Bit Map - UNIX/X windows picture file > Z UNIX LZW "compress" - compressed file(s) > ZIP MS-DOS ZIP - compressed file(s) > ZOO MS-DOS ZOO - compressed file(s) > > >IV. ENCODING AND UPLOADING FILES > > Basic checklist: Alternate checklist: > ---------------- -------------------- > UUENCODEr "Auto-posting" tool(s) > Editor or file splitter > News posting software > >First things first: before you do any sort of posting, be sure you've >read and understand the a.b.p* netiquette as outlined in part 1 of this >FAQ. This will save you from countless flamings! > >OK. You need to UUENCODE the file. Find an encoder and encode it! >If the output file is particularly large (i.e. more than 60 KB), it >would be wise to split up the encoded file into smaller parts (<= 60 KB) >and then post those. You can split the file with a text editor if you >like, or check part 3 for more specifics on splitting utilities. > >Now post the files... and remember to include the neat info mentioned >in part 1, like subject lines that mean something, descriptions, >checksums, "Cut Here" lines, etc... > >There are some very nice "super posting" utilities out there that will >handle all the lower-level details for you. See part 3 for more info >on these utilities. If you don't use one, you'll obviously need to do >all the uuencoding, splitting, and the posting of each split part >yourself - which can become quite a tedious process! Another benefit of >the "super posters" is that they enforce some standardization on the way >posts look - making an auto-decoder's job much easier in the process! > > >V. ALTERNATE SOURCES FOR PICTURES/HOW-TO'S OF FTP > > Basic checklist: Alternate checklist: > ---------------- -------------------- > Direct Internet access E-mail software > FTP software > "archie" access > >The pictures newsgroups are certainly not the only source for pictures, >nor are GIF files the only types available (see section III). The most >likely place you are to find other pictures is in an archive that is >reachable via FTP. FTP stands for File Transfer Protocol, and is a >program for transmitting files over the network. To use FTP, you will >need access to a computer with the FTP program, and a network connection. >Be aware that files on FTP sites will probably NOT be UUENCODED, so >remember to transfer in binary when getting non-text files. >For the greatest level of detail on FTP and finding sources in general, you >should refer to the posting "How to find sources (READ THIS BEFORE POSTING)", >which is periodically posted to comp.sources.wanted, alt.sources.wanted, and >news.answers OR you can execute either 'finger ftp@piggy.ucsb.edu' or >'finger ftp@ferkel.ucsb.edu' to get a quick tutorial. You can also get the >"finding sources" FAQ via anonymous FTP, available on either >pit-manager.mit.edu [18.72.1.58] in /pub/usenet/news.answers as the file >"finding-sources.Z", on ftp.cs.ruu.nl [131.211.80.17] in /pub/NEWS.ANSWERS >as "finding-sources", on ftp.uu.net [137.39.1.2, 137.39.1.9, or 192.48.96.2] >in /usenet/news.answers as file "finding-sources.Z". UUCP access is done by >retrieving the file "uunet!/archive/usenet/news.answers/finding-sources". >Lastly, you can get this FAQ by sending a message to either of >mail-server@pit-manager.mit.edu with the mail body >"send usenet/news.answers/finding-sources", or to mail-server@cs.ruu.nl with >"send NEWS.ANSWERS/finding-sources" in the body of the message. >One of the useful things detailed in the "finding sources" posting mentioned >above involves the use of the "archie" facility, which makes it very easy to >find a program if you know its name (or just part of its name if you specify >the "set search sub" option). You can do this either directly by logging >into an archie server or via e-mail. It may take a small amount of effort - >but it's a heck of a lot easier and faster than asking the entire >net.population! > >Additionally, it is possible to get files from anonymous FTP sites via >e-mail. For details on this wonderful facility, send an e-mail containing >the text "help" to ftpmail@decwrl.dec.com. For those of you on BITNET, >send an e-mail containing the text "help" to bitftp@pucc.princeton.edu. >Now you too can get all sorts of great utilities from anonymous FTP sites >using an e-mail proxy! > >Due to popular demand, an anonymous FTP site list of pictures-related >"stuff" has now been compiled and is available from bongo in >/gifstuff/ftpsites. This list is by no means guaranteed to be accurate >or comprehensive, but hopefully most of the information is valid. BTW, >this list is a condensed and supplemented version of the Jan. 20, 1990 >revision of Jon Granrose's (odin@pilot.njin.net) "List of Hosts that >Accept Anonymous FTP Requests", which is posted regularly to comp.misc, >comp.sources.wanted, and alt.sources.wanted, and also available via >anonymous FTP from pilot.njin.net (128.6.7.38). Any additions or >corrections would be most welcome and appreciated! > >Most ftp programs will allow you to enter something like > ftp wsmr-simtel20.army.mil >which will connect you with the mighty SIMTEL-20 archives at the White >Sands Missile Range. Occasionally, you will encounter an ftp program >that is old enough or slothful enough that it does not recognize >internet-style addresses like the one above. In that case, you'll >need to know the computer's numeric address; for SIMTEL-20 >you would enter > ftp 192.88.110.20 > >Once you're connected, you'll have to tell the computer at the other >end that you want to log in, by entering USER (some machines save you >this step by *assuming* you want to log in. What else would you want >to do?) When you are prompted for an account name, enter > anonymous >When it asks you for a password, enter *your* internet address. > >Often the machine to which you are trying to connect will be busy >(i.e. too many anonymous users), in which case the machine will inform >you of this and throw you off. Try again later. > >Now you're in. What do you do? Well, you need to know where the >files are stored that you want. If you know this, just > cd directory-name >to the directory in question. Then you can do a DIR to find out >what is in it. > >So you see a file called CRSH+BRN.GIF and you want it for yourself. >What do you do? Well, the first thing is to tell the computer on the >other end that you want it to transmit a binary file. On most FTP >servers, entering the magic word TENEX will do this. If the machine >doesn't recognize TENEX, try BINARY, or if all else fails, you can >enter > TYPE L 8 >Be sure to do this for GIF files or you'll get garbage when you try >to view them! >The difference between TENEX and BINARY is in translation of data type >sizes - if your machine type has different data type sizes than the one >you're downloading from, use TENEX, otherwise use BINARY. If you're not >sure, try TENEX first (if the command isn't recognized, you're probably >OK). On some VAX platforms, the keyword "IMAGE" is also sometimes used >to denote binary files. > >Now you're ready to grab the files you want. You have two options: >you can type > get filename >or > mget wildcard >where wildcard is any UNIX-style wildcard. MGET will get all files >that satisfy the specification. > >When you're done grabbing files, type QUIT or BYE to log off the remote >machine and return to yours. Now you're ready to view the picture - >no decoding step necessary (neat, eh?)! > >Most of the non-erotica pictures that appear in postings to the >alt.binaries.pictures* hierarchy are available from anonymous FTP sites >(again, see bongo's "ftpsites" list), but this is of course not guaranteed. > >The other most common method for obtaining files is from an archival >file server. Most of these work in the following way: you send mail >to the server's address, with one-line commands in your message, like > help > directory \pictures\gif\family-oriented > send \pictures\gif\family-oriented\CRSH+BRN.GIF >and the requested info is sent back to you at some later time, when >the server has time to get around to it. > >The first step when you discover a server system is to send a HELP >command so you can learn what the commands are for that server. >However, most servers operate with commands basically similar to those >listed above. > > >VI. COMMON PROBLEMS > > Basic checklist: > ---------------- > At least one clue > Some small level of intelligence > Self-determination > >Well, you've downloaded the file, tried to view it, and got garbage. >What went wrong? > >The two most likely places for something to go wrong are both in the >transmission of the file. The first is this: when you downloaded the >file to your home computer, did you remember to tell the modem- >transfer software that you're sending a binary file? > >The second-most likely is that you forgot to say TENEX before you >grabbed the file via FTP. > >Either of these will result in mangled files that are unviewable by >anything known to man. > >Also: did you remember to trim off the header and trailer information if >you are/were using a "simple" uudecoder? The symptom of forgetting to >do this is usually a message something like "short file" from your GIF >viewer. There could also be the problem where blank lines are left >between parts (or anywhere for that matter) within the 'begin' and 'end' >lines of the uuencoded file. Uudecode will get through them fine, but some >GIF viewers will choke on the results. The only blank line I've seen >get by is the one just before the 'end' statement. Beware of taking >too much or not enough off of the headers and trailers. > >Another common problem is this one: IBM mainframes often use an >EBCDIC character set (yes, there's more than one EBCDIC set!) instead >of the ASCII set used by everyone else. This wouldn't be a problem except >that most ASCII-EBCDIC converters have a bug which mungs the translation >of several characters, including ^ { } and a few others. Even this >wouldn't be a problem except that the particular munging it does is to >map several of these characters onto the *same* wrong character. Ooops. > >The way around this is not to use uuencode to transfer these files, >but to use xx-encode, which produces files which look almost exactly >like uu-encoded files, but they use a character set which is >IBM-proof. If you are using an IBM mainframe as your host computer >and you're having trouble decoding files, this is most likely your >problem. Solution: 1) find a kind soul who is willing to uudecode the >files, xxencode them and send them to you, 2) get the files via FTP, >which should be EBCDIC-proof, or 3) get a better computer that uses >everybody else's character set. :-) > >Sometimes, you need to run the "bilf" utility on a file in order to >fix it. The "bilf" utility changes carriage-return/line-feed sets >into just carriage-return (or vice-versa). MSDOS uses CR/LF at the >end of lines to indicate end-of-record, UNIX and VAXen use only CR. >You might want to try running bilf before unzipping, compressing, etc. >if you are running into problems. bilf also comes in handy when you >are using Kermit to transmit to/from Unix and VMS. > >Almost all of the problems described above can be checked by using >GIFTEST to check the GIF file's integrity on your host machine before >you download it. I have recently added the source code for GIFTEST to >the archive at bongo. I highly recommend that you get a copy of this, >even if you only occasionally have problems with your GIF files; it >runs in only a few seconds, and has the potential to save you hours of >download time! > >The last and least likely problem is that some mailer somewhere >actually munged the file. It happens. Fortunately, it doesn't happen >all that often. When it does (and please check all of the other >problems *FIRST*), it's time to ask for a re-post, as detailed in part 1. > > >VII. COPYRIGHT > >Bottom line: It's OK to copy something (electronically or otherwise) for >your own personal use. It's NOT OK to re-distribute that copy, whether or >not you make any money doing it. > >------------------------------------------------------------------------------- > >That's about it for the "general" information. System-specific >information is continued in part 3 of this FAQ. If you have any >suggestions for things to include in future versions, don't hesitate >to let me know... > > >-- > Jim Howard *** jhoward@best.com *** http://infolane.com/deej/index.html > Author, "The Internet Voyeur" (http://infolane.com/deej/voyeur.html) > (^:= Flames cheerfully ignored. =:^) >................................................................................ >"Death is life's way of telling you you've been fired." -- R. Geis >