🚀 go-pugleaf

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 similar to (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
very 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 moment) 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! Obviously
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
creating 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
since 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 programs available 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 converting 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
nearly 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 centering 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
correctly 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.
Admittedly 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
it 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 DCTV 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 results
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 or color 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 code
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 would 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 work
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.