@database WarpJPEG.guide
@master WarpJPEG.guide
@$VER: WarpJPEG.guide 1.24 (19.10.2001)
@author "Oliver Roberts (oliver@futaura.co.uk)"
@(c) "Oliver Roberts 1999-2001"
@width 75
@remark Created with Heddley v1.20ß © Edd Dumbill 1994-5

@node "Main" "WarpJPEG.datatype 44.25"

    @{b}WarpJPEG.datatype 44.25@{ub} - the @{"fastest" link "Speed" 0} 24-bit JPEG picture datatype!
                                (for 68k, PPC/WarpOS and PPC/MorphOS)

         Copyright © 1999-2001 @{"Oliver Roberts" link "Author" 0}, All Rights Reserved.


   @{" Description               " link "Intro" 0} what is this datatype for?
   @{" Features                  " link "Features" 0} list of features
   @{" System requirements       " link "Requirements" 0} what you need to use this software
   @{" Installation              " link "Install" 0} installing this software
   @{" Preferences               " link "Prefs" 0} descriptions of configurable settings
   @{" Speed                     " link "Speed" 0} information regarding speed issues

   @{" Distribution              " link "Distribution" 0} distribution conditions
   @{" Disclaimer                " link "Disclaimer" 0} important notices

   @{" Acknowledgements          " link "Acknowledgements" 0} thankyous and credits
   @{" Support & the Future      " link "Future" 0} support + improvements I intend to make
   @{" About the author          " link "Author" 0} how to contact the author
   @{" History                   " link "History" 0} program history
@endnode

@node "Intro" "Description"
As you've probably guessed, WarpJPEG.datatype is a yet another JFIF/JPEG
datatype.  The original difference being that it was for owners of PPC
cards, and was targetted specifically at WarpUp (not PowerUp).  Even
better, it is fast, compact, clean, well behaved and fast - a true
plug'n'play PPC datatype.  Now though, 68k optimized and MorphOS native
versions have been added, which also benefit from my WarpDT engine.  One of
the key features is its superior speed, hence the name WarpJPEG.

I originally decided to write this datatype because no other decent WarpOS
native JPEG datatype existed for the PPC, and I thought this would be the
ideal chance to finally learn how to start coding PPC stuff on the Amiga.
@endnode

@node "Features" "Features"
 - Supports regular JFIF files, and also many JPEG variant formats such
   as Exif, Adobe, Photoshop, Mavi, Windows, JCCK/CMYK colorspace files
   and other less common formats

 - Supports both normal and progressive JPEG files

 - Full true colour (24-bit) and high quality reduced colour (256 colours
   or less) and greyscale output modes, for graphics cards and native
   Amiga displays respectively

 - Highly optimized datatype dispatch engine, and fast JPEG decoder,
   resulting in a very efficient, compact and quick JPEG datatype

 - Asynchronous file i/o and double buffering techniques (WarpOS only),
   which speeds up image decoding
 
 - Optimized versions for 68020, 030, 040 and 060

 - PowerPC support with native WarpOS and native MorphOS versions

 - Alter the pen allocation precision when images are remapped to an
   8-bit display

 - Specific support for the OS 3.5/3.9 picture.datatype, when available

 - The dithering feature of the OS 3.5/3.9 picture.datatype can be
   configured to your liking (e.g. disabled for 15/16-bit displays)
@endnode

@node "Requirements" "System Requirements"
This datatype needs the following in order to work:

 - Kickstart 3.0 or higher
 - picture.datatype v43 or higher
   (i.e. either of the ones supplied with AmigaOS 3.5/3.9, P96 or CGraphX)

 @{i}68k version@{ui}

 - 68020 processor or higher (optimized versions included)

 @{i}WarpOS version@{ui}

 - PPC accelerator card + 68040/060
 - WarpUp Release 5.0 or higher

 @{i}MorphOS version@{ui}

 - PPC accelerator card
 - MorphOS beta release 1 or higher

