NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/5531

Internet Message Format | 1996-08-05 | 9.1 KB

Path: uu4news.netcom.com!genesplicer!209-254-8!joey.mcdonald
From: [e-mail] (Joey McDonald)
Date: 15 Mar 96 10:49:56
Newsgroups: comp.sys.amiga.programmer
Subject: DCTVpost 3/5
Message-ID: <[e-mail]>
Organization: The GeneSplicer

The only control we need to adjust is the blue-level slider. Simply increase
the value to 57 (the highest setting possible without causing distortion) and
you'll see an immediate and vast improvement in the composite image. Using this
single control you can quickly and easily achieve results similarto (if not
identical to) those obtained using method #1.

By experimenting with the controls on the color bias panel and palette window
you may find that other interesting enhancements or image effects are possible.
It's also worth noting that DCTV is even capable of displaying composite data
from an Amiga 1-bit image.. (although the display quality is ver poor).


                                 PROOF POSITIVE!


Our final image (figure 3) does exhibit a small amount of streaking and color
flicker in some areas, but I'm sure you'll agree that it's the most impressive
looking 2-bit image ever generated by a computer. Considering the methods used
to create this display I think the results are quite remarkable.This image
proves that it's possible to display a DCTV image within 2-bitplanes while
retaining a large enough palette to achieve high quality results. In my
opinion, this image rivals any comparable ECS Amiga generated display. When it
comes to file size and animation speed (I'll get to those in a oment) the HAM6
and HAM8 display modes cannot compete.

A reduction in file size is one of the real advantages of generating a DCTV
display within 2-bitplanes. The original file size of the 4-bit froggie.dctv
image was 109614 bytes and our 2-bit version weighs-in at only 63734 bytes.
That's a savings of 45880 bytes without any added file compression! Obvously
the results will vary depending on the image being converted, but I have found
that most images will yield at least a 40-50% reduction in file size, while in
certain instances you may achieve a 50-60% (or greater) reduction.

We have not only achieved a savings in storage space, we have also gained an
increase in display speed. Try viewing the image with a display utility and you
should notice that it appears on screen faster than the original 4-bit image.
Loading the image in to a program such as Deluxe-Paint and then ceating a small
animation (using the MOVE requester) should make the speed increase even more
apparent.

With such a dramatic reduction in image file size and a visible increase in
display speed, the DCTV 2-bit display mode shows great potential in the area of
animation. Let's take a quick look at what the requirements are to animate in
this new mode.


                          DECLARATION OF ANIMATION!


At present, the only way to create a DCTV 2-bit animation is to perform the
conversion on each individual anim frame (something I wouldn't recommend unless
you have plenty of time on your hands). It's impossible to automate the process
within Pixmate due to the programs lack of an Arexx port, and sice I have not
found another image processor capable of the same results the need for an
entirely new program arises.

To offer a rough idea of the potential anim file size reductions and increases
in animation speed, I opted to manually convert the SceneryAnim.anim file found
on DCTV disk #4. Not having the luxury of owning a commercial program capable
of splitting and compiling animations, I relied on two programsavailable on
most good BBS's. BuildAnim2 (by Christer Sundin), and AnimBuild (by Michael
Hartman). BuildAnim2 can perform both splitting and compiling but had problems
compiling this particular anim. I relied on AnimBuild for animation compiling.

Using BuildAnim2 I split the animation into individual frames. I then performed
the 2-bit conversion on the first anim frame and saved the results. To speed up
the tedious process of palette adjusting I used the Pixmate "Load Palette"
option to load my set palette for each additional frame. After coverting all of
the remaining frames I used AnimBuild to re-compile each 2-bit image back into
an anim file.

The original anim file size was 452398 bytes. After conversion the size was
reduced to 276810 bytes, a savings of 175588 bytes without any added file
compression. Compressing the converted anim via PowerPacker yielded an
additional 37% reduction in size, for a total file size of 175196k. That's
neary 200k savings without added compression and nearly 300k with compression.

