Daniel and NOF-Digi list.
thanks for putting together the report on the thorny issue of File
sizes for Internet delivery. It makes interesting reading.
My time these days is rather tight and I don't really have the
opportunity to feed into what you guys are doing in NOF-Digi much, but
believe me I read the list with great interest.
These are a few thoughts on the content of the report and feedback that
you had from your email, I hope it encourages a little more discussion
from the list on these important topics. I am sorry it is so long, but
they are all rather favorite topics of mine.
If you find any of this interesting, please remember to take a look
at the TASI site at http://www.tasi.ac.uk where you will find some much
better material covering largely the same area.
**Quoted image resolution**
I am always a little worried when we start gauging the quality of
digital images by their 'dpi' (ppi would be more accurate - but I won't
start on that one). Using 'dpi' in this way is both misleading and
inaccurate. Folklore suggests that a screen resolution is 72dpi but
really this is neither here not there (in fact it's not even nearly
true on modern monitors....just measured mine and its 106dpi). The
only possible and reliable way of quantifying the size of an image is
by its pixel dimensions (as you rightly point out in section 1).
I know this can be hard to grasp so let me give an analogy....
If you asked me how much I weighed and I answered 2.8 pounds per square
inch, you would think that I was being less than helpful...but this is
precisely what we do when we quote an image's resolution in pixels per
inch. You have no way of working out how much I weigh unless you also
ask me...."Ed...how big are your feet?" Assessing the quality of
an image is exactly the same.....the ppi of an image only gives you an
indication of the quality of the image if we also know what the
physical size is of the original or the proposed output.
If I have an original which is 10inch long and I scan it twice, once at
300ppi and once at 100ppi, I will have two images; one 3000 pixels long
and the other 1000 pixels long. The quality will be identical, only
the size is different. The resolution is only of interest (or
relevance) in that scanning process. It provides no evidence of quality
(unless we also know size of the original). Once created the only
relevant figure is the size in pixels, and in this case one image
contains 3 times as much information as the other.
NEITHER HAVE ANY SIZE in inches, cms or any other unit of the real
world. You simply have two images......at 3000 and 1000 pixels long.
You only have to worry about their resolution when you want to output
them to some physical form in the 'real world'.
Or to put it the other way around.....the image provides information
that can either make a very high quality print (high dpi) at a small
size, or to provide a lower quality print (low dpi) at a bigger size.
Again quality can only be ascertained by knowing the size of the
output. If you share a large amount of information (3000 pix) over a
small space (5 in), the quality will be high (600ppi). If you share a
smaller image (1000 pix) over a larger space (20 in) the quality will
be low (50ppi) but in both cases the image is identical even though one
is 600ppi and the other 50ppi.
Gosh, I do hope this makes this all a little clearer, but if I had a
penny for every time I had heard:
"We have scanned everything to 'preservation' quality at 300dpi... but
I don't understand why the scanned slides are not as good quality as
the A3 prints..."
I have tried explaining this many times before and I apoligise if
despite the repetition I am still unable to explain it any better. Try
reading the link below for another attempt on the same material.
http://www.tasi.ac.uk/advice/creating/digitalimage.html
**Image sizes**
I think that section 1 covers all the points. The key thing when
working out any question of image size for any imaging project...is to
work from the other end....
How much information do you need to capture?
How big do you want to print the images and at what quality?
How much detail do you need to capture within the original to extract
the useful informational content?
If you can answer these questions, then you already know the answers.
If you decide that you will need to make A4 magazine quality images,
you can deduce that you need approx 25Mb or 3600 x 2400 pixels to
make them. The required resolution will be that figure which provides
you with that size of image.....and if you have differing size
originals, then it will vary dependent upon their size (as shown in the
"Gathering the Jewels" image parameters guide.....so again sorry....no
magic resolution figure.
If you want to provide the image for delivery on a monitor, then I
totally agree with your advice to provide something that fits into a
640 x 480 area, however do consider the issues of future
sustainability....the standard monitor size (dare I say resolution<G>)
is certainly going to grow and you will certainly need to deliver
larger images at a later date.
Of course the points you raise in Section 2 are of paramount
importance. You will simply find that some images, especially those
with small text, simply can not be shown in any useful way at these
small image sizes.
Actually this is interesting not just for print, some modern
paintings...and many watercolours simply have very little visual
information in them and can be understood and appreciated at
screen resolutions, whereas many 19th century engravings simply are not
readable at all, at sizes under 800 x 600 pixels.
Again there are no rules, only rigorous research, followed by setting
standards which are fit for the proposed purpose.
There will be as many different 'correct' image sizes as there are
different projects with different purposes.
**Compression **
A couple of points:
With JPEG compression (remember JPEG is the compression - JFIF the file
type) you will be able to vary your visual quality (and file size) from
'no visual difference' to 'small - but totally ruined' - it's your
choice. A few things to remember though, Some image types will
compress better than others, Watercolours will need a different amount
of compression to engravings....it's just the nature of the way JPEG
works. So test your image types with different amounts of
compression and then make a choice and stick to using the appropriate
amount of compression.
A general rule of thumb....over many thousand images....of all
types....is that if you compress all images to a point where they are
'just visually undiscernable from the originals' then on average this
should be approx 10% of the file size, but it will vary from 5% to 20%
(my guess - no evidence for this). You might well wish to compress
them more than this, at the cost of a lower image quality but it gives
you a starting point.
Someone pointed out that a 40% compression in one software is not the
same as another......it's tons worse than that! First these figures
are totally arbitrary, 40% does not mean you get a filesize 40% of the
original....just that you are 40% of the way up the scale. Secondly
watch out that some software gives figures for 'Quality' whilst others
for 'compression'........they are opposite values and again 40 quality
does not equal 60 compression.
Another thing that I would point out is that JPEG compression is done
by many proprietary algorithms.....(this is true for re-sizing also)
and that some simply do a much better job than others giving higher
quality files.....at smaller file sizes. On the whole I would say that
the algorithms used by Adobe are some of the best (I suspect there are
better) but others such as those used by ULEAD (the imaging engine used
in some image management systems for internal JPEG compression) are
certainly not as good. I have never compared Adobe to
Macromedia.....mmmm....nice little project for someone <G>.
The golden rule of all compression?
"Never JPEG a JPEG"
OK should be never JPEG a JFIF....but simply does not sound so good!
If there is any part of your workflow where a JFIF is being
JPEGed.....change it.....JPEG must only be used once and as the last
operation before delivery.
**Watermarking**
Very interesting section this! I was aware that watermarking increased
file-size, but not that it could add 100% size with text based
images....good point!
a couple of thoughts. I suspect that watermarking should really come
at the very very end of the image workflow. I know I always say "Do
everything......and then JPEG for delivery" but in this case I suspect
that JPEGing a watermarked file will simply undo the work done by the
watermark, leaving it possibly more visible....and also less durable.
For those who wish to keep to the most rigorous control over colour
quality...I suspect there could be real problems about watermarking
....and then JPEGing. I would need to do more research before being
too dogmatic about it though....just have worries...although I admit to
needing to have a good think on this one.....anybody else got any
thoughts?
I see that a few of the projects are going for a workflow where they
make some form of delivery master in a lossless compressed or
uncompressed form such as TIFF or PNG and use that to create delivery
images....with watermarking....on-the-fly....
Now that's the way to go!
Sorry this has been so very very long.....
If you think that you shouldn't really have the time to read
it.....mmmmm.....I know what you mean, because I certainly didn't have
the time to write it <G>.
cheers
eib
----------------------------------------------------------------------------
Ed I Bremner, QA-Focus/TASI Senior Technical Research Officer
Institute for Learning and Research Technology
University of Bristol, 8-10 Berkeley Square, Bristol, BS8 1HH
Tel: +44 (0)117 928 7170 Fax: +44 (0)117 928 7112
http://www.tasi.ac.uk/ A JISC Service
----------------------------------------------------------------------------
On Mon, 27 May 2002 13:55:44 +0100 Daniel Merriman
<[log in to unmask]> wrote:
> Hi,
>
> Well, I really didn't want to send the document to the whole list but I
> have been left with no choice due to high demand. Here goes...
>
> Apologies to those who do not require a copy.
>
> For those who are interested, please see attached.
>
> regards
>
> Dan.
>
> Daniel Merriman - Project Manager
>
> From Weaver to Web Project
> Calderdale MBC
> Reference Library
> Northgate House
> Halifax
> HX1 1UN
>
> 01422 392632
>
>
> *** SCANNED FOR VIRUSES ***
----------------------------------------------------------------------------
Ed I Bremner, QA-Focus/TASI Senior Technical Research Officer
Institute for Learning and Research Technology
University of Bristol, 8-10 Berkeley Square, Bristol, BS8 1HH
Tel: +44 (0)117 928 7170 Fax: +44 (0)117 928 7112
http://www.tasi.ac.uk/ A JISC Service
----------------------------------------------------------------------------
|