Note that a graphics card is @{i}not@{ui} necessary.
@endnode

@node "Install" "Installation"
To install WarpJPEG.datatype, simply run the provided installer script by
double-clicking the icon.  This will create a CPU specific version of the
library for you, and install it to SYS:Classes/Datatypes and also installs
the JPEG descriptor file to DEVS:Datatypes.  It does nothing else, so you
needn't worry about it messing about with your system :)
@endnode

@node "Prefs" "Preferences Options"
WarpJPEG can be configured using the "Datatypes/WarpJPEG.prefs" environment
variable.  The preferred way of altering the settings is via the
WarpDTPrefs graphical user interface (requires OS3.5 or higher), available
from http://www.nanunanu.org/~oliver/warpdtprefs.html or Aminet
(util/dtype/WarpDTPrefs.lha).

However, it is also possible to alter the settings manually by changing the
environment variable with setenv, according to the following template:

  DITHER_OVERRIDE/K,DITHER_QUALITY/K,DITHER_DEPTH/K/N,PENS_OVERRIDE/K,
  PENS_QUALITY/K,OUTPUT_MODE/K,DCT_METHOD/K,FANCY_UPSAMPLING/T,DITHER/K,
  QUANTIZATION/K,NUM_COLOURS=NUM_COLORS/K/N


@{b}@{fg shine}@{bg shadow}OS3.5 DITHER CONTROL OPTIONS@{ub}@{fg text}@{bg back}

The three dither options all interact with each other and apply only when
at least picture.datatype V44 (OS3.5/3.9) is in use.

By default picture.datatype V44+ dithers images for all target displays
less than 24-bit.  It is debatable whether it's worth using dithering on
15/16-bit displays - for photographic images, the difference is usually not
noticable, but for computer generated images containing smooth colour
gradients dithering produces a noticably better output image.

@{b}DITHER_OVERRIDE@{ub}

Selects what our dither quality setting should override:

  NOTHING    - do not change the dither quality in any circumstances
  DEFAULTS   - only override picture.datatype's default dither quality,
               which is used when the application does not specify it's
               own dither quality value
  APPS       - override the dither quality that an application may set
  EVERYTHING - always use your custom dithering settings

@{b}DITHER_QUALITY@{ub}

Select the dither quality to use when this datatype decides that changes to
the dither quality are required, according to your dither override and
depth settings:

  POOR - simple colour remapping and no dithering (fastest)
  GOOD - slower, higher quality dithered output (default)
  BEST - similar to GOOD, with maybe slightly higher quality output

@{b}DITHER_DEPTH@{ub} (Screen Bit Depth Filter)

Use this option to select which display depths should use the above quality
setting.  When the target display is deeper than the given depth value, the
above dither quality will be applied to that image.  For example setting
this to 8 will cause the dithering settings to be used for 15/16-bit target
displays, but left untouched when the target display is <= 8-bit.


@{b}@{fg shine}@{bg shadow}PEN SELECTION OPTIONS@{ub}@{fg text}@{bg back}

The pen selection options are only relevant to 8-bit displays, and adjust
the precision to which pens/colours are allocated, which affects the image
quality and number of pens that will get used.

@{b}PENS_OVERRIDE@{ub}

Selects what our pen/colour quality setting should override:

  NOTHING    - do not change the pen precision under any circumstances
  DEFAULTS   - only override picture.datatype's default pen precision
               quality, which is used when the application does not
specify
               it's own pen precision value
  APPS       - only override the pen precision that an application has set
  EVERYTHING - always use your pen precision settings

@{b}PENS_QUALITY@{ub}

Changes the pen precision quality to use when remapping an image to an
8-bit display, in situations according to your pens otherride setting:

  POOR - use only a small amount of unique colours, at the expense of
         image quality
  GOOD - allocate enough pens to ensure a reasonable output image
         quality, whilst not hogging all pens for a single image (default)
  BEST - allocate as many pens as possible/necessary, resulting in the
         best image quality, but when displaying multiple images on the
         same screen, the quality of every image might not be so good


