"For Your Eyes Only" v2.05 User Guide
- Getting started
- The output settings
- The input settings
- The misc settings
- Understanding the pixel aspect
- The 16 and 32 bpp output settings
- The supported image formats
- Known bugs
- Contacts and credits
- Load the application by double-clicking on the !FYEO2 icon.
- Click the mouse to cancel the welcome box.
- Find a JPEG, Targa, GIF, BMP, or ppm file and either:
- double click on it if it is correctly filetyped.
- drag it on the FYEO2 icon on the iconbar, or on a FYEO2 window if you
don't know if the filetype is correct or not.
You stop the image processing at ANY time by clicking on the close icon of
Note that you cannot close an already loaded image window while you are
processing another image.
If you are processing a very large image, the desktop may appear 'jerky'.
This is because FYEO2 has a lot more work to do.
Finally, if you drag a "progressive" JPEG to FYEO2, then FYEO2 will attempt
to convert it using the "jpegtran" software (if you have it). This operation
does not multi-task, so FYEO2 will pop up a message on the screen and display
Settings boxes can be obtained with the FYEO2 iconbar "Preferences..." menu
item, or by clicking on the FYEO2 iconbar icon.
In each box you can:
- Validate settings for the next processed file by clicking OK.
- Validate settings for the next processed file AND save them as default
by clicking SAVE PREFERENCES.
- Cancel the change you've just made by clicking CANCEL.
- Set the default settings by clicking DEFAULT (you then have to click OK or
SAVE to validate them).
The output settings:
The output settings box offers you options to select the format of the output
You can choose:
- The bit-per-pixel value (8 = 256 col, 16=32K col, 32=16M cols).
There is no option for bpp values less than 8 (i.e. <256 colours).
[nerdy comment: I suspect '32bpp' should read '24bpp', but I'm going to
leave this alone until I've had time to check it]
- The pixel aspect: horizontal and vertical, in dots per inch.
In terms of screen mode:
8bpp 90x90dpi is mode 28 (VGA, 'square' pixels),
8bpp 90x45dpi is mode 15 (TV-res, 'rectangular' pixels)
8bpp 45x45dpi is mode 13 (TV-res, big-ass ugly 'square' pixels)
Selecting "Use current" means that the output sprite mode will be the
same mode as you are currently in, this is perhaps the most useful
- The colourspace: Colour or greyscale.
In tests, "greyscale" offered a speed boost of around 20% when viewing
larger JPEGs, this may be useful if you have a number of JPEGs to preview
and don't mind the previews being in monochrome.
Note that the JPEG decoder is American in origin, and the original FYEO2
was written by a French person; hence you will see American spellings
within FYEO2 ("colorspace", "color", "grayscale"). In this document I use
- The dithering type:
Dithering is a complicated process designed to increase the number of
colours that you 'perceive' in an image. It does this by blending nearby
colours to achieve the 'dithered' result. This is exactly the same idea
as used in publishing, where your daily newspaper is printed using cyan,
magenta, yellow, and black ink. If you look closely at the pictures on
the front page, you'll see thousands of dots of those four colours, all
carefully arranged to make it seem like a full colour picture.
This option is neither available nor required in 16bpp and 32bpp modes;
however it can greatly increase the quality of images converted to 8bpp
from a higher bpp original.
FYEO2 offers you three options:
- No dithering: quoted 'None' in the settings box.
This, as you can image, gives the poorest results.
- Simple dithering: quoted 'Simple'.
This is a simple and fast but coarse dithering aimed at image
previewing. It can offer a speed increase of up to 30% on JPEG
viewing. This dither method is characterised by visible dots of red,
green, and blue; often in 'wibbly lines'. Try it on the example and
you'll see what I mean.
- Floyd-Steinberg dithering: quoted 'Floyd-Steinberg'.
This is a much more accurate but slower dithering method, and is the
default dithering in FYEO2.
The way it works is by tracking 'errors' in the colour conversion
(which will happen if the desired colour is not available, there are
only 256 colours and the original image may use several thousand).
These 'errors' are then spread to adjacent pixels, and are then
'diffused' into the pixels. This allows for the limited number of
colours to be blended in ways that make it seem like more colours are
available. Now you know briefly how the technique works, you will
understand why it is sometimes referred to as "error diffusion". It is
called Floyd-Steinberg because two people (R.W.Floyd and L.Steinberg)
devised the method in the mid-'70s.
+ There are two other types of error diffusion that you may come across
in other software... The first is "Burkes", the latter is "Stucki". It
is said that "Stucki" gives the very best results (ironically, with
Floyd-Steinberg being the worst). When I tested it on my PC, the
results were pretty similar, except it took Stucki EIGHT times
longer to perform the dithering!
- The image scaling:
This is the way that the image will be reduced or magnified.
- 1:1 means that the image will not be scaled.
- 1:4 means that the image will be scaled to 1:4 1:4; i.e. a quarter of
its original size.
- 1:8 means that the image will be scaled to 1:8 1:8.
Selecting 1:8 enters the fast preview mode when viewing JPEG files.
- To fit means that if the image is too big to fit the specified size,
it will be automatically scaled in order to fit the whole image in the
specified size with the pixel aspect ratio preserved.
- To fill means that the image will be scaled automatically to fill the
the specified size, the pixel aspect is not preserved. I'm sure you
have seen what this looks like when walking into an electrical
hardware shop run by clueless people - with all the shiny widescreen
TVs incorrectly set up, so normal TV broadcasts appear 'stretched'.
- Custom allows you to customize the scaling with the specified values.
Please be aware that scaling costs a lot of memory when using 'complex'
fractions such as 640:639 480:479. Despite the fact that fraction
reduction is used you will get 'Not enough memory for scaling buffer'
often if you do it. This applies also to the implicit scaling generated
by the 'to fill' option. The 'to fit' option uses an approximation to
avoid this problem (so it may not fit exactly).
The input settings:
The input settings box allows you to select the format of the input image.
You can specify the image pixel aspect in dots per inch.
This is useful for images with rectangular pixels, use either 90x45 or 45x90
For the majority of images, 90x90 dpi is the correct value to use.
Please read the section "Understanding the pixel aspect" for more details.
The misc settings:
The misc settings box allows you to change the miscellaneous settings.
You can choose whether or not FYEO2 will 'auto filetype' the images that are
dragged to it. This can be useful if you are viewing a number of files that
you know are supported, but which have no filetype. An example is a floppy
disc containing images saved on a PC - for example how Microsoft Internet
Explorer saves the 'complete' HTML document. The images will invariably be
JPEG or GIF. Simply drag them to FYEO2 and let FYEO2 automatically set the
filetype of images that it recognises.
Understanding the pixel aspect:
The pixel aspect settings work as follows:
- The output dpi selects the way the wimp will scale the sprite:
- a 90x90 dpi sprite means that the wimp will not scale the sprite in a
'VGA' mode such as 21, 28... (90x90 modes) but it will reduce it by a
factor of 1:1 1:2 in the standard rectangular-pixel 'TV' modes such as
12, 15... (90x45 modes). Finally, it will reduce a 90x90 dpi sprite by
a factor of 1:2 1:2 in the square-pixel 'TV' mode, mode 13 (45x45 mode).
- a 90x45 dpi sprite means that the wimp will not scale the sprite
in a rectangular-pixel 'TV' mode (12, 15...).
- a 45x45 dpi sprite means that the wimp will not scale the sprite
in the square-pixel 'TV' mode (13).
- The input dpi selects the way FYEO will scale the original image to
match the original image pixel aspect:
- If the input dpi and the output dpi are equal, you will get all of the
original image pixels in the output sprite.
- If the input dpi is 90x45 and the output dpi is 90x90 you will have
twice as many pixels vertically in the output sprite.
- If the input dpi is 45x90 and the output dpi is 90x90 you will have
twice as many pixels horizontally in the output sprite.
- If the input dpi is 45x45 and the output dpi is 90x90 you will have
twice as many pixels both horizontally and vertically in the output
- If the input dpi is 90x90 and the output dpi is 45x45 you will have
half as many pixels both horizontally and vertically in the output
[and so on]
The best way to get to grips with how this works is to play with it!
The 16 and 32 bpp output settings:
When used on a computer capable of displaying the 'Deep' sprite modes (such
as a RiscPC or later machines), FYEO2 acts as usual.
When used on a computer which does not understand such modes, FYEO2 will warn
you (the warning can be disabled, see the !Run file) that it can't display
a picture that is being generated in 16 or 32bpp. FYEO2 is capable of
processing such an image on an older machine, the only things is, you cannot
see the processing occur). When the processing has finished (use the image
window title bar to see the process status), you can save the sprite as is
Because of this, you can convert images for use in software that can cope
with them, even if the operating system cannot cope with them 'natively'.
The supported image formats
(in alphabetical order)
Windows 'BMP' (BitMaP) files, widely used within the Windows platform.
Identified by first two bytes being "BM", or the filetype &69C.
* 1bpp (2 colours), uncompressed.
* 4bpp (16 colours), uncompressed. Current versions of FYEO2 may suffer
decoding problems with certain 4bpp images.
* 8bpp (256 colours), uncompressed.
* 24bpp (16 million colours), uncompressed.
The RLE4 and RLE8 compression methods are not supported, and at this time
it is not expected that they will be supported in the foreseeable future.
OS/2 BMP formats, version 1.x (short header) and 2.x (long header) are not
supported; however if you require support for one of these types, please
contact me. I may ask for a selection of (smallish) example images.
The BMP decoding is slow because the image is stored bottom-up, so it is
read line-by-line BACKWARDS through the file.
This approach was preferred to the alternative (buffering the file) as it
does not require space to store the entire image 'backwards' to then read
it out the right way around. So this BMP decoding is heavy on disc access
and light on memory.
Graphics Interchange Format - popular LZW compressed image type created by
Compuserve, and used on-line a LOT. More recently, notorious for legal
issues arising from the use of the format (as the Americans are stupid
enough to allow for 'algorythms' to be patentable). The PNG format was
introduced and touted as a replacement to GIF, but that never really came
about. Pretty much everybody still uses GIFs regardless...
Supports up to 256 colours, one of which may be transparent. FYEO2 does not
handle the transparency, it will typically set the pixel to a 'null' colour
which may be black but depends upon the GIF's palette.
GIFs may be 'interlaced'. This is supported by FYEO2.
GIFs may be 'animated' by storing several images (a secondary image could
be just a 'bit that changed' like in MPEG video compression; this depends
upon the quality of the software used to create the GIFs). This is NOT
supported by FYEO2. You'll see only the first image.
Recognised by "GIF" at the start of the file, or the filetype &695.
1 to 8 bpp; may be interlaced; may contain transparency information.
The Joint Photographic Experts Group (seriously, that's what JPEG means!)
have devised an image format that is properly known as JFIF, but most
people call it JPEG.
It can contain eight bits of monochromatic image data (256 grey shades),
or up to 24 bits of red, green, and blue data giving up to sixteen million
JPEGs are characterized by the ability to be compressed by varying degrees,
the lower the compression 'quality', the smaller the image file - but the
worse the picture may look. It is a 'smart' system where the compression
will try to lose data that you are unlikely to notice unless you look very
closely. It is for this reason alone that JPEG has made a huge impact
on-line, where an original image megabytes in size can be JPEGed to a mere
couple of hundred kilobytes as still look pretty much the same.
There are many different types of JPEG defined, however you are unlikely to
come across anything other than baseline ('normal') or progressive.
8bpp monochrome or 24bpp colour.
Identified by "JFIF" at offset +6, and by filetype &C85.
One of the limitations of JPEG is that it would build up the picture from
the top downwards. On-line, it may be preferred to 'see' the entire image
in a lower resolution as soon as possible, bettering it as more data
arrives. This is exactly what interlaced GIFs do. The solution was simple,
to interlace the JPEG data. However, while most RISC OS browsers can cope
with interlaced JPEGs, many programs cannot - including (for a significant
majority) the OS's own JPEG handling routines.
FYEO2 cannot deal with progressive JPEGs; it uses "jpegtran" to convert
such JPEGs to baseline form.
The way that FYEO2 copes with progressive JPEGs is as follows:
It will attempt to display the JPEG; but it will fail with the message
about an 'unknown SOF marker' that you may be used to. Instead of
reporting the error, FYEO2 will try to call "jpegtran" (this should be in
your Library directory, or elsewhere in your Run$Path).
If "jpegtran" is not found, or the conversion fails, you will receive an
If the conversion completes okay, the converted image (which is always
called "<Wimp$ScrapDir>._jpeg") will be inserted into FYEO2's queue. The
typical result of this is that FYEO2 will begin displaying the converted
If you drag a selection of progressive JPEGs to the FYEO2 iconbar, then
the conversion WILL fail and you'll end up looking at several copies of
the last image to be converted - this is because FYEO2 calls all of the
'converted' images the same thing, and then pushes that into the queue;
hence multiple copies of the last image to be converted!
A format mainly used on Unix. There are several types, greyscale ("PGM")
and colour ("PPM"); which may be encoded in binary form or text form. A
third type, black and white ("PBM") isn't supported.
8bpp monochrome or 24bpp colour, text or binary encoding.
Identified by "P2" or "P5" (mono) at start of file; "P3" or "P6" (colour)
at start of file; and by the filetype &69D.
To be honest, I don't know anything about Targa, except by looking at the
source code I can tell you the options are:
- Pixel order is BGR
- 8bpp greyscale
- 8bpp colour mapped
- 16bpp colour (3 x 5bit for RGB)
- 24bpp colour
- 32bit colour (BGRA), supported by ignoring the attribute byte
- looks like it may be able to be stored top-down or bottom-up
(needs lots more memory for supporting bottom-up format)
- may be interlaced, but FYEO2 does NOT support this
- may be RLE compressed
This format does not have a distinguishing ID in the header, so it seems
that Targa will be assumed only if the file is >18 bytes and has filetype
- If you open the iconbar menu, then the "Dithering" menu will behave like
the iconbar menu (which can be pretty weird to see). I think this is due to
a tiny difference between the RISC_OSLib that was originally used, and the
26/32 neutral one, which doesn't appear to export one of it's internal
variables that FYEO2 uses.
- The image decoding may screw up on 4bpp BMPs. Read "RickNotes" for an
explanation of what is going on.
- If you drag multiple "progressive" JPEGs to FYEO2, you will end up looking
at multiple views of the last one converted. This is not actually a bug,
it is a side effect of how FYEO2 handles "progressive" JPEGs. The solution
is simple - view them one at a time...
If you encounter any other behaviour that may be construed as a 'bug',
whether insignificantly tiny or the kind of bug that keeps little girls awake
at night fearful of the things lurking under the bed ... EMAIL ME!
Contacts and credits
FYEO2 was originally written by Frank Lyonnet. Also Frédéric Elisei.
It was later updated by Jérôme Mathevet.
Now, in 2004, I, Rick Murray, have taken on the task of updating FYEO2.
This program, pretty much, is a French creation (I live in France now). If
you are one of those poor pathetic sods that "hates the French", for
whatever reason... I just thought you should be aware of that.
I'll tell you what, also: the French girls are WAY cuter than the English
girls. It's not just a better dress sense, it's a whole different attitude
towards life. Sadly, none have asked me out (my appalling mangling of their
language might be an issue!), but there is always tomorrow... :-)
You can find the original v2.05 (including sources) at:
If you would like to email Jérôme (he speaks English a heck of a lot better
than I speak French), you will find his address on his website. The old
speedster-at-yahoo address doesn't appear to work, so time to update your
You can find details of my updates, and download the newer version(s),
Please note that sources are NOT available. I only get an hour per week on
the internet at a local library, so I'd be forever updating the sources and
stuff like that. Instead, I will only put up 'major' changes.
If, however, you would like a snapshot of the current source code of my
version of FYEO2, all you need to do is ask.
Important: I don't run a version control system, so please don't ask for
any specific version, the only one I have (aside from backups)
is the latest version, okay?
If you would like to email me, you can send email to:
[ ... omitted - refer to the image on the FYEO2 index page ... ]
Oh, and yes I know the email address given on the website is different,
either will do - just PLEASE do not quote my email address in any public
forum (news, mailing list, etc) for ANY reason, no matter how justified it
may seem. I am no longer able to access my heyrick mailbox for the sheer
weight of pointless spam that has been sent my way.
If I find anybody has posted my email address publically, I will find out
their email address and make sure the spam engines have it, then I will
close the email account affected, and post a message stating such on my
website. It won't inconvenience me much, as personal important mail goes to
a completely different account all together. It will cause very degrees of
inconvenience to others. And yes, you may consider that a threat, if you
happen to be so inclined to post people's email addresses without thinking
of the consequences...
- Thanks, obviously, to: Frank Lyonnet, Frédéric Elisei, and Jérôme Mathevet.
- Thanks to Tony Blair for sucking up to America's delusional vision of a
better world through terrorism-but-it-is-okay-cos-we-are-the-good-guys. If
ever I needed a reason to despise how England is managed, there it is!
- Thank you to George Bush for giving me the impetus to learn rude words in
French, so that I may fully express myself in describing "quel putain
branleur" he is. Given how the French pronounce things, I do however wonder
how newsreaders can talk about Mr. Putin (you know, the guy running
Russia!) with a straight face...
- Thank you to John and Irene, for the baked beans. For all the French are
good at cooking, their beans taste so unlike beans should that it is as if
you are not even eating beans!
- Thank you to Alyson Hannigan, simply for being.
- Thank you to Joss Whedon, for creating something amazing.
- Thank you for mom for paying for the electricity that I use to sit here and
write this rubbish...
- Thank you to CNBC for showing Jay Leno and Conan O'Brien on weekends. It's
the only English programmes I can get. Okay, I can get ALL of CNBC and also
CNN, but 24 hours of non-stop CNN may make you want to kill yourself!
- Thank you to Germany for not being cheapskates. I don't speak more than
about ten words of German ("Ich liebe dich" makes three...), but I quite
enjoy watching Medicopter 117. Also, MTV and Viva. All broadcast 'in the
clear' because the Germans don't whinge incessantly about "licences" for
broadcasting stuff that people outside of Germany may watch. Unlike many
of the UK channels that are locked up tighter than a nun's... <cough> you
get the point. :-)
- Thank you to Microsoft for being perverse buggers... is there any actual
reason why BMPs are stored bottom-up, or did you just do it like that
because everybody else was doing it top-down?
- Thank you to Laura Pausini for making me in the mood to cook my favourite
meal - pasta. No, I don't speak Italian either.
- Thank you to Sara (sarasari) for introducing me to Niccolo Fabi, and taking
the time to translate some of it.
- Thank you to MTV Germany for using subtitles for a lot of US imports (The
Osbournes, Scare Tactics, Jackass, etc) instead of dubbing. That way, I can
watch the programme and listen to the (english language) sound.
- Thank you to Evanescence for an amazing debut album. One of the few in my
collection that I can stick on repeat play and not feel like throwing in
the bin after the fifth time around...
- Thank you to Acorn for RISC OS and the ARM processor. Also, to Sophie
Wilson for ChangeFSI - ever useful.
- Thank you to CJE for the RiscPC on the "Programmer's RiscPC" scheme.
Hey - I caught you out Chris, you did NOT have that teletext adaptor I asked
about in stock. You know, the Acorn one for the BBC with the four blue
twiddly-bits on the back for tuning. To your credit though, I don't think
anybody has actually seen one since about 1986... :-)
- And finally, something French... Thank you to Alizée for being adorable, if
much too young for me. (then again, look who Calista Flockhart married!)
Malheureusement, j'ai pas vingt ans aussi. J'ai trente ans. Aiyaiyai...
Or "FIN" if we're going to be like a trendy 'New Wave' film...
...but then again, if you've never heard of François Truffaut or Louis
Malle, perhaps you'd miss the certain irony here... ahhh, la dolce vita... :-)
Return to FYEO2 index
Copyright © 2004 Richard Murray