home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Fujiology Archive
/
fujiology_archive_v1_0.iso
/
!FALCON
/
!BONUS
/
GFX
/
JPEG2_20.ZIP
/
JPEGV220.TXT
< prev
next >
Wrap
Text File
|
1994-02-27
|
19KB
|
432 lines
The V11 JFIF viewer
for the Atari Falcon
030-only version 2.18, 9/1/94.
By David R. Oldcorn of Volume 11 Software Development
All Falcon-specific parts copyright 1993-1994 Volume 11 Software/DR Oldcorn
Based on the JFIF C conversion software originally by the
Independent JPEG Group.
DSP56001 code and interface written 23/7/93 - 28/7/93
(not included)
GIF and Graphics Interchange Format are trademarks of Compuserve, Inc.
Usage:
About the easiest setup is to set it on a function key and as a
JPG extension triggered system, so double-clicking a JPG file will
show it onscreen, and an F-key will bring up the viewer.
Once it is running in viewer mode the controls are as follows:
File selection screen:
A-Z: select drive to be displayed.
Cursors: move file cursor
RETURN: show file / enter subdirectory
BACKSPACE: exit subdirectory
*: show info on current file
Esc: exit to desktop
Space: mark file for slideshow
Tab: start slideshow (show all if no files selected)
Shift+Tab: Timed slideshow (adjustable from options screen)
Ctrl+Tab: continuous slideshow (as above but doesn't pause)
Insert: switch to preferences screen
Help: show keylist & program info
Delete: delete currently selected file... will prompt!
#: rename currently selected file. Be careful what you change it to!
0-9: start JFIF compaction at a preset quality setting
(see HELP screen in program for list)
In display mode:
Cursors: move screen
Esc: exit now
Return: exit / next slideshow file
Space: halfsize picture
Backspace: switch interlaced frame alternacy (not enormously useful, but
there to show up an unusual problem with interlace on a friend's
TV).
Tab: Stop displaying picture and show decompression timings.
On preferences screen:
Cursors: move cursor / alter contrast settings
Space: change status
Shift+Curs: +- 10 to contrast settings
Return/Esc/Insert: exit
The 030 version is entirely public domain, and you are free to distribute
it as much as you like AS LONG AS it and this file are NOT ALTERED in
ANY way, and that it is always accompanied by this instructions file.
The full DSP version of this software is available for £5 from:
Volume 11 Software Development,
PO Box 311,
Broughton
Preston
PR3 5DZ
(England)
All monies should be made payable to D. Oldcorn.
I can only check the box every 2-3 weeks, so there may be a bit of a
delay if you're unlucky (i.e. it gets there a couple of days after I
last checked it). Once I have your letter I will try to get the thing
sent back within a week, spare time permitting! If I'm just about to
release a new version with major improvements, I may also hold things
back for a few days - until it's ready.
Note that the DSP version is not at all public domain in any way, shape
or form and may not be copied for distribution.
I can be contacted until at least September 1994 on email at:
oldcornd@cs.man.ac.uk
If you have an email account, and want the DSP version, then I can send
it to you by email if you want - it's quicker for you, and cheaper for me!
All feedback, suggestions and comments welcome.
Disclaimer (just in case anything goes wrong I am not responsible):
This software will not necessarily perform to the specifications
set out below due to unforseen problems, and you take all the
blame for anything that goes wrong when you try to use it. If
this idea disturbs you, please do not attempt to use this software.
GENERAL NOTES
All pictures are displayed in Falcon 16-bit Truecolour.
Even the ST formats (Degas etc.) are run in TC mode, so all the halfsize
features still work. Halfsize during read is only available on JPEGs.
Working memory is: size of file buffer + about 50K + about 100K(DSP) +
size of selected image buffer
The file buffer is 8K for Targa and JPEG with continuous read on, and
the file size for everything else.
For VERY large pictures operating in hardware scroll mode can require
around 2.5-3 Megs due to the very large final image.
Memory available to the program is the size of the biggest UNFRAGMENTED
free block in the TOS memory space. This does NOT include the default
screen (the desktop / select screen) so running the viewer from high
colour or large desktop screens will reduce the amount of memory available.
Best mode for memory is 640x200 2 colour. Running the viewer after
other programs can result in it having surprisingly little memory,
as main memory can become fragmented.
If you get an 'out of memory' error, set a lower res video mode,
turn hardware scroll off and probably set halfsize on - this will
limit the screen size by not allocating memory for areas outside
the left and right of the visible screen area (it WILL still allocate
for VERTICAL scroll but if halfsize is on this is unlikely to be
necessary).
It has displayed JPEGs as big as 640x2500 and 1700x1700 (halfsized)
on my 4 Meg machine.
In slideshow mode, remember it has to hold TWO pictures in memory at
once... so you won't be able to show very big pictures one after
another without running out of memory. That said, if you're running
it in a clear Falcon with just the Control Panel installed, you
should have about 3.8 megs free, so the pics will have to be big to
cause problems.
Things can get a bit messy if it runs out of memory in slideshow mode,
as attempts to report this fact will usually go unnoticed. It will
generally sit and ping a lot!
Due to a slightly unhinged design flaw in the Falcon video XBIOS
(which was always present on the ST too, but because direct hardware
accesses were OK you could get round it) the screen resolution can't
be changed without clearing the screen (to white, of all things) which
1) leads to the flicker when an image starts loading and 2) leads to
flickering and unusual output when the slideshow swaps an image,
especially if it has to change resolutions
VGA mode is limited to 320x240 because the Falcon doesn't support
640-wide screen modes in VGA Truecolour. The hardware scroll and
halfsize are still OK so you WILL be able to see a full picture.
Full PAL height uses direct access to the video hardware to remove the
top and bottom borders produced when using overscan on a PAL (50Hz)
TV or monitor, this may not work on later versions of the hardware.
When you select this mode your monitor may do something strange, if
it does don't use it (on 4 different TV's and 2 different monitors
there haven't been any problems so far).
This produces the maximum 600 data lines, although you'll probably need
a vertical resize to see the top 30 and bottom 10 of these.
The STe hardware scroll registers are also used for pictures which
are wider than the screen. These should be valid on all Falcons, but
an option is given to disable horizontal scrolling, in which case the
hardware register will not be accessed, and the extra memory required
for the screen will not be allocated.
All hardware accesses can be optionally disabled, which will prevent
any possibility of any illegal hardware access.
It pings when it's finished loading whatever it's loading
It's not MultiTOS compatible but it is quite legal in terms of memory
usage and management. Running this under MultiTOS would be completely
pointless. (As far as I can tell, the incompatibility is caused by
changing screen res + direct screen access: although this program
could manage without res changes, if it used the VDI it'd take weeks...
currently plotting one pixel takes 9 instructions in YCrCb...)
If a slideshow is begun with no selected files, it will run every file
in the current directory. Holding SHIFT when slideshow is activated will
cause it to run without pauses. If no files are being written, the
slideshow will run in a continuous loop.
It has a file buffering system for JPEGs and Targas that will reduce
memory allocation. By default this only operates in info mode or
from hard drive, as it slows down the system massively when reading
from floppy, but this can be adjusted from the options screen.
Rename does basic checking how valid the filename you pass back is but
it will let TOS do whatever it wants with your filename. Changing the
extension is usually a bad idea.
GENERAL NOTES ON JFIF CONVERTER.
Current version implements a subset of JFIF.
BUT most standard JFIF's will certainly be supported.
It will only handle images in YCrCb and greyscale (the only two
logical colourspaces for general use).
Noninterleaved scans are not supported, if I ever see one it will be.
Non-integral upsampling ratios are not supported.
This should cover the vast majority of JFIF files.
(This covers ALL the JPEGs I have encountered, and all
which can be created using the Independent JPEG group's CJPEG software).
It is recommended that ALL stored JPEGS should be 2x2 1x1 1x1, the
software is most efficient at these sampling ratios.
Error checking is performed, and faulty files will halt
the decompacter or produce garbage. Resyncing is NOT guaranteed
even if restart markers are included, but in most cases some kind of
resync should be possible.
Halfsize reduction is performed by a supersampled zoom at the
upsampling stage (only approximately if you are using non-1x1/2x2
ratios, but this should be fairly rare).
NOTES ON DSP CODE:
The DSP version is slightly more limited than the plain vanilla
030 version, due to the limited memory available to the DSP and the
logistics involved in programming a fast, efficient DSP version. As
a result, some JPEGs will have be processed by the 030 entropy decode
rather than the DSP, which will be slower - anything with restart
markers will have to be done on the 030, and anything with silly
sampling ratios (CrCb ratios must be 1x1 1x1 to be OK, and Y must
be 1x1, 2x2, 2x1 or 1x2).
The DSP version completely ignores any detected errors in the input
file (e.g. corruption leading to invalid Huffman table entries being
referenced). If you suspect this, run the 030 entropy decode, which
will produce an error message if there is a problem.
On average it runs about 4 to 5 times faster than a pure 030 scan.
If a full DSP scan can't be done, and the DSP is available, it will
use DSP iDCT and 030 Huffman, which will run about half of full DSP
speed. 030 mode will also be selected if the DSP has been locked
out for any reason. If things seem unusually slow this is probably
the reason!
Other DSP programs should run OK after the JPEG process has terminated.
NOTES ON GIF CONVERTER
If no colour map is present it will do something silly.
It's bloody slow, but that's LZW for you.
FILE WRITE MODE
The viewer is capable of writing an output file whilst displaying
some of the available formats (JFIF and Targa). The output format
can be either JFIF or Targa (uncompressed 24 bit or 8 bit greyscale).
When it writes, it will write a new file whose name is the same as
the old one except for an appropriate extension change. If this file
already exists it will attempt to find a unique filename by tagging A's
onto the name or by moving the last letter of the filename up one (if
all 36 last letters A-Z and 0-9 are used it will not write). I
particularly do not guarantee that this is 100% working, and any
files deleted by accident are your problem. It hasn't ever happened
to me but I never trust these things.
After every write it will RESET the write status to no write... it has
been found mostly by mistake that this is by far the best option!
If an error occurs the program may do one of three things:
1. Ignore it and carry on, probably producing a corrupted image
2. Halt the write process, closing the file, reporting the error
3. Go Bye Bye (unlikely)
If (Esc) is pressed during write, the file will be closed and
will be incomplete.
NOTES ON JFIF COMPRESSOR
For notes on use of JPEG compression, see the accompanying file
JPEG.TXT. These notes are concerned mostly with the implementation.
The compressor implemented is a standard JPEG compression, with
full quality setting (1-100, as CJPEG) and Huffman coefficient
optimisation, which will reduce the size of the compressed file by
about 5-10% (it is especially efficient on small files). Using the
optimiser will only add a few seconds to the compression time, but
more memory will be required. Sample ratios are fixed at 2x2 1x1 1x1
(YCrCb) and 1x1 (greyscale).
Memory usage can be large, at least 100k or so, and it will attempt
to use as much memory as possible, to reduce time in disk access. This
is especially useful during optimisation, where it will attempt to use
memory if possible, but otherwise will use a (VERY large) temporary
file on disk called TMPFILE$.$$$. This will be about 900Kish for
640x480. If it runs out of space things may be a little confused, but
hopefully it will close everything and delete the temp file. BE WARNED
users of AHDI before 6.06, filling a drive can sometimes result in the
loss of boot sector on the next logical drive, which can be very
difficult to recover, so be careful about using compression on nearly
full drives. If you have AHDI 6.06 or later, this bug has been fixed,
so you don't need to worry.
Known bugs:
If really badly out of memory can crash quite heavily
History:
2.20: Switched to DSP code v3.00, and heavily modified DSP communication
code to fix it to handle the new DSP operating modes. New version not
quite as much an improvement as I'd hoped but still put speed up
by around 20%. Improved upsampler a bit to knock 25% off time for
2x1 pictures. Added time taken report.
2.19: VGA fixed. Some mouse routines added - scroll pic by mouse. File
rename available. Fixed a small but obscure bug that was making
pics with non-multiple-of-8 widths sometimes complain, and one to
do with hotkey write. Support for interlaced GIF's added (untested).
Timed slideshow added.
2.18: Error handling actually reports something useful. Added
report of JFIF optimisation to info. Force a greyscale write added.
Delete file option added. A lot of little things fixed. A couple of
big ones too. Handler for more than 80 files. JFIF greyscale force
added.
2.17: JFIF write while decomp (oooh, doesn't it sound simple - this
added 50K to the source and 5K to the object). Some small bugs fixed,
vskip locked to valid values, and a rare but extremely dangerous
out-of-memory crash when switching res prevented, I hope! Fixed Targa
cutdown so it actually works!
2.16: Targa write while decomp, if wanted, plus Targa read, greyscale
and 24-bit RGB only, will do more when I can get some more example
Targa files. Targas run through new buffered memory system to massively
and essentially remove memory overhead. JPEGs now do too. This may be
a bit slow on write-and-decomp. Options handler made a bit less
obfuscate, and speeded up quite a bit. Entire output handler moved over
to a more flexible format ready for JPEG compacter to be introduced.
Changed PAL600... it's now a bit of a misnomer cos it's now only about
590 lines....
2.15: Rebuild to modular version started. Memory overhead dropped by
changes to huff handlers, which also fixed a restart marker problem.
Added quality factor to JPEG info. Changed the restart marker processor
slightly so if it finds errors it at least TRIES to carry on.
2.14: Save preferences, and switch to assemble 030-only version. File
sizes now shown. GIF bugs fixed. PAL600 fixed for TV's that have fiddly
syncpulse requirements. Screen scroll system fixed properly. DSP lock
and error detection now reported to options screen. Upsampler reworked
to allow halfsizing of all JPEG's. Halfsize bug fixed. Enabled a key
to swap frame alternacy to occasionally improve display of some JPEGs.
Contrast expansion added. Went over to DSP code 2.02 to fix a bug
if the first image loaded was greyscale.
2.13: Added other file format handling: Degas, Spectrum 512 (you
won't BELIEVE how much fiddling this routine's been through, since
I had to manually tune it - and a stupid bug didn't help!). Fixed memory
allocate to only allocate on 4-byte boundaries beacuse otherwise
the video system complains.
2.12: Fixed a series of bugs in MCU transform and upsampler to get more
sampling ratios working properly. Improved GIF converter a bit. Added
SOF1 marker to let low-quality sampled images work properly. Added
'slideshow all' mode if no files are marked. Switched over to 16-bit
Truecolour, but can't see the difference, so I dunno whether it works!
2.11: Fixed PAL600 bug caused by manky video programming. Introduced
Info. Introduced source history. Which is why it doesn't go too far back!
2.10: Added slideshow mode, including view-and-decompress any pic,
including major rewrites to all the video code. Code rearranged into
logical sections (select/view & scan, JPEG, GIF).
Added no-hardware access mode. Fixed some minor bugs with selector.
Rewrote DSP output transform to fix some more sample ratios for DSP.
2.09: Rewrote upsampler for more than just 2x2/1x1 sample ratios.
Went over to DSP code 2.01, and rewrote IDCT-on-DSP output transform
accordingly. Moved big non-initialised data to BSS segment.
DSP code history:
3.00: Complete rewrite of iDCT to accelerate matters. Added DSP
upsampling and colour conversion routines too. Improved
Huffman code as well.
2.03: Some speedups made in iDCT
2.02: Fixed bug to force greyscale images to work OK
2.01: All coefficient output converted to be range-limited. Some speed
modifications made.
2.00: Huffman/IDCT on DSP.
1.00: IDCT on DSP.
Rough Execution times for 640x480 colour JPEG:
030 version: 18 seconds
DSP version: 4 seconds
Currently supported file formats:
JPG - JPEG File Interchange Format
GIF - CompuServe GIF (TM)
PI? - DEGAS uncompressed
PC? - DEGAS compressed
SPC - Spectrum 512 compressed
TGA - Targa, 24-bit colour and 8-bit greyscale uncompressed only
Currently written file formats:
JPG - JPEG File Interchange Format
TGA - Targa
Regular updates should be available - when I either think of new ideas,
or manage to find a new JPEG it won't handle!
Coming soon: Starball, an ST / Falcon Pinball game, which is completely
awesome, in every respect. Falcon features include 50 frames per second
operation and stereo soundtracker sound. Even on the ST it'll blow your
socks off. Believe it!
ə