@{b}@{fg shine}@{bg shadow}DECODER OPTIONS@{ub}@{fg text}@{bg back}

The following options define the internal settings of the JPEG decoder:

@{b}OUTPUT_MODE@{ub}

Switch between full colour (24-bit colour / 8-bit greyscale) output or
reduced colour (256 colours or less) output.

  FULL    - output a full colour image, which may be dithered down by
            picture.datatype to satisfy the target display requirements,
            if necessary (default)
  REDUCED - output a reduced colour image, which results in much higher
            quality images if you only have 8-bit display modes
            available (e.g. if you don't have a graphics card).  The
            quality of this mode can be altered using the colour
            reduction options below.
  GREY    - always output a greyscale image.  The quality of this mode
            can be altered using the colour reduction options below.

Selects which decode method to use.  Two methods are available:

  SLOW - high quality, accurate integer algorithm (default)
  FAST - slightly faster (on 68K) integer algorithm, but sacrifices the
         output quality.

@{b}DCT_METHOD@{ub} (DCT Quality)

Selects which decode method to use.  Two methods are available:

  SLOW - high quality, accurate integer algorithm (default)
  FAST - slightly faster (on 68K) integer algorithm, but sacrifices the
         output quality.

Note: PPC users should probably stick with the slow algorithm since the
fast methods is only fractionally faster on a PPC (on a 603e, at least).

@{b}FANCY_UPSAMPLING@{ub}

  ON  - do careful upsampling of chroma components
  OFF - use a faster, but sloppier method.  The visual impact is usually
        very small, and the speed gains can be significent on some images
        (default)


@{b}@{fg shine}@{bg shadow}COLOUR REDUCTION OPTIONS@{ub}@{fg text}@{bg back}

These options are only relevant when using the reduced colour output mode:

@{b}DITHER@{ub}

There are three dithering modes available:

  NONE    - no dithering, which is extremely fast, but the image quality
            will not be very good
  ORDERED - ordered dithering gives satisfactory output image quality,
            at a high speed
  FS      - floyd-steinberg dithering gives the very best output image
            quality, but at the expense of speed (default)

@{b}QUANTIZATION@{ub} (Colour Quality)

This option changes the way in which colours are chosen for the palette of
a reduced colour image.  Note: this option does not have any affect when
ordered dithering is chosen.

  POOR - do a single pass quantization in order to create a satisfactory
         palette
  BEST - use two-pass quantization, which is slower, but creates an
         optimum image palette, and therefore a higher quality output
         image (default)

@{b}NUM_COLOURS@{ub}

Select the maximum number of colours that the output image should use. This
may be anything between 8 and 256 colours (defaults to 256).
@endnode

@node "Speed" "Speed"
@{b}@{fg shine}@{bg shadow}The fastest JPEG datatype?@{ub}@{fg text}@{bg back}

The table below shows the time (in seconds) it took to decode 10 different
images on my A1200 603e/240MHz 060/50MHz, with BVision and CGX
picture.datatype, with other tested datatypes configured as close as
possible to WarpJPEG's internal settings.  However, I should emphasize that
the figures above are for comparison purposes only - the actual values are
likely to be slightly different (faster or slower) on your system, but I'm
confident that the WarpOS version of WarpJPEG is noticably faster than all
alternative PPC datatypes.

The figures speak for themselves...  WarpJPEG for WarpOS is around 70-90%
faster on most images (twice as fast on greyscale and small colour images)
than other PPC datatypes and around 3-4 times faster than 68k datatypes on
a 060 (the speed difference will be even greater on 040 systems with a fast
PPC).  Maybe you don't believe these claims - my answer to that is
simple...  Try WarpJPEG for yourself and you will see the difference! :)

                                 +-------------------------------+
                                 |@{bg fill}     @{fg shine}PowerPC/68K (dual-cpu)@{fg text}    @{bg back}|
                                 +---------------------+---------+
                                 |          WarpOS     | PowerUp |
                                 +----------+----------+---------+
                                 |          |   akJFIF 44.112    |
                                 | WarpJPEG |                    |
                                 |  44.25   | PPCLibEmu  PowerUp |
                                 |          |            native  |
 +-------------------------------+----------+--------------------+
 | 2008x1597 col,   225570 bytes |   1.97       3.86      3.60   |
 | 1280x1012 col,   148387 bytes |   0.88       1.74      1.59   |
 |  804x1040 col,   306821 bytes |   0.89       1.56      1.46   |
 | 1024x 766 col,   244522 bytes |   0.84       1.54      1.41   |
 |  779x 767 col,   162752 bytes |   0.63       1.11      1.02   |
 |  779x 767 col p,  86016 bytes |   1.14       1.63      1.47   |
 |  450x 450 col,    50845 bytes |   0.25       0.48      0.41   |
 |  370x 502 col,    24480 bytes |   0.18       0.38      0.32   |
 |  506x1007 gry,    88115 bytes |   0.22       0.51      0.45   |
 |  761x 495 gry p,  68593 bytes |   0.38       0.61      0.54   |
 +-------------------------------+-------------------------------+
  (p = progressive)

