Darkroom classes

In article , Whisky-dave wrote:

Depending on time frame. Now the tehnical QUALITY is better, where or not
the PHOTOGRAPHY is another matter. Photography is or should be about the
contents of the image not pixel count.

The contents of the image is not dependant on the technique used to create
the image.

The longlevity of the storage has little to do wih the 'skill' of
creation of what you've backed up.

There is no inherent "skill" involved in either technique.

The original point was whether or not Digital was better than film for photography.

And "skill" has no place in that question. It can only pertain to the end
result. Skill play as much a part in both techniques.

Digital is now the best way for archiving, backing up etc.. whether or
not it has any effect on the quality of authors work is something else.

Analog has no effect on the quality of the "author" either.

both film and digital photography use light.

At the point of origin, once it passes through the lens, and hits the
sensor. With digital from then on it has little to do with light but
'number crunching to taste' to get a result.

It's the same. The "photography" part of the process ends when light hits
the sensor or the film. There is no difference.

with film you in lack of light to develop it to enable the effect the
photons had on a chemical reaction. Then you pass light through that to
produce a print, you're still using light to enhance a final print if you
hold back or burn in as aposed to darken or lighten.

"Producing a print" is not a part of photography. The people pushing the
buttons on the express develop machines in your local camera store are not
being photographers when they do.

For me the photo pary stops once it's in digital form, that's when
graphic artisty comes in an a skill of it's own.

It's the same with creating paper prints from negatives. It's an art form
in itself.

An elderly lady at my cmera club used to work in a retouching department
which included colouring black and white photos. That didn't make here a
photograher.

Neither would she be if she was producing paper prints from negatives.

Using a microwave isn't really cooking even if you have to stir halfway
through and add water

Actually, it is. Bad analogy.

Just as digital photography and analog photography both is "photography",
cooking your food in a microwave or in an oven is both "cooking".


--
Sandman[.net]

In article , Eric Stevens
wrote:

Of course things never get lost on hard drives do they.

no they don't.

Oh yes they do. Over the years I have on occasion had complete job
folders just vanish from my archives.

files do not vanish for no reason.

someone deleted them.

No.

either you did and forgot

Each time I got a new job I issued a new job number and opened a new
fold for it. All that happened in that job was subsequently saved in
subfolders. I have been deliberately saving my job files as many of
them are technically very interesting. The archives have been
accumulating for 25 years and passed from one computer to the next.
Over that period I have twice now found that a complete job folder has
vanished. I have no idea what else have vanished. I have no incentive
to delet job files, quite the reverse in fact.

they don't vanish on their own.

someone deleted them.

or someone with access to the computer did and did not inform you.

The only other person with access is my wife. Not only does she have
no incentive but she wouldn't know how to do it anyway.

then that leaves you.

but even if they were deleted, they'd be in a backup. that's what
backups are *for*.

You have to know that a folder is missing before you can restore it.
Otherwise you just backup the archive as it now is, with a missing
folder.

now you know, so pull it from a backup.

In article ,
Whisky-dave wrote:


I was backing up to CD using some utiltiy that came with the burner.
I was watching teh writing logg, god those were excciting days, and notice
some files couldn;t be backed up because the file or folder names were too
long.

that utility was a piece of ****.

In article ,
Whisky-dave wrote:

And some haven't. We have pictures of WWI and WWII and older.

there weren't digital cameras back then.

Yes and those photos exceed the age of any digital photo.

only because digital is new.

yes and 20 year old photos are better than 20 year old digtal from the POV of
quality.

only because digital was in its infancy 20 years ago.

compare early digital photos with the very first film photos. if you
can find any, that is.

Hopefully today digital images should stay around almost indefinatly
as long as they are backup up in some way(s).

they will.

A friends smart phone didn;t survive a dip in the canel.

Digital IS NOT indestructable.

nothing is.

