OT - Paul? Help!

Fran said:

EXIF data: WTH?? Silly me, I expected the data returned by
the camera to correspond in some way with the settings I'd
used. More fool me I suppose... The EV settings on my camera
vary in increments of 0.3 from -1.5 through 0 to +1.5; the
white balance settings are: sunny; cloudy; fluorescent 1; fl
2; fl 3; incandescent; auto. I didn't bother fiddling with
anything else except that the flash was turned off. The
results of my fiddlings are at
http://frances.fotopic.net/c357019.html - and as the notes
will tell you the EXIF data's disappeared consequent upon my
cropping away extraneous foreground... Aaaarghhhh!

EXIF tends to get chucked out when you edit.

This is why you should keep the original as it comes out of the camera
safely tucked away in a read only folder.

A quick look reveals slow shutter speeds with people blured by
movement [1], other than that the white ballance looks pretty good on
the three flourescent settings, file 007 and on I presume. Which is
best only your memory can judge. From memory of camera reviews the
flourecent settings tend to give better results than auto, flourescent
is notoriously tricky as it tends to have spikes in the frequency of
the light output from the tube. You might want to see if your camera
has been reviewed at http://www.dpreview.com/ and how it handles the
different light sources. Since these are indoor shots there is likely
to be little sky to mislead the meter and I reckon you can leave the
exposure compensation set to zero. Any blown highlight won't matter as
they will be in things like lights and windows that you don't want
detail in in the grand scheme of things.

[1] Given that archery and shooting in general relies on keeping as
still as possible at the moment of release I don't see this being a
problem.
--
Phil Cook looking north over the park to the "Westminster Gasworks"

Fran said:

EXIF data: WTH?? Silly me, I expected the data returned by
the camera to correspond in some way with the settings I'd
used. More fool me I suppose... The EV settings on my camera
vary in increments of 0.3 from -1.5 through 0 to +1.5; the
white balance settings are: sunny; cloudy; fluorescent 1; fl
2; fl 3; incandescent; auto. I didn't bother fiddling with
anything else except that the flash was turned off. The
results of my fiddlings are at
http://frances.fotopic.net/c357019.html - and as the notes
will tell you the EXIF data's disappeared consequent upon my
cropping away extraneous foreground... Aaaarghhhh!

A better editing suite will preserve these - what are you using ?

One problem with storing decimal values is that the representation of these
numbers can be platform-dependent. Using a numerator/denominator approach
avoids this as it is much easier to mandate the way that whole numbers
(integers) are interpreted. Thus 1.5 could be stored as 15 and 10, or 3 and
2, or whatever makes most sense. I do admit that some camera manufacturers
seem to opted for the most bizarre denominators (256 and the like). 10 will
of course give you one decimal point which is good enough for camera
purposes, and is probably the most common.

--
Since I've used all of my sick days, I'm calling in dead.

Mail john rather than nospam...

[email hidden] said...

Quoted message said:

Quoted message said:

The
results of my fiddlings are at
http://frances.fotopic.net/c357019.html - and as the notes
will tell you the EXIF data's disappeared consequent upon my
cropping away extraneous foreground... Aaaarghhhh!

A better editing suite will preserve these - what are you using ?

PSP 8

Quoted message said:

One problem with storing decimal values is that the representation of these
numbers can be platform-dependent. Using a numerator/denominator approach
avoids this as it is much easier to mandate the way that......

Wha'??? I was with you all the way to 'problem', but then you
lost me.
--
I try to be a good example to my children, but they just see
me as a dire warning.

I noticed that Message-ID:
<[email hidden]> from Fran contained the
following:

Quoted message said:

Quoted message said:

One problem with storing decimal values is that the representation of these
numbers can be platform-dependent. Using a numerator/denominator approach
avoids this as it is much easier to mandate the way that......

Wha'??? I was with you all the way to 'problem', but then you
lost me.