The results for the MorphOS version are interesting.  It's actually on par
with the WarpOS version (above), and actually even faster in some cases,
especially with larger images.  It's also faster than the PowerUp version
of akJFIF running under PowerUp emulation in MorphOS, where it's at least
30% faster.  For smaller images, it's twice as fast, and for greyscale
images it can be upto 5 times faster than akJFIF!  No benchmarks for 68k
versions are included because they were found to be many times slower.

                                 +--------------------------+
                                 |@{bg fill}  @{fg shine}PowerPC only (no 68K)@{fg text}   @{bg back}|
                                 +--------------------------+
                                 |         MorphOS          |
                                 +----------+---------------+
                                 |          | akJFIF 44.112 |
                                 | WarpJPEG |               |
                                 |  44.25   |    PowerUp    |
                                 |          |   emulation   |
 +-------------------------------+----------+---------------+
 | 2008x1597 col,   225570 bytes |   1.54         2.03      |
 | 1280x1012 col,   148387 bytes |   0.74         1.01      |
 |  804x1040 col,   306821 bytes |   0.87         1.13      |
 | 1024x 766 col,   244522 bytes |   0.83         1.13      |
 |  779x 767 col,   162752 bytes |   0.60         0.82      |
 |  779x 767 col p,  86016 bytes |   0.77         1.05      |
 |  450x 450 col,    50845 bytes |   0.23         0.42      |
 |  370x 502 col,    24480 bytes |   0.15         0.34      |
 |  506x1007 gry,    88115 bytes |   0.23         1.14      |
 |  761x 495 gry p,  68593 bytes |   0.32         1.07      |
 +-------------------------------+--------------------------+
  (p = progressive)

The results for the 68k version are much tighter, although overall,
WarpJPEG comes out on top.  Not by that much, but faster nonetheless:

                                 +-----------------------------------+
                                 |@{bg fill}                @{fg shine}M68K@{fg text}               @{bg back}|
                                 +----------+--------+--------+------+
                                 | WarpJPEG | JFIFdt | akJFIF | OS   |
                                 |  44.25   |  44.7  | 44.112 | 3.9  |
 +-------------------------------+----------+--------+--------+------+
 | 2008x1597 col,   225570 bytes |   5.56      5.85     6.21    8.77 |
 | 1280x1012 col,   148387 bytes |   2.63      2.75     3.02    3.96 |
 |  804x1040 col,   306821 bytes |   3.28      3.34     3.65    3.50 |
 | 1024x 766 col,   244522 bytes |   3.09      3.19     3.47    3.31 |
 |  779x 767 col,   162752 bytes |   2.19      2.25     2.52    2.33 |
 |  779x 767 col p,  86016 bytes |   2.60      2.97     3.20    3.03 |
 |  450x 450 col,    50845 bytes |   0.72      0.73     0.90    0.76 |
 |  370x 502 col,    24480 bytes |   0.44      0.45     0.58    0.63 |
 |  506x1007 gry,    88115 bytes |   0.72      0.91     1.05    0.76 |
 |  761x 495 gry p,  68593 bytes |   1.00      1.14     1.28    1.05 |
 +-------------------------------+-----------------------------------+
  (p = progressive)