That's the 4th time his phone has taken a dip , removing the batteries and
letting it dry out for a few days, and it springs back to life it's an old
nokia about as smart as my cats arse, ancient technolgy, and I'll admit an
iPhone would probbly stop working for good when it detected it was heading
for a dip.

buy a lottery ticket.

however, it will outlast film and without any degradation whatsoever.

Provided it's reguallry backed up on current media.
That's the theory as yet unproven.

what's to prove? if you have backups, you can't lose the data.

....

Are you saying photography has nothing to do with light ?
of course it does.

both film and digital photography use light.

At the point of origin, once it passes through the lens, and hits the sensor.
With digital from then on it has little to do with light but 'number
crunching to taste' to get a result.

it has everything to do with light, but modeled digitally.

and with film it's chemistry, not light.

with film you in lack of light to develop it to enable the effect the photons
had on a chemical reaction. Then you pass light through that to produce a print,
you're still using light to enhance a final print if you hold back or burn in as
aposed to darken or lighten.

with digital you don't need darkness to process them. that's a *huge*
step forward.

no more changing bags, dark rooms, smelly chemicals that must be fresh,
temperature controls, precise timing, etc. talk about *primitive*.

For me the photo pary stops once it's in digital form, that's when graphic
artisty comes in an a skill of it's own.

a skill which you obviously don't have.

An elderly lady at my cmera club used to work in a retouching department
which included colouring black and white photos. That didn't make here a
photograher.

nobody said it would.

Using a microwave isn't really cooking even if you have to stir halfway through
and add water

it's cooking, just using a different tool.

only the medium on which it's stored is different.

Until viewed.

if someone put a print made from a digital camera and a print made from
a film camera in front of you, you would not be able to tell which was
which (assuming the digital image was reduced in quality to look like
film).

In article , Eric Stevens
wrote:

I'm sure I've had files change attribute by beoming invisible, after a crash.
Both Macs and PC are far more relible now than in the 90s same with whatever
OS, excluding vistor, Melenium 2000 perhaps ;-)

And if you haven't noticed that they have vanished you never include
them in the next umteen backups.

include??

the backups happen automatically. if the file existed, it's backed up.
it's automatically included.

For how far back is it practical to
keep all your old backups?

as far back as needed to have backup copies of anything that you want
to keep.

if you don't need to keep it then it can be discarded.

Apart from that I've had a logic bit reset over night in an HP
calculator. Last thing the previous day it was on. The next morning it
was off. Cosmic rays were the explanation. Stored data is not entirely
reliable.

yes it is.

On 6/28/2014 7:13 PM, Tony Cooper wrote:

snip

nospam's never mentioned if he's married and/or has kids. My guess is
that he doesn't have kids and is waiting for some new process with
which to conceive them (maybe an Apple app) and thinks the old process
is just too much work.


You may owe me a new keyboard.

--
PeterN

On Sat, 28 Jun 2014 16:11:05 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

I'm sure I've had files change attribute by beoming invisible, after a crash.
Both Macs and PC are far more relible now than in the 90s same with whatever
OS, excluding vistor, Melenium 2000 perhaps ;-)

And if you haven't noticed that they have vanished you never include
them in the next umteen backups.

include??

Let me explain it. Every week I give an instruction 'Backup Archive'
and all of Archive is backed up. I keep adding new jobs to Archive and
adding to jobs which are already backed up there. So the backup
instruction is supposed to maintain a copy of all the jobs I have ever
done.

But, for reasons I don't understand, Job 8764 vanishes. That's alright
because I still have a backup copy of Job 8764. The problem is, I
don't know that Job 8764 is missing. So the next backup I do is
lacking Job 8764 as it is no longer there to backup. I still don't
realise that Job 8764 is missing so the backup after the last is still
lacking Job 8764. And so it goes on, until I reach a point where there
are ten backups lacking Job 8764. Still not knowing that Job 8764 is
missing, according to to the backup protocol, I delete the 11th backup
after making the 10th. After all, who needs 11 backups.

