I know that I cannot affect other people's set-ups, the brightness or
contrast settings on their monitors, but I would like to know whether I
can do anything here to optimise what I send out.
I have looked at my pages on four different set-ups (completely
different monitors and video cards) and with two different browsers, IE4
and NS4 and the pictures look fine. To me they look true to real life.
I had been badgering a couple of friends, who said everything looked
fine, to give me a proper critique and one eventually said that one
picture was so dark that he couldn't see it properly and it was very
ill-defined. Although that was a little depressing I would rather know
and try to find out what was wrong and how to correct it than carry on
oblivious. He told me that another picture was not as sharp as it could
be and I have re-done that one and think it is better. I am stuck when
someone says things are too dark overall when they look OK here.
What can I do at this end to improve the rendering of graphics on
someone else's machine? Do you have any advice?
If it helps, the photograph that someone couldn't see properly, and
where the foreground and background merged, is at:
http://www.howfen.demon.co.uk/bobbins.html
I know it isn't the best photograph in the world but it looks clear
enough to me.
I've looked at the Jpeg FAQ and am trying to understand compression but
I don't know whether I am choosing the right options. I use PSP5. I'm
responsible for many hits on atomor.demon.co.uk and have been lurking
here for quite a while. I have searched dejanews but I couldn't find
the right questions to ask to narrow the search down.
I would be very grateful for any advice you have.
--
Glenys
>>I had been badgering a couple of friends, who said everything looked
>>fine, to give me a proper critique and one eventually said that one
>>picture was so dark that he couldn't see it properly and it was very
>>ill-defined.
>[]
>Do you use a PC and your friend a MAC? I recall that the gammas and
>palettes are different, so any picture that looks OK on a PC may well
>look lousy on a MAC (and no doubt conversely)
No, that's the strange thing. Both Pentium IIs with similar specs,
except that I have a 15" monitor and he a 17". We live too far apart
for me to see what is going on.
It made me wonder whether there were some guidelines for making sure
that the colours here would come out more or less the same elsewhere, in
the same way that I have seen discussion on making pages viewable at
different resolutions.
--
Glenys
Not really in this case.. image formats don't typically contain 'gamma
correction' settings (which typically differentiates how dark/bleached an
image will appear from one machine to the next), so the fact they come out
different is really just an issue of the hardware being used - and as Andy
says, this will usually manifest itself between different types of
computers, but it isn't the only cause.
FWIW, I thought the image(s) looked fine. I would be inclined to think that
either the monitor brightness and/or the gamma settings of the video card
are to blame for the image appearing so dark - both of which are largely out
of your control (you could try increasing the gamma in the image in PSP as
much as you feel is still acceptable on your machine, and see if it is ok
for this visitor, but there is little else I could think you could do).
Regards,
Nick
Is he using "Large Fonts"? I've seen that make a mess of images before
now. It shouldn't affect the colours, but if might affect image
definition.
David Wright "Language shapes the way we think,
Elgol,Isle of Skye,Scotland and determines what we can think about."
dwr...@ealaghol.demon.co.uk - B.L Whorf
http://www.ealaghol.demon.co.uk/
... or even just a different flavour of operating system? When I moved
up from Win3.1 to Win95 I found quite noticeable differences of colour
rendering on the same computer and monitor.
--
E. J. Jewell <mailto:eje...@chy-an-piran.demon.co.uk>
<URL:http://www.chy-an-piran.demon.co.uk/>
I appreciate your comments and those of the others who have responded.
I will see what I can learn about gamma correction which doesn't mean a
lot to me at the moment.
>FWIW, I thought the image(s) looked fine. I would be inclined to think that
>either the monitor brightness and/or the gamma settings of the video card
>are to blame for the image appearing so dark - both of which are largely out
>of your control (you could try increasing the gamma in the image in PSP as
>much as you feel is still acceptable on your machine, and see if it is ok
>for this visitor, but there is little else I could think you could do).
Thank you for taking a look. I'll do some experiments and get my friend
to see how they appear on his machine. I thought I had achieved all I
needed when I got the filesize, and therefore the page, to within the
suggested limits and it looked OK here but I have clearly got a lot more
to learn about graphics.
--
Glenys
Not as far as I know. We have been talking about font sizes and screen
resolutions recently and I believe we use the same, but I will pursue
your suggestion. It will continue to niggle at me until I find an
explanation for what is happening and a solution :)
--
Glenys
>We have been talking about font sizes and screen
>resolutions recently and I believe we use the same, but I will pursue
>your suggestion. It will continue to niggle at me until I find an
>explanation for what is happening and a solution :)
Are you both using the same colour palette (Control Panel, Display,
Settings) ?
--
Paul Terry
Just to clarify, I am referring to the value in Control Panel / Display
/ Settings / Font Size. This is quite separate from setting say Times
Roman 20pt as your standard font in the Browser. "Large Fonts" in this
context effectively adds an extra 25% to screen fonts as they are
displayed. The problem I saw was with images in a help file; they were
also being expanded and if you have ever tried expanding a bitmap image
you will know that it can cause loss of definition.
Tom
--
Tom Tweedy
Dalmatian Telegraph
http://www.lancedal.demon.co.uk
Sorry it has taken a few days to reply.
>Just to clarify, I am referring to the value in Control Panel / Display
>/ Settings / Font Size. This is quite separate from setting say Times
>Roman 20pt as your standard font in the Browser. "Large Fonts" in this
>context effectively adds an extra 25% to screen fonts as they are
>displayed. The problem I saw was with images in a help file; they were
>also being expanded and if you have ever tried expanding a bitmap image
>you will know that it can cause loss of definition.
I understand what you are saying and we are talking about the same
thing. My friend and I both use 800x600 screen resolution and with
small fonts as our basic Windows settings.
--
Glenys
I have asked and he is on 256 colour. I am on High Color 16 bit. Both
on 800x600 small fonts.
--
Glenys
Thank you for those comments. It does look at the moment as though the
simplest explanation is the most likely one and that it is something to
do with the combination of hardware and software on my friend's machine
and his brightness and contrast settings.
I persuaded him to hike up the brightness on his machine when in IE5 and
he reports that the problem picture suddenly came into relief and the
definition between the foreground and background became obvious. If he
keeps that same setting for his other applications, however, everything
seems completely washed out. I've found a slight difference here
looking at my pages through NS4.5 and IE4 but nothing so marked.
It has been a very useful exercise for me to experiment and thank you
everyone for your help.
--
Glenys
>I have asked and he is on 256 colour. I am on High Color 16 bit.
I think that is most likely to be the reason for the different hues that
the two of you see, especially since the picture concerned is a jpeg -
his system will be making a very large number of approximations for the
colours that it cannot render exactly.
Try reducing your own colour depth to 256 colours and see what you get
(this usually means rebooting Windows, although the MS Power Tool Quick
Res will allow you to change colour depth without rebooting).
--
Paul Terry
This is the reason that some recommend sticking to the browser-safe
colour palette - though I personally don't do so.
--
Tony Morgan e-mail: to...@atomor.demon.co.uk
Atomor Web Limited
Web by design
It makes no noticeable difference on my machine, but it makes sense that
this has something to do with it.
I may not be helping things by the way I saved the jpeg, probably
because I am on a steep learning curve and am still not entirely sure
what I am doing. I know about jpeg being a lossy format and I think I
remembered always to work on a copy of the original but this was the
first time I had used a digital camera and was still getting used to the
whole thing.
I used PSP5 and because I was obsessed about getting the filesize down I
reduced it to 256 colours. The Standard Option produced a poor result
that was quite blotchy, but I found if I chose Optimized Median Cut,
Nearest Color, it was better. When I came to save it, however, I got
the message "Because of the requirements of the specified file format,
the saved file will have a bit depth of 24 (16.7 million colors). Would
you like to continue?" When I said yes to that the picture showed up as
840K in PSP, but as 60K in Explorer. The image information says that it
is in 24 bit colour, but it certainly doesn't download like an 840K
file.
I couldn't find any information on the different formats so I ignored
the fact that I couldn't understand what was going on because it looked
fine to me. Perhaps using something other than the standard setting
compounded the difficulty that my friend's 256 colour has in rendering
it accurately.
Thanks for the suggestion.
--
Glenys
I know I could use the safety palette for creating a picture from
scratch but I am not sure how it would help with an existing photograph
that won't render properly with that palette. Am I missing something?
What you say has reminded me that I got the same friend to beta-test the
first couple of pages when I had finished them. I chose #FFFFE0 as the
background but he reported that it looked a washed-out parchment which
was not what it was supposed to be at all. I assumed that was because
it wasn't a browser-safe colour, which is why I went to #FFFFCC. It now
looks as though that was only part of the story, if it was relevant at
all. I might consider being hung for a sheep as well as a lamb and go
for the colour I really wanted after all :)
--
Glenys
Quite honestly, it's bad enough worrying about catering for all display
resolutions and browsers/variants without adding the complications of
colour palettes.
>>I used PSP5 and because I was obsessed about getting the filesize down I
>>reduced it to 256 colours
>
>JPEGs are for photographic (and similar) images and have 24-bit "true"
>colour - 16 million colours. Reduce it to 256 colours and you throw
>away a lot of picture quality. This is the main cause of your
>problems.
So I am beginning to understand :)
I have done a fair amount with pcx files in the past and have grim
memories of them in 24-bit colour on a 486 with 8Mb RAM. This is the
first time I have worked with jpegs and I suppose I sub-consciously
carried over the idea that as far as filesize is concerned 24-bit is bad
and 256 is good. I didn't know about the wonders of compression either
until a few weeks ago and since your article I have been surprised when
I compressed a 24-bit picture and saw how small it could be.
(snipped a lot of extremely useful explanation)
>What you should have done was simply convert the scanned image to a
>JPEG - that would reduce the file size enormously. Unfortunately,
>none of the image-manipulation proggies like PSP that I've seen let
>you set the JPEG compression (sometimes known as quality) so it will
>still be larger than it need be.
Because the pictures I am most concerned with were done with a digital
camera I saved them in the default format of the software which came
with it, jpeg. I now see that I could have saved them as TIFFs or BMPs.
Perhaps I should get a bigger hard disk and save them as BMPs and then I
can play with them to my heart's content in PSP5 and only at the last
moment save as jpegs. PSP5 does give you the opportunity to set
compression.
>What I use to play with the
>compression is CyberView Image Pro - see <URL:
>http://www.cyberviewcd.com>. Now I can use much larger graphics, even
>for thumbnails. Unfortunately, it's not free so you may not be able to
>justify buying it for only a few pics (it's only about ?20 though).
I've downloaded the evaluation version. It seems very powerful but
because the evaluation version will not allow me to save a file I
haven't worked out how I could compare filesizes yet.
>If you like to send me your jpegs I will compress them for you and we
>will have a natter as well :-D Send them over the weekend.
I've re-worked some of the photographs though I haven't uploaded them
yet but I will be in touch :) Thanks.
--
Glenys
http://www.howfen.demon.co.uk
I'd suggest TIFFs, not bitmaps. Also do not save them as compressed
TIFFs if you have the choice, because some programs cannot read them.
They will be BIG, real big.
[]
I'd suggest that you read the Graphics Optimisation page on my site at
<URL: http://www.atomor.demon.co.uk> before making sweeping statements.
One thing that is *most* important is Rule 1 of JPGs:
Never, *Never* apply JPG compression to a JPG image. In other words,
never apply JPG compression to an image to which the compression
algorithm has already been applied (unless you go back to the original
non-jpg imaage.
I too have read your pages, Tony, many, many times and found them to be
of immense help, but it has only been from various things I've read
recently that I have had a creeping realisation of the implications of
re-saving jpegs. On your Optimisation page you say:
"The steps are:
Check the number of colours used.
Convert GIF to JPG or JPG to GIF (or leave alone). Converting
may require the number of colours to be adjusted (128 or less
for GIF, 16 Million for JPG).
If GIF, Adjust the number of colours used.
If JPG, adjust the compression.
Check the pixel size of the file.
Check the pixel size required on page.
Adjust the size.
I recommend that you complete these in the order given."
Although you are talking about converting from gifs to jpegs and vice
versa I don't think I have taken it out of context. I assumed that the
photograph that I saved as a jpeg because that was the default (and it
is very prominent because it offers three qualities of jpeg, followed by
tiff and bmp) brought me into this list at the end of the second stage.
I am in the habit of saving any file at frequent intervals and I learned
to stop myself doing this with jpegs.
My heart sank when I read the Jpeg FAQ a couple of weeks ago and saw
that even cropping or rotating a jpeg had an effect on quality and
that's even without saving it.
>> In other words, never apply JPG compression to an image to which the
>> compression algorithm has already been applied (unless you go back to
>> the original non-jpg imaage.
>
>In general, I agree with that. However, I was talking about the case
>where the source is JPEG from a digital camera and I said that *if*
>the JPEG created by the camera had zero compression (there is still
>some loss of picture quality with zero compression but it is
>negligible) then it could be used as a source in this special case.
That seems to be the only option for me if I want to rework the pictures
from my original files rather than take them again. I don't think for
one moment that Dolores is suggesting this is ideal. I may well take
the pictures again, those that I can, purely out of interest.
Before I showed anything to anyone other than my nearest and dearest I
had tried all sorts of ways of scanning and photographing some of my
work and I have 200 Mb of files on my hard disk to prove it. I can have
yet another go. I suspect there will be marginal improvement except for
those whose aged computers can deal with only 256 colours but it will be
a challenge.
I did this site primarily as an exercise in getting the hang of HTML.
Though I had had a vague idea of doing a site I didn't start off with
the intention of publishing anything at all other than to friends and
family. I needed to do a site for work where I am required to use
FrontPage and thought it would be easier to learn the basics with a
simple editor and content that interested me. I thought that the
graphics were going to be the easiest bit and it was only a chance
remark of a friend that one of my pictures looked rather dark and ill-
defined that set me on this track of finding out what was going on.
I have learned a lot from everyone's comments, and in particular not to
assume that I know what I am doing :)
--
Glenys
The Graphics Optimisation page was put together some time ago and in
view or your (and other's) comments some of it needs clarifying.
I think that you'll find that if you accept my suggestion regarding
scanning at a relatively high resolution, providing that you aren't too
aggressive with JPG compression, and as the image is resized/resampled
to a much smaller size and resolution, the degradation of the image
isn't noticeably significant.
In fact, using my Sony digital camera which produces 1024x768 in an
aggressively JPG'd format, by the time an image is reworked and reduced
to (usually about) 300px wide, I never seem to encounter perceivable
problems.
In regard to scanning, as I generally use either Picture Publisher or
Fireworks, they save in .PPF and PNG formats by default (respectively),
and again I get no problems. Both of these formats provide non-lossy
graphics compression.
Another thing I usually do as a *last* step, is to apply 'sharpen edges'
at the final resolution/size - which often gives a dramatic improvement
in the *perceived* image quality.
re jpeg compression
>I am in the habit of saving any file at frequent intervals and I learned
>to stop myself doing this with jpegs.
I don't think there is any problem with frequently saving the jpeg *as
you are working on it* - the problem of increasing degradation will only
occur if you remove the image from memory (e.g. by closing down your
graphics program) and then reload the [now compressed] image from disk
to work on it further.
--
Paul Terry
If the file is already a .jpg, then perform 'Save As' rather than just
'Save' as you'll then be able to click on the 'Options' button (actually, do
this no matter what the format.. just choose 'Jpeg' as the file type before
hitting the 'Options' button). Previous versions (ie: PSP4) used to set
these types of options under the 'Image Information' (or whatever it was
called :)), but they decided to move it in 5 (to a better place IMO).
That 'Options' button is file-type sensitive, meaning that if you tried to
save the image as a .gif (for example), you'd be asked other things than
JPEG compression, like whether you want a transparent colour to be set,
etc., so this is why you have to make sure you choose the file type you are
interested in before it'll do anything useful.
Regards,
Nick
I disagree, I've often come across over-large jpegs on the Net which
can be resaved at considerable space saving and negligible loss in image
quality. I have some on my website in fact, eg. the 38K image
<URL: http://www.xerez.demon.co.uk/g15/MLYNJH.JPG>
The original was 262K which I felt was ridiculously large, so I simply
resaved it with Lview (at the default 75% quality I think, though it may
have been a bit less). Despite the enormous size reduction, the quality
loss is only discernible when the images are compared at 200%
magnification. When reusing pics I've found elsewhere I usually find I
can get away with recompressing jpegs or reducing the number of
colours in gifs (or turning them into jpegs or vice versa) to save
bandwidth.
-Shez.
--
____________________________________________________________
Health is merely the slowest possible rate at which one can die.
____________________________________________________________
Address any email replies to Shez (email to "news" is rejected)
(c)Shez asserts the moral rights of authorship under the Berne Convention
Take a break at the Last Stop Cafe at <URL: http://www.xerez.demon.co.uk/>
Try this Shez....
1. Create a 200x200px graphic at (say) #E2FFFF
2. Put a 75x75px square in the middle of it at (say) #FF0000.
3. Save as JPG at the compression you suggest.
4. Now create a web page with a background of #E2FFFF (the
same colour as in (1) above).
5. Put the graphic on the page.
6. Save and view in your browser.
Still disagree?
It demonstrates the colour shift you get when compressing JPGs, and you
can hardly ask for an 'old master' to be created to demonstrate :-)
Some time ago I started (for a *very* short time) to use JPGs on plain
backgrounds rather than transparent GIFs to *really* minimise the
bytesize - but when I started to get these colour-shifts (which really
do show up against a plain pastel background) - I quickly realised the
error of my ways :-)
I'm not sure what your point is. Saved as a jpeg the red square has a
slightly fuzzy edge, but I would use a GIF for a graphic like this, or even
a HTML table with a coloured cell.
I don't see what it has to do with recompressing an existing jpeg, which
is what I was discussing. (I did try resaving it as a matter of interest, and
the second generation copy showed little deterioration.)
-Shez.
--
____________________________________________________________
Lowery's Law: If it jams -- force it. If it breaks, it needed replacing anyway.
This must depend on the compressor then, as there was no discernible
difference between the colours of the original bitmap and first & second
generation jpegs that I made.
I checked them with the photoshop eyedropper and the red channel of
the jpegs was 1 point down compared to the original bitmap, e.g. the
red square was down from 255 to 254. This was not discernible when
looked at in the browser though, and didn't change any further in the
second generation.
>Some time ago I started (for a *very* short time) to use JPGs on plain
>backgrounds rather than transparent GIFs to *really* minimise the
>bytesize
As a 4-colour GIF the graphic came in at 477 bytes, compared to 922
bytes as a jpeg at the lowest quality setting.
-Shez
Will it matter that E2FFFF is not on the websafe palette list?
>
>2. Put a 75x75px square in the middle of it at (say) #FF0000.
>
>3. Save as JPG at the compression you suggest.
>
>4. Now create a web page with a background of #E2FFFF (the
> same colour as in (1) above).
>
>5. Put the graphic on the page.
>
>6. Save and view in your browser.
>
>Still disagree?
--
Modern 95 systems can do it without (although you need to get it to ask
first).
--
Robert Bradley
I am not a mindreader, so I don't know everything.
>I'd suggest TIFFs, not bitmaps. Also do not save them as compressed
>TIFFs if you have the choice, because some programs cannot read them.
>They will be BIG, real big.
Could I ask why TIFFs are preferable to bitmaps? I am quite happy to
use any format that will help me produce good quality pictures for my
homepages. Now that I have started I fear that there will be more pages
and more pictures to come so I might as well get things straight at this
early stage.
--
Glenys
I've been pondering on this.
I started off with files from the camera that were called .JPG. Mindful
of the need to having matching filenames for the image and its reference
in the page I know I renamed all of my 50+ pictures <URL:http://www.howf
en.demon.co.uk/morebob/first.html> at some stage as I was working on
them.
I thought that rotating the image through one or two degrees and another
.2 degrees back, fiddling and twiddling and Saving As something else and
then as an 8.3 filename wouldn't make a difference. In the light of
what you say maybe it didn't. I didn't see starting on the Saved As
file as being any different from starting on the original until I read
the Jpeg FAQ.
--
Glenys
The point I was trying to make (and demonstrate) is that the JPG
compression algorithm often (usually in fact) introduces a colour shift.
If you can't see this then forget it. You're wasting my time!
And your observation in your previous post regarding a '4 colour gif' is
out of context and a red-herring.
In response to this, perhaps you can describe the difference between the
Netscape palette and the IE (aka Windows) palette. You will then see
that your question is irrelevant to this context.
Apart from colour shifts some gif to jpg conversions can look decidedly
gruesome. Not so long ago I tried to do some gif to jpg conversions for
someone who had set up a site with Publisher. One of the unacceptably
large graphics was a blue text on a "woodgrain" background. In the jpg
blotches of blue appeared in the wood and the text was rather ragged at
the edges. Reducing the number of colours in the gif to get the size
down also degraded the image. What I did in the end was to make a jpg
of woodgrain on its own and use it the background of a single cell table
with the text rendered separately as the content of the cell. Doing it
that way got 56K down to 12K.
--
E. J. Jewell <mailto:eje...@chy-an-piran.demon.co.uk>
<URL:http://www.chy-an-piran.demon.co.uk/>
Just altering the name of a file would have no effect on its content.
>
>I thought that rotating the image through one or two degrees and another
>.2 degrees back, fiddling and twiddling and Saving As something else and
>then as an 8.3 filename wouldn't make a difference. In the light of
>what you say maybe it didn't. I didn't see starting on the Saved As
>file as being any different from starting on the original until I read
>the Jpeg FAQ.
>
I did read somewhere a Counsel of Perfection that you should (i) make a
copy of the original file and work on that (ii) record all the twiddles
you do (iii) simplify these (eg 4 forward and 2 back --> 2 forward) (iv)
finally, apply the simplified twiddles to the original file and only
then save as jpg.
No, I don't do it that way either..
I suspect the main reason is that they can be saved compressed
(lossless) to save on diskspace.
>Could I ask why TIFFs are preferable to bitmaps?
"Bitmaps" tends to be used to refer to all raster formats (tiffs, .bmps
and so on, as opposed to the vector formats) so I will assume the
question is about why TIFFs are preferable to BMPs. AIUI:
1. .bmps use no compression, while .tifs use (unlike .jpgs) *lossless*
compression. The result is that .tifs almost always occupy less disk
space than the equivalent .bmp format.
2. .tifs are platform independent - you can exchange them with users
of Macs, Amigas, etc - while .bmps are specific to Windows (and,
with another variant of the .bmp format, to OS/2 + Windows).
3. .tifs (*tagged* image format, remember) can store extra information
in the tagging - this is called "meta information" and can include
textual information, such as name of artist, date, scanning details
and so on - usually while still being more compact than the
equivalent .bmp file. Some variants of .tif (such as Photopaint's
.cpt format which I often use) can include a lot more, such as saving
masks as part of the image.
I should add that I am no expert on any of this, but my understanding is
that, for the above reasons, tifs are generally preferred. There are
some drawbacks - particularly the large number of variants on .tif,
which I think may have arisen because some graphics software has not
made the effort to support the full potential of TIFF. I am also unsure
if some of the TIFF compression algorithms (of which LZW compression
seems the most popular) don't compromise the elegance of pure TIFF with
certain types of image.
However, having said all that, I think you would generally be better off
with (plain) .tif format than with a MS Windows .bmp - if in doubt,
remember that anything to do with Microsoft will occupy more disk space,
and with much less purpose, than the available alternatives!
--
Paul Terry
>
> I should add that I am no expert on any of this, but my understanding is
> that, for the above reasons, tifs are generally preferred. There are
> some drawbacks - particularly the large number of variants on .tif,
> which I think may have arisen because some graphics software has not
> made the effort to support the full potential of TIFF. I am also unsure
> if some of the TIFF compression algorithms (of which LZW compression
> seems the most popular) don't compromise the elegance of pure TIFF with
> certain types of image.
>
I generally use a non-compressed tiff in a zip file. (Non-compressed = wider
compatibility, zip gives you compression).
BTW, given the non-lossy nature of compressed tiffs, why weren't tiffs
included in the types of files browsers could interpret?
--
Regards
Roger
<URL: http://www.roga.demon.co.uk >
I realise that sounds very naive but it was to be read in conjunction
with the following paragraph.
>>I thought that rotating the image through one or two degrees and another
>>.2 degrees back, fiddling and twiddling and Saving As something else and
>>then as an 8.3 filename wouldn't make a difference. In the light of
>>what you say maybe it didn't. I didn't see starting on the Saved As
>>file as being any different from starting on the original until I read
>>the Jpeg FAQ.
>>
>I did read somewhere a Counsel of Perfection that you should (i) make a
>copy of the original file and work on that (ii) record all the twiddles
>you do (iii) simplify these (eg 4 forward and 2 back --> 2 forward) (iv)
>finally, apply the simplified twiddles to the original file and only
>then save as jpg.
>
>No, I don't do it that way either..
As with anything else once you know the rules you know when you can
break them - but you do have to know the rules in the first place.
--
Glenys
sorry :( The helpfile in PSP5 refers to raster and vector but doesn't
explain further and it is on my long list of things to find out about.
I meant Windows .bmps.
> AIUI:
>
>1. .bmps use no compression, while .tifs use (unlike .jpgs) *lossless*
> compression. The result is that .tifs almost always occupy less disk
> space than the equivalent .bmp format.
Saving images first as .bmps then re-saving as .tifs has been very
interesting. On some, the very 'busy' ones, where there is a lot of
detail and a big colour range, there is such a small difference in
filesizes that I would not have thought there was any point in choosing
one format over the other if this had been the only one I had looked at.
On others, notably where there are large blocks of one colour the
difference has been astonishing.
>2. .tifs are platform independent - you can exchange them with users
> of Macs, Amigas, etc
I didn't know that.
>3. .tifs (*tagged* image format, remember) can store extra information
> in the tagging - this is called "meta information"
I didn't know that either.
>I should add that I am no expert on any of this, but my understanding is
>that, for the above reasons, tifs are generally preferred. There are
>some drawbacks - particularly the large number of variants on .tif,
On one or two occasions in the past I have sent things as a .tif, a
black and white drawing I remember in particular, it didn't work, or at
least not as it should have done. They had something to look at but it
was only months later that I saw a print-out (they were too polite to
say at the time) and it was a travesty of the image I had sent. That
rather put me off .tifs and as I had other formats that I knew would
work easily and reliably with them. I haven't used .tifs since.
>However, having said all that, I think you would generally be better off
>with (plain) .tif format than with a MS Windows .bmp - if in doubt,
>remember that anything to do with Microsoft will occupy more disk space,
>and with much less purpose, than the available alternatives!
I am something of a heretic because I have found FP very helpful in
managing the files on my work site (I had to give in to FP's ways) and
it has been useful to be referred back to Windows .bmps here on the
question of graphics.
Today I bought a very large book on HTML. If I don't post for a while
either I am creating content for new pages or the book slipped from my
hands and I have done myself a serious injury but I will be back in time
with more questions.
--
Glenys
Size really doesn't matter....
You should have gone for the excellent Elizabeth Castro'd Visual
Quickstart Guide 'HTML 4 For the World Wide Web' (and probably a lot
cheaper that you have paid).
You may (or not!) find the following interesting:
http://www scantips.com/index.html - a huge site on how to scan; not
everybody agrees with everything the author says but its thought-
provoking.
http://www.faqs.org/faqs/jpeg-faq/ - a rather technical tome about JPEG,
brief bit on JPEG vs GIF. For more on this see also http://www.adobe.co
m/studio/tipstechniques/GIFJPGchart/gifjpgcon.html
http://www.cdrom.com/pub/png/spec/PNG-GammaAppendix.html goes on about
the definition of Gamma
http://www.servtech.com/~dougg/graphics/index.html discusses with
illustrations the preparation of web graphics
http://www.microsoft.com/workshop/design/color/colorman.asp does the
same, in pages which seem locked to be quarto wide so don't print well
on A4!
http://www.microsoft.com/workshop/design/color/safety.asp and
http://www.microsoft.com/workshop/design/color/ColorPick.asp and
http://www.lynda.com/hex.html discuss the 'safety palette'.
And if all else fails RTFM at:
http://www.demon.net/www.faq/webgraphics.html
The small introductory book I bought at first was splendid for getting
started but it doesn't answer the questions I have now, for work as well
as homepages. A large manual I borrowed taught me quite a bit but for
all its pages I found that there was very little detail when I wanted to
focus on particular issues of concern to me. I settled on buying a big
book the style of which appeals to me and which appears to be well-
regarded.
>You should have gone for the excellent Elizabeth Castro'd Visual
>Quickstart Guide 'HTML 4 For the World Wide Web' (and probably a lot
>cheaper that you have paid).
I spend a lot of my time advising students (in a different discipline)
to buy as many books as they can afford within their budget to get
different perspectives on the same subject. Following my own advice and
practice I have ordered the Quickstart Guide and will be very interested
to look at it.
I notice that the book you recommend isn't mentioned in the FAQ. It
might be a useful addition.
--
Glenys
"All books, even bad books, are sacred." Heinrich Boll
>You may (or not!) find the following interesting:
I found a lot of help here that I have bookmarked to look at again.
>http://www.faqs.org/faqs/jpeg-faq/ - a rather technical tome about JPEG,
>brief bit on JPEG vs GIF. For more on this see also http://www.adobe.co
>m/studio/tipstechniques/GIFJPGchart/gifjpgcon.html
That's the one I have looked at before :(
>http://www.cdrom.com/pub/png/spec/PNG-GammaAppendix.html goes on about
>the definition of Gamma
Very useful.
>http://www.servtech.com/~dougg/graphics/index.html discusses with
>illustrations the preparation of web graphics
Interesting.
>http://www.microsoft.com/workshop/design/color/colorman.asp does the
>same, in pages which seem locked to be quarto wide so don't print well
>on A4!
>
>http://www.microsoft.com/workshop/design/color/safety.asp and
>http://www.microsoft.com/workshop/design/color/ColorPick.asp
Purely out of interest and just to prove I did look at them these are
referred on to other pages now.
http://msdn.microsoft.com/workshop/design/color/safety.asp etc
>And if all else fails RTFM at:
> http://www.demon.net/www.faq/webgraphics.html
I'll do you a deal, Andy. You insert a forward slash in place of the
dot in www.faq above and I'll ignore the F in RTFM :)
--
Kind regards,
Glenys