Note: all tests were performed, multiple times, using Visage, with the
following command line: "visage test.jpg nojpeg time test".

@{b}@{fg shine}@{bg shadow}WarpOS version still too slow!@{ub}@{fg text}@{bg back}

Despite these facts, I'm still disappointed with the relatively slow
performance advantage offered by my 603e over my 060 (approximately only
2-3 times faster). The main problem is that PPC datatypes still have to use
the 68k for reading the data from disk and for creating / writing to the
bitmap structures that the datatypes system requires.  As far as the former
goes, time lost for file i/o is negligable as WarpJPEG uses double buffered
asynchronous i/o (supports DMA controllers).

The largest bottleneck is that the DTM_WRITEPIXELARRAY method of the
picture.datatype has to be used to write the image data from WarpJPEG into
the image bitmap.  As this process is done via picture.datatype, it can
only currently be performed by the 68k.  To give you some idea of how much
of a problem this is for WarpJPEG, typically, half of the overall decode
time is used by the PPC to decode the whole image, and the other half is
used by DTM_WRITEPIXELARRAY on the 68k.  And that's on a graphics card -
the time used by DTM_WRITEPIXELARRAY will probably be even greater on
systems using native Amiga graphics. It doesn't take a genius to see that
this is slowing the datatype down, and is the main reason why WarpJPEG will
still be faster on a 060 than a 040.

@{b}@{fg shine}@{bg shadow}How to make the datatype faster@{ub}@{fg text}@{bg back}

Is there anything that can be done about this?  Well, yes, there are a few
patches that you can install which should make things faster:

 - NewWPA8 (util/boot/NewWPA8.lha on Aminet) should provide a notable
   speed increase on native Amiga graphics - probably won't make any
   difference if you use a graphics card.

 - If you use a graphics card and CyberGraphX, you may want to make
   sure you are using the supplied v43 picture.datatype, as this will
   be faster than the P96 and OS3.5/3.9 picture.datatype on your system.

Of course, any other general speed-up patches should help too.
@endnode

@node "Distribution" "Distribution Conditions"
WarpJPEG.datatype is public domain with the copyright remaining with the
@{"author" link "Author" 0} and may be freely distributed legally providing:

   (1) None of the distributed files are changed in any way
   (2) It is not sold for profit and it is not included on any disks
       that are sold solely for profit (includes magazine coverdisks)
   (3) The distribution contents remain complete (see list below)

If this software is to be sold for profit, permission must be obtained from
me, the @{"author" link "Author" 0}.

@{b}Aminet@{ub}, @{b}Amiga Format@{ub} and @{b}Amigactive@{ub} have been granted permission to
distribute WarpJPEG.datatype on their CDs.

The following files must be present in their original and unchanged form in
any copies of this software:

   Classes/Datatypes/WarpJPEG.datatype.020
   Classes/Datatypes/WarpJPEG.datatype.030.pch
   Classes/Datatypes/WarpJPEG.datatype.040.pch
   Classes/Datatypes/WarpJPEG.datatype.060.pch
   Classes/Datatypes/WarpJPEG.datatype.wos
   Classes/Datatypes/WarpJPEG.datatype.elf
   Devs/Datatypes/JPEG
   Devs/Datatypes/JPEG.info
   WarpJPEG.guide
   WarpJPEG.guide.info
   Install_WarpJPEG
   Install_WarpJPEG.info
   spatch