Two years later I need to access Job 8764 and only then do I discover
it is missing. Anxiously I search the ten backup copies I have and to
my despair I find there is no backup copy of Job 8764 in the backups
either. It vanished too long ago.

the backups happen automatically. if the file existed, it's backed up.
it's automatically included.

And as I explained above, if it no longer exists it cannot be
included.

For how far back is it practical to
keep all your old backups?

as far back as needed to have backup copies of anything that you want
to keep.

That's a weasel's answer.

My archive file contains 1,123 folders, 16,546 files and occupies
33.8GB. If I was to keep 104 backup copies as my hypothetical example
requires I would need 3.51TB of backup storage (or thereabouts). That
might be practical now (just) but it wasn't when I retired only a few
years ago. In fact 32 bit Windows systems can't manage more than
2.19TB of storage. See
http://www.cnet.com/au/news/wd-break...tb-hard-drive/
I only bought my first 64 bit system relatively recently.

Of course, had I been aware of the risk of losing files and folders
from what appear to be correctly functioning hard drives, I could have
used a more complex backup protocol which might have helped deal with
files that are missing. But I wasn't then aware of the risk.

if you don't need to keep it then it can be discarded.

Apart from that I've had a logic bit reset over night in an HP
calculator. Last thing the previous day it was on. The next morning it
was off. Cosmic rays were the explanation. Stored data is not entirely
reliable.

yes it is.

No it isn't.

Are you really saying that all methods of data storage are absolutely
reliable? All methods have their weaknesses.
--

Regards,

Eric Stevens

In article , Eric Stevens
wrote:

I'm sure I've had files change attribute by beoming invisible, after a
crash.
Both Macs and PC are far more relible now than in the 90s same with
whatever
OS, excluding vistor, Melenium 2000 perhaps ;-)

And if you haven't noticed that they have vanished you never include
them in the next umteen backups.

include??

Let me explain it. Every week I give an instruction 'Backup Archive'
and all of Archive is backed up. I keep adding new jobs to Archive and
adding to jobs which are already backed up there. So the backup
instruction is supposed to maintain a copy of all the jobs I have ever
done.

i know what you meant by include.

you were manually managing backups, which sets you up for problems, as
you found out the hard way.

But, for reasons I don't understand, Job 8764 vanishes. That's alright
because I still have a backup copy of Job 8764. The problem is, I
don't know that Job 8764 is missing. So the next backup I do is
lacking Job 8764 as it is no longer there to backup. I still don't
realise that Job 8764 is missing so the backup after the last is still
lacking Job 8764. And so it goes on, until I reach a point where there
are ten backups lacking Job 8764. Still not knowing that Job 8764 is
missing, according to to the backup protocol, I delete the 11th backup
after making the 10th. After all, who needs 11 backups.

that's yet another flaw in your backup strategy.

if the computer was managing the backups *for* you, you'd have at least
one copy of your files, possibly multiple versions of it.

multiple backups can be coalesced to save space so you don't need a
dozen copies of the same stuff. however, you *do* need at least one
copy offsite, ideally more than one.

Two years later I need to access Job 8764 and only then do I discover
it is missing. Anxiously I search the ten backup copies I have and to
my despair I find there is no backup copy of Job 8764 in the backups
either. It vanished too long ago.

yet another reason why the computer can manage it *for* you and do a
much better job of it.

the backups happen automatically. if the file existed, it's backed up.
it's automatically included.

And as I explained above, if it no longer exists it cannot be
included.

as i explained above, the fact you manually include and exclude files
means you can (and did) make a mistake, with undesirable consequences.

For how far back is it practical to
keep all your old backups?

as far back as needed to have backup copies of anything that you want
to keep.

That's a weasel's answer.

no it isn't.

My archive file contains 1,123 folders, 16,546 files and occupies
33.8GB. If I was to keep 104 backup copies as my hypothetical example
requires I would need 3.51TB of backup storage (or thereabouts). That
might be practical now (just) but it wasn't when I retired only a few
years ago.