I wasn't sure either in this context but he could be talking about the
problems of storing decimal values in binary. Whole numbers will
convert to binary just fine but with decimals there will often be very
tiny errors in the conversion. Also, some decimal values are recurring.
For instance, take the fraction 2/3 As a decimal this 0.6666 recurring
- it goes on forever; How do you convert that to binary exactly?
However if you store it as 2 divided by 3, the problem goes away.

BICBW...

--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

Fran said:

[email hidden] said...

Quoted message said:

Quoted message said:

The
results of my fiddlings are at
http://frances.fotopic.net/c357019.html - and as the notes
will tell you the EXIF data's disappeared consequent upon my
cropping away extraneous foreground... Aaaarghhhh!

A better editing suite will preserve these - what are you using ?

PSP 8

I don't know about PSP but it works elsewhere - try using Save As
instead of Save. This may (or may not) preserve EXIF settings.

Otherwise, you can get Freeware EXIF editors (do a google) which would
allows you to add back the settings from your original image.

S.

--
York Alpine Club - http://www.yorkalpineclub.org.uk
Recent Photos - http://climbing.me.uk
Old Photos - http://www.simon-caldwell.co.uk
My Brother's Photos - http://www.caldwellcreations.co.uk

Geoff Berrow said:

I noticed that Message-ID:
<[email hidden]> from Fran contained the
following:

Quoted message said:

Quoted message said:

One problem with storing decimal values is that the representation of these
numbers can be platform-dependent. Using a numerator/denominator approach
avoids this as it is much easier to mandate the way that......

Wha'??? I was with you all the way to 'problem', but then you
lost me.

I wasn't sure either in this context but he could be talking about the
problems of storing decimal values in binary. Whole numbers will
convert to binary just fine but with decimals there will often be very
tiny errors in the conversion. Also, some decimal values are recurring.
For instance, take the fraction 2/3 As a decimal this 0.6666 recurring
- it goes on forever; How do you convert that to binary exactly?
However if you store it as 2 divided by 3, the problem goes away.

(takes deep breath... no condescension intended...)

Can I assume knowledge of 0's and 1's ? Digital data is always represented
in "binary" - 0 and 1 are the only two values allowed. This is somewhat
conceptual - in reality they are typically electrical or magnetic signals.
Small holes in punch cards, paper tape. A crystal lined up one way or the
other. Whatever, off or on, 0 or 1. The storage required for each 0 or 1
is a bit. Somewhat less rigorously, 8 bits make up what is usually the
smallest real item of storage which is a byte.

Man however has more or less uniformly adopted a decimal number system.
Almost certainly because we have 10 fingers and thumbs. , though. We count
1, 2, 3... 9, 10, 11... 99, 100, 101... and this is generally believed to
have been invented or put to most use by the Arabs, possibly derived from
Indian origins. Any cursory examination of Roman numerals will reveal this
to be quite different in concept (and a complete b*****d to do sums in, for
example).

Okay, so in binary, 1, 2, 3 etc, are 1, 10, 11, 100, 101, 110, 111, 1000 and
so on. The principle is exactly the same as our normal decimal system,
except there is a whole lot more adding-and-carrying. However, since there
are only two possible values, the process of addition can be made extremely
simple, so simple that electronic circuits can do it. Very very quickly ;-)
Rather than adding digits to count in 1s, 10s, 100s, 1000s and so on, the
binary system counts in 1s, 2s, 4s, 8s, 16s etc.