@endnode

@node "Disclaimer" "Disclaimer"
This software is provided "as is", without warranty of any kind, either
expressed or implied, statutory or otherwise. By using the archive and its
contents, you accept the entire risk as to its quality and performance.

Neither Oliver Roberts nor any other party involved in the creation,
production or delivery of the archive and its contents shall be liable for
any direct, indirect, special, consequential or incidental damages,
including without limitation damages for loss of profits, loss of use or
loss of anticipated costs, expenses or damages, and any data or information
which may be lost or rendered inaccurate, even if Oliver Roberts is advised
of the possibility of such damages.

@{b}Do not@{ub} attempt to tamper with the supplied files. Doing so will cause
problems and you may find things start going wrong!
@endnode

@node "Acknowledgements" "Acknowledgements"
This software is based in part on the work of the Independent JPEG Group,
using the libjpeg link library.

The WarpOS version was made possible by VBCC, which was used to build and
compile the datatype.  Thanks to Volker Barthelmann and Frank Wille, for
their support and help.

The Spanish installer translation is by Dámaso D. Estévez. The French
installer translation is by Philippe Bovier.

Thanks also to Sam Jordan for WarpOS and helping me out with various
queries regarding it.

Finally, thanks to the OS 3.5 development team - now everyone has access to
a 24-bit picture.datatype, I don't need to bother messing about adding
dithering routines :)
@endnode

@node "Future" "Support & the Future"
Some things that may appear in the future:

 - If I can squeeze any more speed out of the datatype, in general, I'll
   do so :)

If you have any other suggestions, please @{"let me know" link "Author" 0}.

Future releases of WarpJPEG.datatype will be available from either Aminet
(util/dtype/WarpJPEGdt.lha) or its webpage:

  http://www.nanunanu.org/~oliver/warpjpeg.html

If you would you like to know when WarpJPEG is next updated, then you may
want to subscribe to my announcement list to receive an e-mail informing
you of the changes as soon as a new versions of any of my products are
released.  To subscribe, send a blank e-mail to

  futaura-announce-subscribe@yahoogroups.com

or go to

  http://groups.yahoo.com/subscribe/futaura-announce
@endnode

@node "Author" "About the author"
If you have any problems with this software, or if you have any
suggestions/queries, please contact me and I will do my best to sort any
bugs out as soon as possible:

e-mail: oliver@futaura.co.uk
   www: http://www.nanunanu.org/~oliver/
   icq: 34640231
@endnode

@node "History" "Program History"
@{b}44.25@{ub} (19.10.2001)

 - Raised minimum WarpUp requirements from V4 to V5, due to cache flush
   bugs in V4 which cause images to be displayed incorrectly (black
   stripes, corrupt images or completely black images).  These bugs
   affected v44.24.  WarpUp V5 does not have these problems.
 - Cleaned up the WarpOS version, fixing some potential problems that
   could happen when an error occurred.
 - Minor code optimizations.
 - The installer now allows the destination of datatype files to be
   changed.

@{b}44.24@{ub} (24.9.2001)

 - Added support for files containing non-standard data, preceding the
   JFIF header.
 - WarpOS version reworked, now working in a fundamentally different way,
   to completely banish any possibility of cache conflicts - it also
   brings a speed increase of 2%.
 - Minor speedups for the 68k and MorphOS versions.
 - Fixed a bug which could cause a system deadlock if the dither control
   or pen precision options were enabled when using picture.datatype V44
   or higher.
 - Optimizations made to the dispatch engine.