it all depends how important the data is to you.

if the value of the data is worth more than a drive (which is almost
always the case) then buy another drive.

In fact 32 bit Windows systems can't manage more than
2.19TB of storage.

that's per single volume and it's a ridiculous limitation.

os x can access up to 8 exabytes per volume, regardless of 32/64 bit.

anyway, nothing prevents someone from having multiple volumes, or if
they're truly masochistic, optical discs.

See
http://www.cnet.com/au/news/wd-break...tb-hard-drive/
I only bought my first 64 bit system relatively recently.

Of course, had I been aware of the risk of losing files and folders
from what appear to be correctly functioning hard drives, I could have
used a more complex backup protocol which might have helped deal with
files that are missing. But I wasn't then aware of the risk.

more simple, you mean.

let the computer worry about tracking what has changed and what is
unique across multiple snapshots.

if you don't need to keep it then it can be discarded.

Apart from that I've had a logic bit reset over night in an HP
calculator. Last thing the previous day it was on. The next morning it
was off. Cosmic rays were the explanation. Stored data is not entirely
reliable.

yes it is.

No it isn't.

Are you really saying that all methods of data storage are absolutely
reliable? All methods have their weaknesses.

what i'm saying is that files don't delete themselves, and they don't.

On Sun, 29 Jun 2014 02:20:59 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

I'm sure I've had files change attribute by beoming invisible, after a
crash.
Both Macs and PC are far more relible now than in the 90s same with
whatever
OS, excluding vistor, Melenium 2000 perhaps ;-)

And if you haven't noticed that they have vanished you never include
them in the next umteen backups.

include??

Let me explain it. Every week I give an instruction 'Backup Archive'
and all of Archive is backed up. I keep adding new jobs to Archive and
adding to jobs which are already backed up there. So the backup
instruction is supposed to maintain a copy of all the jobs I have ever
done.

i know what you meant by include.

From what you have written below, I don't think you understand what I
mean by 'include'.

you were manually managing backups, which sets you up for problems, as
you found out the hard way.

I don't do it manually. I have an automatic command file which tells
2nd Copy to do it. Backing up the archive happens every week without
intervention from me.

But, for reasons I don't understand, Job 8764 vanishes. That's alright
because I still have a backup copy of Job 8764. The problem is, I
don't know that Job 8764 is missing. So the next backup I do is
lacking Job 8764 as it is no longer there to backup. I still don't
realise that Job 8764 is missing so the backup after the last is still
lacking Job 8764. And so it goes on, until I reach a point where there
are ten backups lacking Job 8764. Still not knowing that Job 8764 is
missing, according to to the backup protocol, I delete the 11th backup
after making the 10th. After all, who needs 11 backups.

that's yet another flaw in your backup strategy.

What is the flaw?

if the computer was managing the backups *for* you, you'd have at least
one copy of your files, possibly multiple versions of it.

I don't see why it matters whether it's me or the computer which
initiates the backup. From then on, the process is exactly the same.

multiple backups can be coalesced to save space so you don't need a
dozen copies of the same stuff. however, you *do* need at least one
copy offsite, ideally more than one.

Bear in mind these backups date back to the days of MS-DOS.

Two years later I need to access Job 8764 and only then do I discover
it is missing. Anxiously I search the ten backup copies I have and to
my despair I find there is no backup copy of Job 8764 in the backups
either. It vanished too long ago.

yet another reason why the computer can manage it *for* you and do a
much better job of it.

What form of management do you have in mind?

the backups happen automatically. if the file existed, it's backed up.
it's automatically included.

And as I explained above, if it no longer exists it cannot be
included.

as i explained above, the fact you manually include and exclude files
means you can (and did) make a mistake, with undesirable consequences.

But I don't manually include and exclude files. They are in a common
folder and I backup them all.

For how far back is it practical to
keep all your old backups?

as far back as needed to have backup copies of anything that you want
to keep.

That's a weasel's answer.