Back to the problem in hand. Suppose I want to store "3". Now, is that 3 a
whole number, 3.0 (which you might think to be the same thing but isn't), or
the character 3 ? In computer terms, they are all different.

Computer scientists refer to whole numbers as "integers", and any fractional
numbers as "floating-point". I apologise for using the term decimal in an
ambiguous fashion - strictly speaking it refers to our number base of 10.
Yet even in binary arithmetic, one can have a "decimal point". For example,
2.5 to us is 10.1 to a computer - 10 to the left of the point being 2 to us,
and the 1 afterwards being not the number of 1/10ths but the number of 1/2s
(the next digit is the number of 1/4s, then 1/8s, 1/16s, etc.) It would be
quite feasible to store all numbers in this fashion (a whole number simply
having a fractional part of zero), but there are a few problems. One is
that some early digital computers had no floating-point capability at all.
If you wanted to add 1.3 to 2.5 you had to turn that into something the
computer could do. Another problem is a balance of range to precision.
Going back a few years, many computers could handle only 16-bit values. In
binary, you cannot store a whole number greater than 65535 in 16 bits. Even
going to 32 bits only gets you to 4 billion. That's not very helpful if you
are counting the fortunes even of 1 man these days. One option is to store
everything in a character form and just use more characters - that is a
computing nightmare and very inefficient to process, although it is the way
that Cobol works for those who have come across this language (accountants
have a funny habit of not being very happy with the idea of having
approximately £1.99 to spend, so financial systems certainly all started
life in Cobol).

The solution adopted was so-called floating-point numbers. In binary, any
number you care to think of can be represented to some level of accuracy as
a whole number of 0s and 1s and a fractional part of 0s and 1s. You may
however need an awful lot of bits for very large or very small numbers. To
fit this into a fixed number of bits, what happens is that the "decimal"
point is moved to the left or right by multiplying or dividing by 2 and
counting the number of times this is done, until you end up with either
1.something or 0.1something (given a choice of two ways of doing things,
computer scientists will always divide into two groups and do both
independently). The number that is left is known as the mantissa and the
count forms the exponent (each can be negative). You won't often find this
done for our normal decimal system outside engineering or scientific circles
as non-technical people prefer to use words. [So, today the Chancellor will
probably stand up and tell us all he needs to raise another 33.5 billion
pounds or whatever, not 33500000000 or 3.35 times 10 to the 10.] The
mantissa is usually truncated or rounded at an appropriate point, resulting
in a fixed level of precision, as Geoff alluded. 1/3 for example cannot be
stored exactly. You can see such problems in scientific calculators for
example - divide 1 by 3, and multiply the result by 3 again. Early models
would tend to come up with 0.9999999, now they will tend to show you 1.
Subtract 1 from that, however, and the answer won't be 0 :-) Geoff alluded
to this loss of precision or inaccuracy - however it's not a big issue for
storing F-stops or even shutter speeds.

Typically, 32 bits used for floating-point storage can hold values up to
around 10 to the 38 (that's 1 followed by 39 zeroes) - enough even for Bill
Gates' bank account. But the precision is usually around 7 digits when
converted to decimals. So, Bill can tell how many billions of dollars he
has, but probably only to the nearest hundred or even thousand, and
certainly not how many cents in loose change there is (as if he cared).
This is another reason why financial systems went off and did their own
thing.

Returning to the point:

So, we need to store our EXIF data along with the image. Some of this will
be text data. That's more or less settled now - a system by the name of
ASCII lays down how different binary values represent different characters,
numerals, punctuation marks, etc. (There was another widely-used system
called EBCDIC, adopted if not invented by IBM, but even they had to
capitulate in the end. EBCDIC had "holes" in it, so the values representing
A and Z were not 25 apart, for example.) So text is okay - just about every
computer on the planet can see values of 69, 88, 73 and 70 and now that this
means "EXIF". ASCII is an 8-bit system and fortunately again just about
every computer understands what order the 8 bits arrive in.

Things get a little more complicated with integers which are generally
stored in either 16 or 32 bits. 1000 in decimal is 1111101000 in binary for
example. In 16 bits, we conventionally add leading zeroes to get
0000001111101000 and then split into two 8-bit bytes so:
00000011 11101000. Now, which one gets stored first ?! Once again,
computer scientists couldn't agree and in fact both arrangements are in
popular use. It's a bit like left and right-handers. For what it's worth,
Intel and AMD store the "low-order" byte first (the low-order one contains
the bit representing 1 and is on the right as we write it down), and as the
PC has come to dominate, this is probably the most common storage. However,
the Unix world grew up as left-handers and store the low-order byte last.
They got to develop the Internet and thus their preference dominates there.
(I should add that most modern computer chips are now tending to be
ambidextrous and can handle numbers stored in both ways. Fortunately with
just the two interpretations even us humble IT people can only be wrong 50%
of the time, or put another way we can always get it right by the second
attempt.)

Floating-point numbers, however, went a whole variety of different ways as
computer manufacturers tackled the problem in the 50s, 60s and 70s
individually. There are literally probably dozens of different storage
methods. One proposed by an international body (IEEE) has become a de-facto
standard but when it comes to transmitting data no software developer really
wants to have to incorporate conversion methods into and out of his local
machine's true preference. For numbers which can be easily represented as a
numerator/denominator, in a particular application, then it makes more sense
to do that when storing values in a manner which is likely to have to be
portable. So, exposure times for example are generally 1/something or maybe
something.0 or .5. Short times can be stored as a numerator of 1 and a
denominator of the something, longer ones probably multiplied by 10 to
remove the decimal point, giving a numerator of ten times the true value and
a denominator of 10. If you are writing an image-editing application, you
merely read in the numerator and denominator and ask your computer to divide
one by the other to give the true value, should you need to then go on and
do any processing with it. You don't need to know how that value was stored
on the camera, and you don't need to know how it is stored on your computer.

Coming back to the OP, I would've thought that PSP ought to be able to
preserve at least some EXIF data. Perhaps it is an option somewhere ? I
know Irfanview can do it, and that's hardly a pro-level package, more a tool
for us amateurs :-)

HTH.

--
It's not hard to meet expenses, they're everywhere.

Mail john rather than nospam...

Geoff Berrow said:

I noticed that Message-ID:
<[email hidden]> from Fran contained the
following:

Quoted message said:

Quoted message said:

One problem with storing decimal values is that the representation of these
numbers can be platform-dependent. Using a numerator/denominator approach
avoids this as it is much easier to mandate the way that......

Wha'??? I was with you all the way to 'problem', but then you
lost me.

I wasn't sure either in this context but he could be talking about the
problems of storing decimal values in binary. Whole numbers will
convert to binary just fine but with decimals there will often be very
tiny errors in the conversion. Also, some decimal values are recurring.
For instance, take the fraction 2/3 As a decimal this 0.6666 recurring
- it goes on forever; How do you convert that to binary exactly?
However if you store it as 2 divided by 3, the problem goes away.

(takes deep breath... no condescension intended...)

Can I assume knowledge of 0's and 1's ? Digital data is always represented
in "binary" - 0 and 1 are the only two values allowed. This is somewhat
conceptual - in reality they are typically electrical or magnetic signals.
Small holes in punch cards, paper tape. A crystal lined up one way or the
other. Whatever, off or on, 0 or 1. The storage required for each 0 or 1
is a bit. Somewhat less rigorously, 8 bits make up what is usually the
smallest real item of storage which is a byte.

Man however has more or less uniformly adopted a decimal number system.
Almost certainly because we have 10 fingers and thumbs. , though. We count
1, 2, 3... 9, 10, 11... 99, 100, 101... and this is generally believed to
have been invented or put to most use by the Arabs, possibly derived from
Indian origins. Any cursory examination of Roman numerals will reveal this
to be quite different in concept (and a complete b*****d to do sums in, for
example).

Okay, so in binary, 1, 2, 3 etc, are 1, 10, 11, 100, 101, 110, 111, 1000 and
so on. The principle is exactly the same as our normal decimal system,
except there is a whole lot more adding-and-carrying. However, since there
are only two possible values, the process of addition can be made extremely
simple, so simple that electronic circuits can do it. Very very quickly ;-)
Rather than adding digits to count in 1s, 10s, 100s, 1000s and so on, the
binary system counts in 1s, 2s, 4s, 8s, 16s etc.

