An introduction to OS 4 picture
datatypes by Oliver
Roberts
The concept of datatypes made its debut on AmigaOS
in Release 3.0, making it possible for applications to read
virtually any type of data file (pictures, sound, movies, and
so on) with ease, for which a suitable datatype class is
available, through a common object-orientated API. To a
certain extent, this helped alleviate the need for application
writers to spend time developing their own custom decoding
routines and also meant that applications could load any type
of data transparently without needing to modify the
application at all.
Arguably, the most common and important type of
data file handled by datatypes are pictures, and with this
being my area of expertise, this article concentrates on this
area. These days we take datatypes for granted, but imagine if
you were restricted to using ILBM images! Seems unlikely,
albeit until AmigaOS 3.0 this was not so unthinkable, when
applications had to deal with decoding image data themselves -
the datatype system in turn made it extremely easy for
applications to load images using the users' preferred image
file formats.
Picture datatypes are used in various OS 4
components more than ever before - not only just for Workbench
backdrops and by Multiview, but the new Intuition GUI relies
on datatypes to load images too. Datatypes are also utilised
by IBrowse, which will always fall back to attempting to load
an image via datatypes if it cannot handle an image itself
(it's not uncommon for websites to use inline BMP images, for
example).
In the past, the trend has been that picture
datatype classes have been developed and supplied by third
parties, with the only type of picture readable on a vanilla
installation of AmigaOS 3.1 being ILBM images (and then only
up to 8-bit). Obviously, being the traditional file format
used for images on the Amiga, this type of file had to be
supported. Unfortunately, it was then left up to the user to
find and install third party datatypes to allow him/her to
view other types of images through the datatype system.
Thankfully, AmigaOS 3.5 and 3.9 did provide JPEG and GIF
datatypes, although neither of these made use of the PowerPC
processor which was supported in the OS at that time by the
inclusion of WarpUp - this was a disappointment to many
BlizzardPPC and CyberstormPPC users, including myself.
JPEG images in particular use a CPU intensive
compression scheme. Back then, I was not satisfied with any of
the existing JPEG datatypes, and knew it was possible to make
a JPEG datatype utilising the PPC which could decode images
much faster. And that is where my involvement in developing
picture datatypes began in earnest four years ago, with the
end result being the Warp Datatypes (WarpDTs). Over the years,
the WarpDTs have matured from simply being a fast PPC JPEG and
PNG datatype solution into a whole family of datatypes using
the same fundamental engine and design principles, rock solid
stability, greatly improved support for far more types of
images and extensive support for both 68K and PPC.
In my opinion, it is very important that OS 4
provides support for commonly used image types, including not
only ILBM, but JPEG and PNG especially. Consequently, brand
new JPEG, PNG, TIFF and BMP datatypes have been specifically
developed for OS 4 (these are accompanied by PPC ports of the
existing GIF and ILBM datatypes, and of course the picture
datatype superclass). Needless to say, these four new
datatypes are heavily based on the WarpDT code, so therefore
share a very similar feature set. Additionally, since the
datatypes are targeted specifically for OS 4, it has allowed
certain assumptions to be made, making it possible to
streamline various parts of code, increasing efficiency and
speed.
Everyone is no doubt familiar with JPEG images,
but probably less so with PNG - a flexible modern file format
offering some unique and impressive features, originally cited
as a replacement to GIF. However, PNG is much more than that.
Unlike JPEG, PNG offers lossless compression, which offers far
better compression ratios than the relatively simple RLE
compression used by ILBM files. Obviously, better compression
implies a speed trade off, although this is really a
comparative non-issue for PPC implementations. Despite its
advantageous qualities, PNG is often conveyed as being
unpopular, largely due to slow take up and limited support by
other OS and software vendors. However, Amiga users have been
fortunate in that many existing applications embraced the PNG
image format early on. Until this time AmigaOS has not
provided PNG support, but with the addition of a PNG datatype
as standard for OS 4, hopefully developers and users will feel
more comfortable in using PNG as a viable format for image
storage.
Although TIFF and BMP files are not commonly used
to store images by AmigaOS applications, they are used
frequently on other platforms, so with OS 4 supporting these
types of images it means that users can easily transfer images
from other systems to their Amiga, without having to worry
about converting them to a different image format. Third-party
TIFF support for AmigaOS has always been somewhat
sub-standard, with other datatypes only being able to load a
small subset of TIFF files, being very slow or just plain
broken. In contrast, due to its WarpTIFF origins, the OS 4
TIFF datatype offers by far the largest coverage of the TIFF
specification available for AmigaOS and moreover is able to
load images efficiently, at speed.
Given that the WarpDTs are so highly optimised and
are comparatively fast even on 68K, the OS 4 datatypes should
be an absolute dream to use on the AmigaOne, and I for one am
looking forward to this prospect. And what's more, the OS 4
datatypes are largely already completed, and are being tested
on the CyberstormPPC version of OS 4 without any problems.
Anyway, I hope you have enjoyed my take on this
distinct slice of the OS 4 feature set. For more information
on the WarpDTs and/or if you would like to try out the latest
versions for AmigaOS 3.x, see the WarpDT
pages. |