no it isn't.

Give me a practical number.

My archive file contains 1,123 folders, 16,546 files and occupies
33.8GB. If I was to keep 104 backup copies as my hypothetical example
requires I would need 3.51TB of backup storage (or thereabouts). That
might be practical now (just) but it wasn't when I retired only a few
years ago.

it all depends how important the data is to you.

But that's only 10 weeks of backups which occupies 3.51 TB. I've got
more than 20 years worth of job files. To back them up every week
would take (I conservatively estimate) 12 TB.

if the value of the data is worth more than a drive (which is almost
always the case) then buy another drive.

On those figures I would need several drives.

In fact 32 bit Windows systems can't manage more than
2.19TB of storage.

that's per single volume and it's a ridiculous limitation

Ridiculous or not, that's 'all' that it can manage.

os x can access up to 8 exabytes per volume, regardless of 32/64 bit.

THat's later but the earlier versions could only manage 2 TB with 8 TB
and 16 TB coming later. See http://support.apple.com/kb/ht2422

anyway, nothing prevents someone from having multiple volumes, or if
they're truly masochistic, optical discs.

See
http://www.cnet.com/au/news/wd-break...tb-hard-drive/
I only bought my first 64 bit system relatively recently.

Of course, had I been aware of the risk of losing files and folders
from what appear to be correctly functioning hard drives, I could have
used a more complex backup protocol which might have helped deal with
files that are missing. But I wasn't then aware of the risk.

more simple, you mean.

let the computer worry about tracking what has changed and what is
unique across multiple snapshots.

That's practical now but the earlier MS backup systems were not user
friendly

if you don't need to keep it then it can be discarded.

Apart from that I've had a logic bit reset over night in an HP
calculator. Last thing the previous day it was on. The next morning it
was off. Cosmic rays were the explanation. Stored data is not entirely
reliable.

yes it is.

No it isn't.

Are you really saying that all methods of data storage are absolutely
reliable? All methods have their weaknesses.

what i'm saying is that files don't delete themselves, and they don't.

One day it may happen to you.
--

Regards,

Eric Stevens

In article , Eric Stevens
wrote:

I'm sure I've had files change attribute by beoming invisible, after a
crash.
Both Macs and PC are far more relible now than in the 90s same with
whatever
OS, excluding vistor, Melenium 2000 perhaps ;-)

And if you haven't noticed that they have vanished you never include
them in the next umteen backups.

include??

Let me explain it. Every week I give an instruction 'Backup Archive'
and all of Archive is backed up. I keep adding new jobs to Archive and
adding to jobs which are already backed up there. So the backup
instruction is supposed to maintain a copy of all the jobs I have ever
done.

i know what you meant by include.

From what you have written below, I don't think you understand what I
mean by 'include'.

i do.

you were manually managing backups, which sets you up for problems, as
you found out the hard way.

I don't do it manually. I have an automatic command file which tells
2nd Copy to do it. Backing up the archive happens every week without
intervention from me.

does it automatically include it or not?

you said you keep adding new jobs to archive. if it was automatic, you
would not need to add anything. it would be done *for* you.

But, for reasons I don't understand, Job 8764 vanishes. That's alright
because I still have a backup copy of Job 8764. The problem is, I
don't know that Job 8764 is missing. So the next backup I do is
lacking Job 8764 as it is no longer there to backup. I still don't
realise that Job 8764 is missing so the backup after the last is still
lacking Job 8764. And so it goes on, until I reach a point where there
are ten backups lacking Job 8764. Still not knowing that Job 8764 is
missing, according to to the backup protocol, I delete the 11th backup
after making the 10th. After all, who needs 11 backups.

that's yet another flaw in your backup strategy.

What is the flaw?

manually managing backups.

if the computer was managing the backups *for* you, you'd have at least
one copy of your files, possibly multiple versions of it.

I don't see why it matters whether it's me or the computer which
initiates the backup. From then on, the process is exactly the same.

because you can easily make mistakes, and did.