Satisfied with the reduction in file size I then proceeded to test the
animation on a variety of popular anim viewers. View3.0 (contained on DCTV
disk#4) and PPSHOW3.0 displayed the anim without any problems. View3.6,
Superview3.12 and Viewtek2.1 also displayed the anim properly but required
manual entering of the display via the arrow keys. For an unknown reason the
Viewtek program played the anim with a "glitch" or color blotch on a few
frames. This did not occur with any other viewer.

Whichever player program you use, look for the ability to manually center the
display. An improperly centered screen will prevent DCTV from detecting and
displaying an image or anim correctly. (The 2-bit display mode seems to be a
bit more sensitive to centering, make sure animations are centered corectly
when recording to video tape or you may end up with b/w or distorted output.)

As far as gaging an actual increase in animation speed, I relied on the
information provided by the View3.6 program. On my SupraTurbo (28mhz 68000)
enhanced Amiga 2000 the stats were as follows. Before conversion: 6742 avg
DLTA, 44,9982 avg FPS. After conversion: 4092 avg DLTA, 60,0000 avg FPS.
Admitedly not the most accurate test results, but fairly informative. There is
a notable FPS (frames per second) increase and a reduction in avg DLTA (less
pixel changes in the anim,..  which is not surprising considering we have
chopped two bitplanes).

Overall I was very impressed with the results. Any loss of image quality due to
the conversion process is far less noticeable while an animation is playing. I
certainly don't believe that the SceneryAnim conversion is the most effective
example of the quality of 2-bit DCTV animation, but I believe i does give us a
basic idea of its capabilities. You'll have the ability to play longer, more
complex animations at faster speeds while using less storage space and less
memory.


                         PROBLEMS and POSSIBILITIES:


Once you have performed the 2-bit conversion on various images, you'll notice
that some pictures do not convert well at all. Keep in mind that we're using a
standard Amiga image processor on DCTV images (It doesn't "know" which colors
it's actually allowed to remove or remap) and we're working in a CTV mode that
technically does not exist. The results we obtained in the tutorial are
actually quite incredible considering those factors. Pixmate was only used to
demonstrate that DCTV can indeed function in an Amiga 2-bit mode while
generating acceptable (even desirable) results.

A utility designed specifically for performing the conversion would not only be
more convenient to use but also far more effective. It's possible that a
variety of techniques designed to match, antialias or dither colors could be
implemented to further enhance the quality of converted images. The reults
would almost certainly be superior to what we have achieved using Pixmate.

The question then arises, why settle for conversion? Current software could be
updated and new software designed to take full advantage of this new display
mode. Paint and digitize software designed to work within the limitations of
the DCTV 2-bitplane palette may not generate the image streaking orcolor
distortion that often occurs during conversion. Imagine being able to directly
digitize images equal in quality to our converted froggie.dctv picture while
retaining file sizes in the range of 50-60k. Sounds good to me!

I would urge Digital Creations (or PLAY inc.) to support DCTV with new and
updated software, but looking back at there track-record of only one update in
four years, I don't think that's going to happen any time soon. If they will
not support DCTV they should place all hardware specs and program cod in the
public domain to promote the creation of new software. The P.D. approach
certainly worked for BlackBelt's Ham-E device which enjoyed heavy support by
3rd parties, including direct support within various frame grabbers, as well as
3 separate paint programs (2 of which allowed animation). It wuld be nice to
have those kinds of choices with DCTV.

While it's true that this new mode is nothing more than a hack of sorts and
that it's certainly not a professional display, I'm sure there are plenty of
artists and animators who can find many interesting uses for it. If you're
working on a low memory or small HD system it may give you the extra wor space
and speed increase you've been looking for. If there are some clever
programmers looking for a challenge, it's a new frontier just waiting to be
conquered. I hope to hear more about this exciting discovery in the future.