Back to the problem in hand. Suppose I want to store "3". Now, is that 3 a
whole number, 3.0 (which you might think to be the same thing but isn't), or
the character 3 ? In computer terms, they are all different.

Computer scientists refer to whole numbers as "integers", and any fractional
numbers as "floating-point". I apologise for using the term decimal in an
ambiguous fashion - strictly speaking it refers to our number base of 10.
Yet even in binary arithmetic, one can have a "decimal point". For example,
2.5 to us is 10.1 to a computer - 10 to the left of the point being 2 to us,
and the 1 afterwards being not the number of 1/10ths but the number of 1/2s
(the next digit is the number of 1/4s, then 1/8s, 1/16s, etc.) It would be
quite feasible to store all numbers in this fashion (a whole number simply
having a fractional part of zero), but there are a few problems. One is
that some early digital computers had no floating-point capability at all.
If you wanted to add 1.3 to 2.5 you had to turn that into something the
computer could do. Another problem is a balance of range to precision.
Going back a few years, many computers could handle only 16-bit values. In
binary, you cannot store a whole number greater than 65535 in 16 bits. Even
going to 32 bits only gets you to 4 billion. That's not very helpful if you
are counting the fortunes even of 1 man these days. One option is to store
everything in a character form and just use more characters - that is a
computing nightmare and very inefficient to process, although it is the way
that Cobol works for those who have come across this language (accountants
have a funny habit of not being very happy with the idea of having
approximately £1.99 to spend, so financial systems certainly all started
life in Cobol).

The solution adopted was so-called floating-point numbers. In binary, any
number you care to think of can be represented to some level of accuracy as
a whole number of 0s and 1s and a fractional part of 0s and 1s. You may
however need an awful lot of bits for very large or very small numbers. To
fit this into a fixed number of bits, what happens is that the "decimal"
point is moved to the left or right by multiplying or dividing by 2 and
counting the number of times this is done, until you end up with either
1.something or 0.1something (given a choice of two ways of doing things,
computer scientists will always divide into two groups and do both
independently). The number that is left is known as the mantissa and the
count forms the exponent (each can be negative). You won't often find this
done for our normal decimal system outside engineering or scientific circles
as non-technical people prefer to use words. [So, today the Chancellor will
probably stand up and tell us all he needs to raise another 33.5 billion
pounds or whatever, not 33500000000 or 3.35 times 10 to the 10.] The
mantissa is usually truncated or rounded at an appropriate point, resulting
in a fixed level of precision, as Geoff alluded. 1/3 for example cannot be
stored exactly. You can see such problems in scientific calculators for
example - divide 1 by 3, and multiply the result by 3 again. Early models
would tend to come up with 0.9999999, now they will tend to show you 1.
Subtract 1 from that, however, and the answer won't be 0 :-) Geoff alluded
to this loss of precision or inaccuracy - however it's not a big issue for
storing F-stops or even shutter speeds.

Typically, 32 bits used for floating-point storage can hold values up to
around 10 to the 38 (that's 1 followed by 39 zeroes) - enough even for Bill
Gates' bank account. But the precision is usually around 7 digits when
converted to decimals. So, Bill can tell how many billions of dollars he
has, but probably only to the nearest hundred or even thousand, and
certainly not how many cents in loose change there is (as if he cared).
This is another reason why financial systems went off and did their own
thing.

Returning to the point:

So, we need to store our EXIF data along with the image. Some of this will
be text data. That's more or less settled now - a system by the name of
ASCII lays down how different binary values represent different characters,
numerals, punctuation marks, etc. (There was another widely-used system
called EBCDIC, adopted if not invented by IBM, but even they had to
capitulate in the end. EBCDIC had "holes" in it, so the values representing
A and Z were not 25 apart, for example.) So text is okay - just about every
computer on the planet can see values of 69, 88, 73 and 70 and now that this
means "EXIF". ASCII is an 8-bit system and fortunately again just about
every computer understands what order the 8 bits arrive in.

Things get a little more complicated with integers which are generally
stored in either 16 or 32 bits. 1000 in decimal is 1111101000 in binary for
example. In 16 bits, we conventionally add leading zeroes to get
0000001111101000 and then split into two 8-bit bytes so:
00000011 11101000. Now, which one gets stored first ?! Once again,
computer scientists couldn't agree and in fact both arrangements are in
popular use. It's a bit like left and right-handers. For what it's worth,
Intel and AMD store the "low-order" byte first (the low-order one contains
the bit representing 1 and is on the right as we write it down), and as the
PC has come to dominate, this is probably the most common storage. However,
the Unix world grew up as left-handers and store the low-order byte last.
They got to develop the Internet and thus their preference dominates there.
(I should add that most modern computer chips are now tending to be
ambidextrous and can handle numbers stored in both ways. Fortunately with
just the two interpretations even us humble IT people can only be wrong 50%
of the time, or put another way we can always get it right by the second
attempt.)

Floating-point numbers, however, went a whole variety of different ways as
computer manufacturers tackled the problem in the 50s, 60s and 70s
individually. There are literally probably dozens of different storage
methods. One proposed by an international body (IEEE) has become a de-facto
standard but when it comes to transmitting data no software developer really
wants to have to incorporate conversion methods into and out of his local
machine's true preference. For numbers which can be easily represented as a
numerator/denominator, in a particular application, then it makes more sense
to do that when storing values in a manner which is likely to have to be
portable. So, exposure times for example are generally 1/something or maybe
something.0 or .5. Short times can be stored as a numerator of 1 and a
denominator of the something, longer ones probably multiplied by 10 to
remove the decimal point, giving a numerator of ten times the true value and
a denominator of 10. If you are writing an image-editing application, you
merely read in the numerator and denominator and ask your computer to divide
one by the other to give the true value, should you need to then go on and
do any processing with it. You don't need to know how that value was stored
on the camera, and you don't need to know how it is stored on your computer.

Coming back to the OP, I would've thought that PSP ought to be able to
preserve at least some EXIF data. Perhaps it is an option somewhere ? I
know Irfanview can do it, and that's hardly a pro-level package, more a tool
for us amateurs :-)

HTH.

--
It's not hard to meet expenses, they're everywhere.

Mail john rather than nospam...

In article <[email hidden]>, John Laird
<[email hidden]> writes

Quoted message said:

Any cursory examination of Roman numerals will reveal this
to be quite different in concept (and a complete b*****d to do sums in, for
example).

They didn't have a zero "0" - is this right?
--
Bill Grey
http://www.billboy.co.uk

Fran said:

EXIF data: WTH?? Silly me, I expected the data returned by
the camera to correspond in some way with the settings I'd
used. More fool me I suppose... The EV settings on my camera
vary in increments of 0.3 from -1.5 through 0 to +1.5; the
white balance settings are: sunny; cloudy; fluorescent 1; fl
2; fl 3; incandescent; auto. I didn't bother fiddling with
anything else except that the flash was turned off. The
results of my fiddlings are at
http://frances.fotopic.net/c357019.html - and as the notes
will tell you the EXIF data's disappeared consequent upon my
cropping away extraneous foreground... Aaaarghhhh!

Fran this is your Fuji 2800Z, yes? Like Kates. The camera records quite
a lot of EXIF data, including f-number, shutter speed, focal length, ISO
setting (effective film speed) and whether flash was used. Is this what
you are looking for?

How are you viewing the EXIF data? PSP 8 will show it to you in a
separate tab on the image information (Shift-I) display. The default is
just image data (I think)and doesn't show all the EXIF info; in
particular it doesn't show "shot conditions" which is what you want.
Check the "shot conditions" box in the tab... The FinePix Viewer
software that comes with the camera will also show you all the EXIF
information.

PSP 8 shouldn't lose the EXIF data, even if you crop the image, at least
it doesn't for me. I am assuming that you haven't saved the image in
another format in between - gif, for instance, will not preserve the
EXIF data. Some editors do lose EXIF off jpegs, though, PSP 7 for one.

None of the pictures on the webpage seem to have EXIF data, but that
could be due to any of the steps taken to publish them. I'm afraid I
can't work out what help you are asking for! The only consistent
problem I can see is movement blur, which (with little ones especially)
you need flash (or a fast film speed) to cure. I guess you were varying
some settings in the first ten pics, but which parameter, and what
values did you use? Maybe I'm being thick.....

On Thu, 2 Dec 2004 19:09:36 +0000, "W. D. Grey" <[email hidden]>

Quoted message said:

In article <[email hidden]>, John Laird
<[email hidden]> writes

Quoted message said:

Any cursory examination of Roman numerals will reveal this
to be quite different in concept (and a complete b*****d to do sums in, for
example).

They didn't have a zero "0" - is this right?

That's right. You only need zero as a "placeholder" when the position of
each numeric digit has significance. The Babylonians are believed to have
pioneered what the Arabic and Indian scholars built on to give our present
system.

If you dig around, there's some interesting theories on how the Arabic
numerals came to be represented as what we now recognise as 1, 2, 3 etc.
All to do with angles and pictorial representations of a hand (representing
5).

--
Pardon our dust... nonsense under construction.

Mail john rather than nospam...

Alan Dicey said:

Fran wrote:
None of the pictures on the webpage seem to have EXIF data, but that
could be due to any of the steps taken to publish them

Click on one of the thumbnails to get the main picture then at the bottom of
the page click on the "image info" button, this will bring up the Exif
data. As Fran says some of it is missing in some of the images.

--

Don`t Worry, Be Happy

Sandy
--

E-Mail:- [email hidden]
Website:- http://www.ftscotland.co.uk
Looking for a webhost? Try http://www.1and1.co.uk/?k_id=2966019

Sandy Birrell said:

Alan Dicey said:

Fran wrote:
None of the pictures on the webpage seem to have EXIF data, but that
could be due to any of the steps taken to publish them

Click on one of the thumbnails to get the main picture then at the bottom of
the page click on the "image info" button, this will bring up the Exif
data. As Fran says some of it is missing in some of the images.

Thanks for that pointer.

Now I am mightily confused. All the pictures except the first two have
full EXIF data: that for the first two seems to be corrupt. As far as I
can see, all the exposure information is there, for instance (and at the
risk of belabouring the obvious)

FNumber 280/100 = f2.8
ExposureProgram 2
ISOSpeedRatings 100 = 100ASA
ShutterSpeedValue 440/100 = 4.4 sec
MeteringMode 5 Probably means "pattern"
Flash 0 = No Flash
FocalLength 600/100 = 6mm, widest setting for the 2800
ColorSpace 1 = this is probably the White Balance

Fran, using FinePix Viewer to view the jpg will interpret these
parameters in terms of the settings on the 2800Z.

Hope this helps!

[email hidden] said...

Quoted message said:

s a decimal this 0.6666 recurring
- it goes on forever; How do you convert that to binary exactly?
However if you store it as 2 divided by 3, the problem goes away.

I understood all the individual words; however their order
flummoxed me. Sorry, I have a total blind spot where numbers
are concerned.
--
I try to be a good example to my children, but they just see
me as a dire warning.

[email hidden] said...

Quoted message said:

Fran, using FinePix Viewer to view the jpg will interpret these
parameters in terms of the settings on the 2800Z.

Ah. So it would be useful if I could find the original CD
that came with the camera...?
--
I try to be a good example to my children, but they just see
me as a dire warning.

Fran said:

[email hidden] said...

Quoted message said:

Fran, using FinePix Viewer to view the jpg will interpret these
parameters in terms of the settings on the 2800Z.

Ah. So it would be useful if I could find the original CD
that came with the camera...?

Er, - - - yes, I think that would be a good idea in general. It
should also have USB drivers and a VCD creator for burning slideshows
onto VCD's so that you can play them on the DVD player.

You can apparantly download the current version (3.2) from the Fuji website;

http://www.fujifilm.co.uk/technical/folder.pl?id=64

You have to register on MyFuji, which involves giving them some contact
info and the serial number and model of your camera. Then you have to
wait while a 65MB download completes. I expect you can get them to send
you a replacement CD, though.

[email hidden] said...

Quoted message said:

You can apparantly download the current version (3.2) from the Fuji website;

http://www.fujifilm.co.uk/technical/folder.pl?id=64

You have to register on MyFuji, which involves giving them some contact
info and the serial number and model of your camera. Then you have to
wait while a 65MB download completes. I expect you can get them to send
you a replacement CD, though.

Thanks Alan.
--
I try to be a good example to my children, but they just see
me as a dire warning.