the computer will make sure there is at least one copy of anything,
without any effort.

multiple backups can be coalesced to save space so you don't need a
dozen copies of the same stuff. however, you *do* need at least one
copy offsite, ideally more than one.

Bear in mind these backups date back to the days of MS-DOS.

there weren't very many options back then.

now there are.

Two years later I need to access Job 8764 and only then do I discover
it is missing. Anxiously I search the ten backup copies I have and to
my despair I find there is no backup copy of Job 8764 in the backups
either. It vanished too long ago.

yet another reason why the computer can manage it *for* you and do a
much better job of it.

What form of management do you have in mind?

let the computer do it.

the backups happen automatically. if the file existed, it's backed up.
it's automatically included.

And as I explained above, if it no longer exists it cannot be
included.

as i explained above, the fact you manually include and exclude files
means you can (and did) make a mistake, with undesirable consequences.

But I don't manually include and exclude files. They are in a common
folder and I backup them all.

if you did that then nothing would be missing.

and how do you reconcile that you said you add jobs to be backed up?

For how far back is it practical to
keep all your old backups?

as far back as needed to have backup copies of anything that you want
to keep.

That's a weasel's answer.

no it isn't.

Give me a practical number.

there is no number.

the computer maintains at least one copy of your files automatically.

if the backup volume fills, you get a bigger one.

My archive file contains 1,123 folders, 16,546 files and occupies
33.8GB. If I was to keep 104 backup copies as my hypothetical example
requires I would need 3.51TB of backup storage (or thereabouts). That
might be practical now (just) but it wasn't when I retired only a few
years ago.

it all depends how important the data is to you.

But that's only 10 weeks of backups which occupies 3.51 TB. I've got
more than 20 years worth of job files. To back them up every week
would take (I conservatively estimate) 12 TB.

if the value of the data is worth more than a drive (which is almost
always the case) then buy another drive.

On those figures I would need several drives.

In fact 32 bit Windows systems can't manage more than
2.19TB of storage.

that's per single volume and it's a ridiculous limitation

Ridiculous or not, that's 'all' that it can manage.

os x can access up to 8 exabytes per volume, regardless of 32/64 bit.

THat's later but the earlier versions could only manage 2 TB with 8 TB
and 16 TB coming later. See http://support.apple.com/kb/ht2422

2 tb was with os x 10.1, which came out in 2001. there were no 2 tb
drives then, so it was effectively unlimited.

16 tb was available with 10.3, which was 2003 and there weren't any 16
tb disks then and there still aren't any now, so it's still effectively
unlimited.

it's now much higher than that, even though 8 exabyte hard drives won't
exist for a very, very long time.

for any system to still be limited to 2 tb is laughable.

anyway, nothing prevents someone from having multiple volumes, or if
they're truly masochistic, optical discs.

See
http://www.cnet.com/au/news/wd-break...tb-hard-drive/
I only bought my first 64 bit system relatively recently.

Of course, had I been aware of the risk of losing files and folders
from what appear to be correctly functioning hard drives, I could have
used a more complex backup protocol which might have helped deal with
files that are missing. But I wasn't then aware of the risk.

more simple, you mean.

let the computer worry about tracking what has changed and what is
unique across multiple snapshots.

That's practical now but the earlier MS backup systems were not user
friendly

they still aren't.

if you don't need to keep it then it can be discarded.

Apart from that I've had a logic bit reset over night in an HP
calculator. Last thing the previous day it was on. The next morning it
was off. Cosmic rays were the explanation. Stored data is not entirely
reliable.

yes it is.

No it isn't.

Are you really saying that all methods of data storage are absolutely
reliable? All methods have their weaknesses.

what i'm saying is that files don't delete themselves, and they don't.

One day it may happen to you.

no it won't.

files do *not* delete themselves. period.

they may get deleted by accident, and i've certainly done that
(everyone has) but that's very different.

when that happens, i just pull the files from a backup. no big deal.