Frequently, alt.* newsgroups are added _only_ when a customer specifically requests it -- too many 'prank' groups in the hierarchy. If it isn't on your server, contact your provider and _ask_ for it.
This is a functionality of the software you use to read USENET.
There are _multiple_methods_ used for 'encoding' non-text stuff.
The 'classical'/traditional method for USENET is called "uuencode" These messages have a line with the word 'begin', followed by a 3 or 4 digit number, followed by the file-name.
With the advent of MIME, which by definition is for _mail_, some people started using MIME's 'base64' encoding in USENET news articles as well.
These messages have 'standard' MIME sub-headers, and a block of base64 encoded data
Then, some *idiots* decided to invent 'yet another method', which they called 'yenc'. They just built the software and uploaded it to various free distribution points. It's supposed advantage over the standard methods is that the actual "messages" transmitted are smaller -- both uuencode and base64 require 4 bytes of 'text' in the message to represent
3 bytes of the actual binary file. Yenc uses 8-bit data, and 'escapes' a few characters that are 'known' to be dangerous -- with the result that if the message passes through a server that it *not* '8-bit clean' (and _many_ news-servers are *not*, even to this day), the message is irreparably corrupted. But, robustness of design was -not- a consideration for yenc's designers. If some part of the 'rest of the world' doesn't behave in accordance with their 'expectations', then "obviously" that part of the rest of the world is 'in error', and it is *their* problem to fix it. People that use 'yenc' encoding are: stupid, ignorant, inconsiderate, uncaring, or some combination thereof -- probably "most of the above". :)Anyway, depending on what software you use to read news, it may, or may *not*, automatically recognize some/most/all of the above-mentioned encoding methods.
*IF* it recognizes the encoding, then it can 'decode' things to get back the original file . Which it then has to hand off to some form of 'viewer' to display the content. 'pictures' come in a _whole_slew_ of file formats: '.GIF` developed by CompuServe, some compression, limited colors '.PNG' "picture, the next generation" (I'm *NOT* kidding!" a GIF replacement to sidestep some legal (patent) issues with the methodology of creating GIF images. '.JPG' "photo-realistic" (i.e. 16million color) images, 'lossy compression', but compresses to much smaller than GIF files. designed for 'efficient' storage of actual photographic images '.BMP' Microsoft's "windows bitmap" format -- "who cares about file size? it's quick and simple, and doesn't take much processing" can easily be _hundreds_ of times larger than an equivalent JPG '.TIFF' a portable specification for high-resolution computer-generated work. not so good for reproducing actual photographic images '.PS` and '.EPS' the infamous "PostScript", designed for computer-generated technical graphics. '.PDF' Adobe's 'portable document format', which can (obviously) include images -- needs "acrobat reader", or a functional equivalent, to view the content.and probably at least 50 other varieties.
Not to mention that some people are posting images in "MacroMedia ShockWave Flash" (enhanced web-page add-in) format.
Practically all image rendering s/w knows what to do with GIF and JPG, and almost everything written in the last 5+ years knows what to do with PNG images. For broader coverage, you may have to employ multiple viewers, and/or specialized 'helpers' for specific file formats.
if your newsreader understands the 'encoding', and can recover the actual 'binary', it _still_ has to "know what to do" with that stream of bits. If it's in a file format it doesn't know how to display..... well you won't be able to see the picture. ;)