@{b}44.23@{ub} (17.8.2001)

 - Added @{"greyscale output" link "Prefs" 92} mode option.
 - Fixed bug in memory manager, which could have caused crashes under
   certain low memory conditions.
 - Now supports the PDTA_GetNumPictures and PDTA_WhichPicture tags.
 - Discovered a bug in the CyberGraphX picture.datatype, concerning
   error numbers which would have resulted in an unknown error being
   reported by application software if bitmap allocation failed - added
   workaround.

@{b}44.22@{ub} (24.7.2001)

 - Added a workaround to the WarpOS version to stop the Exec memory list
   getting trashed if/when the datatype is flushed from memory, due to a
   bug in VBCC 0.8.
 - Added French strings to the installer.

@{b}44.21@{ub} (17.7.2001)

 - Fixed bug in the JPEG descriptor file, which caused some types of
   file not to be recognized.
 - Added support for various webcam images that weren't recognized before,
   including images from the NASA site.
 - Further optimizations to the memory management code.
 - PowerPC versions recompiled with VBCC 0.8.

@{b}44.20@{ub} (12.4.2001)

 - Improved YCCK to RGB colour conversion routine (Adobe images using
   the YCCK colour space should now look much closer to the original
   image).
 - Added RGB colour conversion support for Adobe images using the CMYK
   colour space.

@{b}44.19@{ub} (4.4.2001)

 - Added an optional 8-bit output mode for non-graphics card users, with a
   number of dithering and quality settings, which produces a much better
   image than the dithering method currently offered by picture.datatype.
 - Added options to control the precision/quality of pen allocations for
   when an image is displayed on a palette-based display (8-bit).
 - Added Spanish strings to the installer.

@{b}44.18@{ub} (15.3.2001)

 - Made @{"fast integer DCT method" link "Prefs" 0} available (approx 10% faster on 68k), and
   added a switch to toggle @{"fancy upsampling" link "Prefs" 0}.
 - Added preferences options to configure the OS3.5/3.9 @{"dithering control" link "Prefs" 0}
   feature.
 - Improved the memory management routines in all versions, bringing a
   small performance advantage for larger images on 68k (about 2% faster)
 - The 68k versions could crash if the JPEG stream was corrupt (bug
   introduced in v44.15) - fixed.

@{b}44.17@{ub} (19.2.2001)

 - The dithering disabler feature (for when the OS3.5/3.9 picture.datatype
   is in use on 15/16-bit displays) was flawed, since it only worked with
   images that were eventually attached to windows (e.g. Multiview). Now
   dithering will be disabled in all other cases too (e.g. Workbench /
   DOpus backdrops).

@{b}44.16@{ub} (12.1.2001)

 - Fixed a bug in the new startup code, which caused images not to be
   loaded in some cases - e.g. IPrefs failing to load WB backdrops.
 - The 68020-040 versions were completely broken in the previous release -
   forgot to rebuild one of the link libraries.
 - The 68k versions are faster again - moreorless back to the speed they
   were in 44.14.

@{b}44.15@{ub} (9.1.2001)

 - Recoded much of the startup code, with libraries now not being opened
   on the ramlib context (after advice from H&P)
 - Modified internal structure of the WarpOS version, to totally safeguard
   against cache conflicts (may have been causing rare random crashes)
 - All WarpOS benchmarks recomputed, since WarpOS V5 is a little bit
   faster than V4 (this datatype is upto 5% faster as a result)
 - Added benchmarks for MorphOS
 - Unfortunately, due to all the internal changes, the 68k version is now
   a little bit slower (only about 1%) than before

@{b}44.14@{ub} (7.9.2000)

 - 68k version is now a little bit faster (1-4% depending on the image).
 - Fixed bug in the previous release which caused all versions not to work
   with the P96 picture.datatype.

@{b}44.13@{ub} (2.9.2000)

 - Added a MorphOS native version and 68k version (in 020, 030, 040 and
   060 flavours) to accompany the original WarpOS version
 - Fixed bug which could case crashes under low memory conditions.

@{b}44.12@{ub} (2.8.2000)

 - Around 10% faster decoding of most images!
 - Recompiled with VBCC 0.7d beta, which gives a slight performance
   increase and smaller program binaries.
 - Tweaked compiler optimization options and increased disk i/o buffer for
   enhanced performance.
 - Improved the datafile descriptor file recognition code - it's faster
   now, and is able to detect more of the rarer types on JPEG file.
 - Recomputed all @{"benchmarks" link "Speed" 0}, to ensure correctness after a change in my
   test environment (test files are now on a different HD, due to a
   semi-fatal HD crash on the old partition).

@{b}44.11@{ub} (7.5.2000)

 - Made the descriptor less pedantic, so it will now match JFIF files
   starting with any standard marker type - i.e. less common,
   unidentifiable, types of JPEG file should now be recognized too.
 - Minor optimizations and code changes.

@{b}44.10@{ub} (5.3.2000)

 - Descriptor now recognizes JPEG's saved by Graphic Workshop for Windows.
 - Very minor code changes.

@{b}44.9@{ub} (8.2.2000)

 - Fixed a problem in the error cleanup code, which caused a PPC crash
   after decoding some corrupt JPEG files.

@{b}44.8@{ub} (4.2.2000)

 - Added support for images using the Adobe YCCK format.
 - Descriptor now recognizes Photoshop 3.0/5.2 JPEG file variations.

@{b}44.7@{ub} (22.1.2000)

 - Fixed possible deadlock case (caused everything to freeze/lock-up)
   which usually only occurred when lots of images were being decoded
   simultaneously.

@{b}44.6@{ub} (15.1.2000)

 - Rewrote parts of the descriptor code, so that it still works if
   other datatypes have messed with the current file position.  Should
   also be faster and more efficient.
 - Now able to decode EXIF thumbnail images.
 - Minor code changes.
 - The installer will now remove any JFIF descriptor files.

@{b}44.5@{ub} (9.1.2000)

 - When the OS3.5 picture.datatype is in use, dithering is now switched
   off (only) if the image is to be rendered to a 15/16-bit screen,
   resulting in much higher performance, with negligable quality loss.
 - Enhanced descriptor file to detect EXIF and Photoshop JPEG file
   variations.
 - Fixed bug in error handling.
 - Dispatcher now performs some extra functions, which may quash the
   stability problems that some users have experienced.

@{b}44.4@{ub} (5.1.2000)

 - Fixed silly bug new to v44.3 which caused a lot of images to be
   rendered with half the vertical resolution (i.e. every other line was
   left out and the rest were doubled), resulting in blocky images.
 - Ironically, fixing the above bug enabled the optimizations that I had
   originally intended: 30-50% faster for colour images, and around 100%
   faster for greyscale images!
 - Reverted to my simpler and less hungry asynchronous engine, as the
   new engine in 44.3 no longer offers an advantage with the above
   optimizations in place. [after release this was found to solve major
   stability problems that some users experienced with v44.3]
 - Corrected akJFIF WarpUp @{"benchmarks" link "Speed" 0}.

@{b}44.3@{ub} (3.1.2000)

 - At least 35% faster overall (upto 60% faster in many cases!), with
   no loss in the output image quality.
 - Enhanced descriptor file to detect more JPEG file formats.
 - Now uses asynchronous i/o routines which has made things a little bit
   faster overall, but will be most noticable on large (low compression)
   files and/or slower media.
 - Improved error handling.
 - Added @{"Speed" link "Speed" 0} section to this documentation.

@{b}44.2@{ub} (18.12.1999)

 - Now at least 10-25% faster (depending on the JPEG file) after
   optimizations and tweaking libjpeg settings.
 - Greyscale jpegs are now displayed if using the OS 3.5 or P96
   picture.datatype (only worked with the CGX one in v44.1).
 - Fixed little bug in the lib init (wasn't setting the revision number).

@{b}44.1@{ub} (15.12.1999)

 - Initial release.
@endnode

