Correcting Colour Balance On Old Negatives

[Java Jive]

Apologies for the cross-posting - this is a post about a new problem
that might be solved either using Linux or Windows software, I have
both available as below.

Linux: GIMP
Windows 7: IrfanView
Paint
Paint Shop Pro 8

The problem concerns the following picture and a few others like it,
all taken with a Brownie Starmite camera when I was a boy, this one
being of the salmon ladder at the hydro dam at Pitlochry, Scotland.

This is the original scan of the negative corrected to be positive ...

www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-OriginalScan.png

... this the above put through the Linux program pnnorm to improve its
saturation ...

www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-Pnnormed.png

... and this is the above after applying colour correction to bring
the white of the clouds to true white, in other words 255,255,255:

www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-PnormColourCorrected.png

As you can see, the problem is that the greys in the clouds still have
a marked reddish cast. If instead of correcting to bring whites to
true white, I correct to bring these greys to true grey, then nothing
else in the picture looks right because of the strong cyan cast that
results. Although the problem doesn't look so bad in the original
scan before applying pnnorm, it's still definitely there, so it's not
pnnorm's fault, but the program, while improving the rest of the
picture, has made the problem worse.

I'm not sure what has caused this, but presumably it's something to do
with the aging of the film over the intervening half century that has
caused the pigments to fade differentially according to their original
density in the picture, but BTAIM ...

Using any of the software listed above, can anyone suggest how to
correct the greys in the clouds to remove the red cast, while leaving
the rest of the picture alone? I don't mind a reasonable amount of
effort, say an hour per picture for that alone, but don't want to
spend much longer than that.
--
========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

[Big Al]

No real help but I did some 900 slides in a dedicated slide scanner and took year/s to do. I corrected as much in scanning software but
yes, I did have to do some post fix. Luckily my daughter had the full version of photoshop cs5 (I think) installed for her college.
She(we) bought it for $700 US.
ANyway it had a auto mode for color correction and it wasn't too bad. I got a lot done that way.

But ultimately to me at least now this is a shotgun solution in GIMP. You can play with hue and brightness/contrast. Levels does a good
job over contast/brightness. There also is a color adjust in GIMP that lets you adjust the 3 R G B hues.

I'm no expert and I let her do the tough ones. She could whip up a correction in seconds. Of course she's working for an ad agency doing
touchup etc now professionally and is damn good at it. But it takes trial and error for me. Just remember what you did, like write down what
entry you went into and what numbers you adjusted to. That way you can replicate it. Photoshop had a macro you could write so I did that
for all the Kodachrome film. etc.



Al.

--
Linux Mint Cinnamon 20.0 64bit, Dell Inspiron 5570, Quad Core i7-8550U, 16G Memory

[William Unruh]

On 2020-12-21, Java Jive <ja...@evij.com.invalid> wrote:
> Apologies for the cross-posting - this is a post about a new problem
> that might be solved either using Linux or Windows software, I have
> both available as below.
>
> Linux: GIMP
> Windows 7: IrfanView
> Paint
> Paint Shop Pro 8
>
> The problem concerns the following picture and a few others like it,
> all taken with a Brownie Starmite camera when I was a boy, this one
> being of the salmon ladder at the hydro dam at Pitlochry, Scotland.
>
> This is the original scan of the negative corrected to be positive ...
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-OriginalScan.png
>
> ... this the above put through the Linux program pnnorm to improve its
> saturation ...
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-Pnnormed.png
>
> ... and this is the above after applying colour correction to bring
> the white of the clouds to true white, in other words 255,255,255:
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-PnormColourCorrected.png
>
> As you can see, the problem is that the greys in the clouds still have
> a marked reddish cast. If instead of correcting to bring whites to

I tried colour curves in Gimp, and operated on the red curve. I lowered
the brightest by about 12%, (255->230, 247->248,182->104, 98->54)Now you
might complain that it is too bluish, but I find it pretty well
balanced, never having seen the original scene. The vegetation on the
bank is brought out, The lock itself is ,maybe a bit dark. but the far
bank and house is not. The clouds are shades of grey, and the sky is
blue.

Anyway, play around with the Colours->Curves.
You should certainly need less than a hour.

[Mayayana]

"Java Jive" <ja...@evij.com.invalid> wrote

|
| Linux: GIMP
| Windows 7: IrfanView
| Paint
| Paint Shop Pro 8
|

It's not a very good picture, anyway, but IV color correction
will help a lot and easily. Reduce red by a lot, reduce blue
moderately, lower gamma, add a bit of contrast and saturation.

PSP8 will give you more control and maybe more options. I don't
know about GIMP. I gave up on that a long time ago. It probably
works pretty well, but it's always been funky, with non-standard
menus, and the last I saw they still didn't have an MDI UI.
(multiple document interface) They only managed to make toolbars
dockable.

[Mike]

In article <v322uftev4su757e7...@4ax.com>,

Java Jive <ja...@evij.com.invalid> wrote:

>This is the original scan of the negative corrected to be positive ...

How did you "correct" the negative? Scan it, then load it in
GIMP and go "Colours -> Invert -> Yeahthat'lldo?" :)

If it's a black and white negative, or colour transparency, that
will mostly work, as the film substrate is clear.

Sadly, for colour negatives, the film base is some varying shade of
orangeness which puts a weird cyan-green cast on your "inverted"
picture. So you can't just reverse the colours.

I scanned a lot of negative strip film (35mm and 110) with a
dedicated USB scanner, and the supplied software had different
profiles for different film makes/brands which went a LONG way to
undoing the colour errors. I did compare "raw scan, pretend it's
a transparency! Then I'll fix it in GIMP" with letting the
software do it at time of scanning.

Best result was let the software do it at time of scan -- it was
SilverFast, I think?

--
--------------------------------------+------------------------------------
Mike Brown: mjb[-at-]signal11.org.uk | http://www.signal11.org.uk

[Savageduck]

On Dec 21, 2020, Java Jive wrote
(in article<v322uftev4su757e7...@4ax.com>):

I took a look at these images, and it seems that your problem starts with an old, not well stored negative. Then as you have said these images were shot with a marginal camera/lens in your youth.

I tried to correct the color cast with several software tools I have, and I have struggled to get what I would consider an acceptable rendition. That said, here is a side-by-side comparison of what I was able to do vs your original.

<https://www.dropbox.com/s/bt98jaqz35kafmw/SalmonLadder-Comparison.jpg>

Personally I would say that this image would be best presented as a monochrome/B&W.

--
Regards,
Savageduck

[Big Al]

Not a bad job.

[Martin Gregorie]

+1




--
--
Martin | martin at
Gregorie | gregorie dot org

[Rene Lamontagne]

Good stuff, Pretty damn nice piece of work

Rene

[Peter Jason]

On Mon, 21 Dec 2020 21:20:45 +0000, Java Jive <ja...@evij.com.invalid>
wrote:

For this & similar images might require laborious sectioning, then
adjusting. (Photoshop)

A crude rapid trial to show possibilities.
https://postimg.cc/MXm8Y4m5
Note the sky/clouds, and ladder lightening.

I have adjusted many old slides for friends, usually taken in the
1970s with cheap stock, and the fixing can be a rapid one adjustment.
For some slides you can raise another person previously hidden (to
everybody's amazment).
Of course it's labour intensive, though automation might be possible
within one set of shots. Careful grouping might pay off.
Beware of old cardboard slides in that the board can become friable
releasing small fibres needed to be brushed away before scanning. Over
time some can become imbedded into the emulsion.

[William Unruh]

On 2020-12-22, Rene Lamontagne <rla...@shaw.ca> wrote:
> On 2020-12-21 6:19 p.m., Big Al wrote:
>> On 12/21/20 7:12 PM, this is what Savageduck wrote:
>>> On Dec 21, 2020, Java Jive wrote
>>> (in article<v322uftev4su757e7...@4ax.com>):
>>>

>>> I tried to correct the color cast with several software tools I have,
>>> and I have struggled to get what I would consider an acceptable
>>> rendition. That said, here is a side-by-side comparison of what I was
>>> able to do vs your original.
>>>
>>> <https://www.dropbox.com/s/bt98jaqz35kafmw/SalmonLadder-Comparison.jpg>
>>>

And this:
www.theory.physics.ubc.ca/SalmonLadderAtPitlochry-Pnnormed-adjust.png
is less than 5 min work on Gimp using the Colours->Curves tool, basically
adjusting the red downall across the spectrum, with even max red being
reduced by about 20%

[Java Jive]

On Tue, 22 Dec 2020 01:45:26 -0000 (UTC), William Unruh
<un...@invalid.ca> wrote:

> On 2020-12-22, Rene Lamontagne <rla...@shaw.ca> wrote:
> > On 2020-12-21 6:19 p.m., Big Al wrote:
> >> On 12/21/20 7:12 PM, this is what Savageduck wrote:
> >>> On Dec 21, 2020, Java Jive wrote
> >>> (in article<v322uftev4su757e7...@4ax.com>):
> >>>
> >>> I tried to correct the color cast with several software tools I have,
> >>> and I have struggled to get what I would consider an acceptable
> >>> rendition. That said, here is a side-by-side comparison of what I was
> >>> able to do vs your original.
> >>>
> >>> <https://www.dropbox.com/s/bt98jaqz35kafmw/SalmonLadder-Comparison.jpg>

Thanks, that's certainly better than my fairly crude attempt based on
getting the white of the clouds to be truly white, but the greys still
look pinkish to me.

> And this:
> www.theory.physics.ubc.ca/SalmonLadderAtPitlochry-Pnnormed-adjust.png
> is less than 5 min work on Gimp using the Colours->Curves tool, basically
> adjusting the red downall across the spectrum, with even max red being
> reduced by about 20%

Sadly, because I really wanted to see this, a 404!

[Java Jive]

Very good, in particular, the clouds are perfect. Can I ask, how many
different sections/selections did you divide the picture into?

> I have adjusted many old slides for friends, usually taken in the
> 1970s with cheap stock, and the fixing can be a rapid one adjustment.
> For some slides you can raise another person previously hidden (to
> everybody's amazment).

Yes, around a year ago I finished scanning my way through an old
family trunk containing documents going back at least to the reign of
Queen Anne. There were many old photographs among these, many of
which required a week's work each, and some which are effectively
beyond realistic recovery. This is an example of one I'd really like
to complete, because I've been able to do most of the rest of it, but
there's a fold right across the picture (from the angle of it,
accidental, probably as the trunk was being moved around). I was able
to remove the part of it that falls across the parade ground, but not
the part that falls across the parading soldiers. There is also some
photographic degradation in the trees at the back of the photo on the
right hand side, and it's also over-exposed, but I'm less concerned
about these, it's the officers and men of the regiment that I'd like
to restore as well as possible, because it's quite an important family
document for my ancestry.

I've tried using the scratch removal tool in PSP, but it's a very
cludgy tool that sometimes works brilliantly, but sometimes makes no
difference to the visibility of the fault, or even makes it worse, and
this is one of the latter situations. I've also tried copying pixels
line by line from a good line just above or below the fault, but it's
terribly confusing because when one is zoomed in to do this sort of
work, one can't see the effect on the overall picture, and so makes
mistakes, and it was taking so long to get effectively nowhere, that
eventually I had to abandon it and leave the photo half done, as you
see it here:

www.macfh.co.uk/Temp/19091109ColMacfarlaneBidsFarewellToTheKOSB.png

> Of course it's labour intensive, though automation might be possible
> within one set of shots. Careful grouping might pay off.
> Beware of old cardboard slides in that the board can become friable
> releasing small fibres needed to be brushed away before scanning. Over
> time some can become imbedded into the emulsion.

Tell me about it! When scanning my slide box, including the Ben
Cruachan slides previously discussed, this was a constant problem, not
even waving them near a vacuum cleaner nozzle would remove them (I
even lost one neg into it, but fortunately an unimportant one). I
suspect that it might be possible to remove this and other embedded
dust from the negs or slides by removing them from the cardboard
holders, putting them back into a final bath of the development
process, and agitating them to wash off the dust, but do not have the
facilities to do this. So tedious software removal seems tobe the only
practical answer.

[Java Jive]

On Mon, 21 Dec 2020 22:52:36 +0000 (GMT), m...@signal11.invalid (Mike)
wrote:

> In article <v322uftev4su757e7...@4ax.com>,
> Java Jive <ja...@evij.com.invalid> wrote:
>
> >This is the original scan of the negative corrected to be positive ...
>
> How did you "correct" the negative? Scan it, then load it in
> GIMP and go "Colours -> Invert -> Yeahthat'lldo?" :)

Not quite, I did it in PSP.

> If it's a black and white negative, or colour transparency, that
> will mostly work, as the film substrate is clear.
>
> Sadly, for colour negatives, the film base is some varying shade of
> orangeness which puts a weird cyan-green cast on your "inverted"
> picture. So you can't just reverse the colours.
>
> I scanned a lot of negative strip film (35mm and 110) with a
> dedicated USB scanner, and the supplied software had different
> profiles for different film makes/brands which went a LONG way to
> undoing the colour errors. I did compare "raw scan, pretend it's
> a transparency! Then I'll fix it in GIMP" with letting the
> software do it at time of scanning.
>
> Best result was let the software do it at time of scan -- it was
> SilverFast, I think?

All well and good, but too late for me, because I did this before
moving house getting on for ten years ago (initially in case anything
happened to the photos in storage, but then discovered that actually
their ongoing degradation was as much or more of a danger), and I
didn't have any fancy software, just the scanner software and
bog-standard graphics programs like GIMP and PSP.

[Andy Burns]

Java Jive wrote:

> there's a fold right across the picture (from the angle of it,
> accidental, probably as the trunk was being moved around). I was able
> to remove the part of it that falls across the parade ground, but not
> the part that falls across the parading soldiers.

Have a look at "liquid rescale" I think when I experimented with it over
13 years ago, it was a standalone program, it was a way to rescale an
image by removing the "boring" parts of an image, rather than linearly
squashing the whole thing.

It looks like it's a gimp filter now, and you can paint an overlay layer
to tell it which bits of the image are "interesting"

I only have one sample from when I tested it

<http://adslpipe.co.uk/photos/liquid.html>

the large image is the original, the 2nd image is a normal rescale in X
only, the 3rd image was a liquid rescale by the same factor, which
allowed it to keep varying amounts of each part of the image, based on
(I think) the amount of entropy in each vertical slice.

It might be a wild shot, but perhaps the version in gimp would let you
eliminate the creased section by emphasising everything but the crease?

[Sjouke Burry]

Unable to connect, link error

[William Unruh]

On 2020-12-22, Java Jive <ja...@evij.com.invalid> wrote:
> On Tue, 22 Dec 2020 01:45:26 -0000 (UTC), William Unruh
><un...@invalid.ca> wrote:
>
>> On 2020-12-22, Rene Lamontagne <rla...@shaw.ca> wrote:
>> > On 2020-12-21 6:19 p.m., Big Al wrote:
>> >> On 12/21/20 7:12 PM, this is what Savageduck wrote:
>> >>> On Dec 21, 2020, Java Jive wrote
>> >>> (in article<v322uftev4su757e7...@4ax.com>):
>> >>>
>> >>> I tried to correct the color cast with several software tools I have,
>> >>> and I have struggled to get what I would consider an acceptable
>> >>> rendition. That said, here is a side-by-side comparison of what I was
>> >>> able to do vs your original.
>> >>>
>> >>> <https://www.dropbox.com/s/bt98jaqz35kafmw/SalmonLadder-Comparison.jpg>
>
> Thanks, that's certainly better than my fairly crude attempt based on
> getting the white of the clouds to be truly white, but the greys still
> look pinkish to me.
>
>> And this:
>> www.theory.physics.ubc.ca/SalmonLadderAtPitlochry-Pnnormed-adjust.png
>> is less than 5 min work on Gimp using the Colours->Curves tool, basically
>> adjusting the red downall across the spectrum, with even max red being
>> reduced by about 20%
>
> Sadly, because I really wanted to see this, a 404!

Sorry-- a whole series of screwups. It should be there now.

[William Unruh]

On 2020-12-22, Sjouke Burry <burrynu...@ppllaanneett.nnll> wrote:
> On 22.12.20 2:45, William Unruh wrote:

...

>> And this:
>> www.theory.physics.ubc.ca/SalmonLadderAtPitlochry-Pnnormed-adjust.png
>> is less than 5 min work on Gimp using the Colours->Curves tool, basically
>> adjusting the red downall across the spectrum, with even max red being
>> reduced by about 20%
>>
> Unable to connect, link error

Corrected now. Sorry.

[William Unruh]

On 2020-12-22, William Unruh <un...@invalid.ca> wrote:
> On 2020-12-22, Java Jive <ja...@evij.com.invalid> wrote:
>> On Tue, 22 Dec 2020 01:45:26 -0000 (UTC), William Unruh

>>> And this:
>>> www.theory.physics.ubc.ca/SalmonLadderAtPitlochry-Pnnormed-adjust.png
>>> is less than 5 min work on Gimp using the Colours->Curves tool, basically
>>> adjusting the red downall across the spectrum, with even max red being
>>> reduced by about 20%
>>
>> Sadly, because I really wanted to see this, a 404!
>
> Sorry-- a whole series of screwups. It should be there now.

I tried something even simpler-- I worked on the original and
adjusted RGB linearly, but displaced
the origins and final point. Here is what I came up with.Not all that
vivid, but then I suspect that the original 40(?) years ago was not all
that vivid either. Of course the jpeg could have something to do with
this as well. The blue and green both seem to have decayed at high
levels and increased at low., and the
red, if anything increased .
The grass on the far bank above the retaining "wall" is not as green as
in my last attempt. Not sure which is "truer"
www.theory.physics.ubc.ca/SalmonLadderAtPitlochry-OriginalScan-adjust.png

[Java Jive]

On Tue, 22 Dec 2020 15:30:29 -0000 (UTC), William Unruh

Thanks again. IMHO, your second effort is the better of the two.
Thanks particularly for showing the GIMP dialog box settings, I'll see
if I can replicate that. I'm less familiar with it than PST, but what
you've shown looks understandable enough.

[Andy Burns]

jetjock wrote:

> Photoshopped.jpg (0/1)


Attachments are not going to make it to [m]any users, you'll need to
upload it somewhere and provide a link.

[Peter Jason]

On Tue, 22 Dec 2020 12:56:19 +0000, Java Jive <ja...@evij.com.invalid>

Only two, original & the large square outline top left. The clouds
were adjusted with the "Levels" box and the red factor reduced.
Of course the trees are too green but the small house has its red roof
OK.
PShop has a "lasso" tool that can crawl around select image boundaries
for subsequent adjustment.
The fish ladder was adjusted with the "Dodge" (lightening) tool that
like a brush can be swept over to lighten the desired area.
Other areas might be like treated, with colour adj applied as well. Of
course it takes a lot of work. I used Photoshop, though PShop
Elements might be just as good.

This image is difficult because it's overexposed and contrasty. I
would engage an expert to fix it. An expert might have a specialty
scanner and lots of experience.
https://postimg.cc/1gM1rnZB

>
>> Of course it's labour intensive, though automation might be possible
>> within one set of shots. Careful grouping might pay off.
>> Beware of old cardboard slides in that the board can become friable
>> releasing small fibres needed to be brushed away before scanning. Over
>> time some can become imbedded into the emulsion.
>
>Tell me about it! When scanning my slide box, including the Ben
>Cruachan slides previously discussed, this was a constant problem, not
>even waving them near a vacuum cleaner nozzle would remove them (I
>even lost one neg into it, but fortunately an unimportant one). I
>suspect that it might be possible to remove this and other embedded
>dust from the negs or slides by removing them from the cardboard
>holders, putting them back into a final bath of the development
>process, and agitating them to wash off the dust, but do not have the
>facilities to do this. So tedious software removal seems tobe the only
>practical answer.

Perhaps some expert could shave off some of the dust-contaminated
surface, but I have no experience here.

[Java Jive]

On Mon, 21 Dec 2020 21:20:45 +0000, Java Jive <ja...@evij.com.invalid>
wrote:
>

> This is the original scan of the negative corrected to be positive ...
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-OriginalScan.png
>
> ... this the above put through the Linux program pnnorm to improve its
> saturation ...
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-Pnnormed.png
>
> ... and this is the above after applying colour correction to bring
> the white of the clouds to true white, in other words 255,255,255:
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-PnormColourCorrected.png

Thanks to all who replied, apologies for slowness in replying, and the
best of Christmases to you all in these difficult times.

In the end, I investigated GIMP, but finally did the work in
PaintShopPro, not because GIMP couldn't've done it, because it's so
unfamiliar to me that it's a struggle even to find the basics like how
to find out what shade in terms of RGB a particular point in the photo
is, so that I couldn't find out if what I was doing was working as I
expected.

What I did in PSP was this:

1 Colour corrected all to make highlights of the clouds white.

2 Selected all of the sky, and further colour corrected to make the
midtones of the clouds grey.

3 Inverted the selection, so now everything except the sky was
selected, and colour corrected to bring the gable end of the building
on the opposite shore to white.

4 Selected the salmon ladder in foreground and lightened somewhat

This is the result - it's never going to be the greatest of
pictures, but I was a boy of 10-12 years old and it's a family memory:
www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-Final.png

[Mayayana]

"Java Jive" <ja...@evij.com.invalid> wrote

| > www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-PnormColourCorrected.png
|

I think you're better off to use the "hand tools"
to alter RGB, brightness, etc. The file you ended up
with is still very pink. Below is an alteration that added
a bit of contrast, reduced red much more, and reduced
blue somewhat. (I clipped it to get pictr.com
to accept the size.)

https://pictr.com/image/7WvEwv

The trouble is there's not a lot of data to work with.
But if you fiddle with hand settings rather than using
auto-features you can quickly find out how much
improvement is possible with the data you have.

[William Unruh]

On 2020-12-25, Java Jive <ja...@evij.com.invalid> wrote:
> On Mon, 21 Dec 2020 21:20:45 +0000, Java Jive <ja...@evij.com.invalid>
> wrote:

...

>
> What I did in PSP was this:
>
> 1 Colour corrected all to make highlights of the clouds white.
>
> 2 Selected all of the sky, and further colour corrected to make the
> midtones of the clouds grey.
>
> 3 Inverted the selection, so now everything except the sky was
> selected, and colour corrected to bring the gable end of the building
> on the opposite shore to white.
>
> 4 Selected the salmon ladder in foreground and lightened somewhat
>
> This is the result - it's never going to be the greatest of
> pictures, but I was a boy of 10-12 years old and it's a family memory:
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-Final.png

The question is whether you want the picture to look like it did when
you first got back the developed prints, or do you want it to look "more
real". Taking bits and pieces of the print and altering them is almost
certainly not making it look like what it was. ( And also you probably
should not have scanned it into jpeg-- jpeg throws away information and
bleeds one pixel into it neighbour, making colour correction and edges
hard to do. Of course getting it to look like it did when you were 9 may
not be the purpose.

[J. P. Gilliver (John)]

On Fri, 25 Dec 2020 at 22:32:23, William Unruh <un...@invalid.ca> wrote
(my responses usually follow points raised):
[]

>The question is whether you want the picture to look like it did when
>you first got back the developed prints, or do you want it to look "more
>real". Taking bits and pieces of the print and altering them is almost
>certainly not making it look like what it was. ( And also you probably
>should not have scanned it into jpeg-- jpeg throws away information and
>bleeds one pixel into it neighbour, making colour correction and edges
>hard to do. Of course getting it to look like it did when you were 9 may
>not be the purpose.
>

I am surprised that, by now, the fading characteristics of the various
film stocks aren't pretty well known by now - even including the effects
of different parts having different exposures (i. e. the algorithm
knowing that, say, a red area causes the blue and green - or magenta and
cyan, etc. - layers to fade in a specific way). Surely it's not beyond
the wit of man (or algorithm) to automate _most_ of the correction
needed now, maybe offering several options, rather than a human having
to manually tweak, especially different patches of the same image?

I guess it's money, as usual - not enough money in it; lots that need
correcting (including movie material), but in small amounts. Still, it
does seem odd nobody's released anything by now. The movie companies
must have something (I remember reading quite a few years ago that the
Star Trek masters had needed restoration for example), but maybe they're
guarding their software jealously. (Or it needs so long per frame - but
surely processing power should have conquered that by now.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Eve had an Apple, Adam had a Wang...

[nospam]

In article <e9S0W2FN...@255soft.uk>, J. P. Gilliver (John)

<G6...@255soft.uk> wrote:

> I am surprised that, by now, the fading characteristics of the various
> film stocks aren't pretty well known by now - even including the effects
> of different parts having different exposures (i. e. the algorithm
> knowing that, say, a red area causes the blue and green - or magenta and
> cyan, etc. - layers to fade in a specific way). Surely it's not beyond
> the wit of man (or algorithm) to automate _most_ of the correction
> needed now, maybe offering several options, rather than a human having
> to manually tweak, especially different patches of the same image?

the fading is not consistent, nevertheless, restoration has been
automated and works quite well. it just requires the proper tools,
which can even colourize b/w photos, if desired.

[Mike]

In article <e9S0W2FN...@255soft.uk>,
J. P. Gilliver (John) <G6...@255soft.uk> wrote:

>Surely it's not beyond
>the wit of man (or algorithm) to automate _most_ of the correction
>needed now, maybe offering several options, rather than a human having
>to manually tweak, especially different patches of the same image?

There are AI systems that can take a black and white picture as input,
and work out what the colours probably were (given a big catalogue of
"what things look like" to work with as learning input).

Just as there are AI processing tools that can actually implement
the old "CSI: BS!" stuff where a pixellated grainy photograph can
be turned into a high-res detailed version at a moment's notice.

There are AI systems that given a photograph can take a good
stab at what country it was taken in (no peeking at the EXIF/GPS data).

I don't know if this has been potted down into a Photoshop plugin
just yet.

[nospam]

In article <rs8avo$i6u$1...@posie.signal11.org.uk>, Mike

<m...@signal11.invalid> wrote:

> >Surely it's not beyond
> >the wit of man (or algorithm) to automate _most_ of the correction
> >needed now, maybe offering several options, rather than a human having
> >to manually tweak, especially different patches of the same image?
>
> There are AI systems that can take a black and white picture as input,
> and work out what the colours probably were (given a big catalogue of
> "what things look like" to work with as learning input).

yep.

> Just as there are AI processing tools that can actually implement
> the old "CSI: BS!" stuff where a pixellated grainy photograph can
> be turned into a high-res detailed version at a moment's notice.

nope.

> There are AI systems that given a photograph can take a good
> stab at what country it was taken in (no peeking at the EXIF/GPS data).

sometimes, but knowing only the country does not help much.

> I don't know if this has been potted down into a Photoshop plugin
> just yet.

no need for a plug-in when there are apps that can do it.

[Mike]

In article <261220201707112143%nos...@nospam.invalid>,

nospam <nos...@nospam.invalid> wrote:

>> Just as there are AI processing tools that can actually implement
>> the old "CSI: BS!" stuff where a pixellated grainy photograph can
>> be turned into a high-res detailed version at a moment's notice.
>
>nope.

Really? Someone should tell the people doing it, then.

Have you not seen some of the work of GAN (Adversarial Networks)
that can create faces/cats out of thin air (well, random numbers)

http://thispersondoesnotexist.com/

which can be used to take a picture of one face (e.g. THIS person's
expression and pose, but use THAT person's head ...) ?

Try :-

https://www.google.co.uk/search?source=hp&ei=uMLnX4i7L47ClwS16aywBQ&q=AI+restore+missing+detail+grainy+photo&btnK=Google+Search

And :-

https://www.youtube.com/watch?v=pp7HdI0-MIo

It used to be thought that it was mathematically impossible
to claw back the "lost" data in a low-res, blurry, noisy, partly
obscured or damaged image.

And, for a single image, in isolation, that's probably still true.

But for a single image + AI + a bank of "all the images you can
lay your hands on" -- things change.

[nospam]

In article <rs8g8g$274$1...@posie.signal11.org.uk>, Mike

<m...@signal11.invalid> wrote:

> >> Just as there are AI processing tools that can actually implement
> >> the old "CSI: BS!" stuff where a pixellated grainy photograph can
> >> be turned into a high-res detailed version at a moment's notice.
> >
> >nope.
>
> Really?

really.

> Someone should tell the people doing it, then.

only if the pixelation is not that significant, and it's not 'at a
moment's notice' either.

[J. P. Gilliver (John)]

On Sat, 26 Dec 2020 at 21:46:32, Mike <m...@signal11.invalid> wrote (my

responses usually follow points raised):

>In article <e9S0W2FN...@255soft.uk>,
>J. P. Gilliver (John) <G6...@255soft.uk> wrote:
>>Surely it's not beyond
>>the wit of man (or algorithm) to automate _most_ of the correction
>>needed now, maybe offering several options, rather than a human having
>>to manually tweak, especially different patches of the same image?
>
>There are AI systems that can take a black and white picture as input,
>and work out what the colours probably were (given a big catalogue of
>"what things look like" to work with as learning input).

(Yes; MyHeritage, a genealogy company, from time to time make theirs
free. Results are variable, but sometimes very impressive; from the ones
I've tried, it's particularly good on group shots - school or wedding
photographs, for example.)

>
>Just as there are AI processing tools that can actually implement
>the old "CSI: BS!" stuff where a pixellated grainy photograph can
>be turned into a high-res detailed version at a moment's notice.
>
>There are AI systems that given a photograph can take a good
>stab at what country it was taken in (no peeking at the EXIF/GPS data).
>
>I don't know if this has been potted down into a Photoshop plugin
>just yet.
>

Yes, all good examples. So why aren't there ones (widely known, anyway)
that can work with, in particular, faded colour photographic material,
and restore the colour, at least _faster_ than a human can?

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

But remember, in a permissive society, it is also permissible to stay at home
and have a nice cup of tea instead. Andrew Collins, RT 2015/2/14-20

[nospam]

In article <XPJWqUQi...@255soft.uk>, J. P. Gilliver (John)

<G6...@255soft.uk> wrote:

> >
> Yes, all good examples. So why aren't there ones (widely known, anyway)
> that can work with, in particular, faded colour photographic material,
> and restore the colour, at least _faster_ than a human can?

there are several.

[Ron C]

seems they haven't filtered down to us common folk
else there wouldn't be threads like this.
~~
care to list a few... for we, the less informed?

[Frank Slootweg]

[Disclaimer: I know relatively little about this subject matter, so ...]

"J. P. Gilliver (John)" <G6...@255soft.uk> wrote:

[...]

> Yes, all good examples. So why aren't there ones (widely known, anyway)
> that can work with, in particular, faded colour photographic material,
> and restore the colour, at least _faster_ than a human can?

FWIW, the 'ScanGear' software, which came with our Canon CanoScan
9000F MarkII flatbed scanner, has such a feature, appropriately called
'Fading Correction' (with several levels of correction). It works quite
well. It makes the colours more vivid or/and makes a dark picture
lighter. We use it with colour slides, dating back as much as five
decades.

AFAIK, this function works during the scanning, but I think something
like it could also work with an already scanned picture, provided the
scan is of sufficient quality.

[J. P. Gilliver (John)]

On Sun, 27 Dec 2020 at 11:36:36, Frank Slootweg <th...@ddress.is.invalid>

wrote (my responses usually follow points raised):

>[Disclaimer: I know relatively little about this subject matter, so ...]
>
>"J. P. Gilliver (John)" <G6...@255soft.uk> wrote:
>[...]
>
>> Yes, all good examples. So why aren't there ones (widely known, anyway)
>> that can work with, in particular, faded colour photographic material,
>> and restore the colour, at least _faster_ than a human can?
>
> FWIW, the 'ScanGear' software, which came with our Canon CanoScan
>9000F MarkII flatbed scanner, has such a feature, appropriately called
>'Fading Correction' (with several levels of correction). It works quite
>well. It makes the colours more vivid or/and makes a dark picture
>lighter. We use it with colour slides, dating back as much as five
>decades.

Anyone else care to comment on this software? Is it available separately

>
> AFAIK, this function works during the scanning, but I think something
>like it could also work with an already scanned picture, provided the
>scan is of sufficient quality.

Interesting.

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Have the courage to be ordinary - people make themselves so desperately unhappy
trying to be clever and totally original. (Robbie Coltrane, RT 8-14 Nov. 1997.)

[Andy Burns]

Mike wrote:

> Have you not seen some of the work of GAN (Adversarial Networks)
> that can create faces/cats out of thin air (well, random numbers)

I have seen them, but *generating* realistic looking images isn't the
same as zooming a handful of pixels to full screen to *recreate* an
actual image.

[Frank Slootweg]

"J. P. Gilliver (John)" <G6...@255soft.uk> wrote:
> On Sun, 27 Dec 2020 at 11:36:36, Frank Slootweg <th...@ddress.is.invalid>
> wrote (my responses usually follow points raised):
> >[Disclaimer: I know relatively little about this subject matter, so ...]
> >
> >"J. P. Gilliver (John)" <G6...@255soft.uk> wrote:
> >[...]
> >
> >> Yes, all good examples. So why aren't there ones (widely known, anyway)
> >> that can work with, in particular, faded colour photographic material,
> >> and restore the colour, at least _faster_ than a human can?
> >
> > FWIW, the 'ScanGear' software, which came with our Canon CanoScan
> >9000F MarkII flatbed scanner, has such a feature, appropriately called
> >'Fading Correction' (with several levels of correction). It works quite
> >well. It makes the colours more vivid or/and makes a dark picture
> >lighter. We use it with colour slides, dating back as much as five
> >decades.
>
> Anyone else care to comment on this software? Is it available separately

It seems to be freely downloadable, but I've not checked if there are
any (legal) restrictions to its use (i.e. for users who don't own a
Canon scanner).

Example download (for Windows 8.1, 64-bit):

"9000F MarkII Scanner Driver Ver. 1.01 (Windows)"

<https://www.canon.co.uk/support/consumer_products/products/scanners/canoscan_series/canoscan_9000f_markii.html?type=drivers&language=&os=windows%208.1%20(64-bit)>

The 'IJ Scan Utility' is a frontend to the ScanGear software. It
allows to name the output file/folder, select the viewer, etc.. All
settings, etc. are in the ScanGear software. I wouldn't call it a
'driver', because it's much, much more than that.

General support page for this scanner:

<https://www.canon.co.uk/support/consumer_products/products/scanners/canoscan_series/canoscan_9000f_markii.html>

[nospam]

In article <BfKdnUrsQIual3XC...@giganews.com>, Ron C

<r.c...@verizon.net> wrote:

> >> Yes, all good examples. So why aren't there ones (widely known, anyway)
> >> that can work with, in particular, faded colour photographic material,
> >> and restore the colour, at least _faster_ than a human can?
> >
> > there are several.
> >
> seems they haven't filtered down to us common folk
> else there wouldn't be threads like this.
> ~~
> care to list a few... for we, the less informed?

start here:
<https://www.microsoft.com/en-us/p/ai-photo-restore-enhancement-restorat
ion/9p6h9wx643c4?activetab=pivot:overviewtab>
AI Photo Restore is the best and most modern photo restoration
software available as it uses the latest machine learning technology.
The technology behind the app is a state-of-the-art deep neural
network for photo restoration that was presented in 2020 by
Microsoft Research in their paper "Bringing Old Photos Back to Life".
...
€ Restores old photos to their former glory using machine learning
€ Fixes all kinds of defects such as noise, blurriness, film grain,
color fading, etc.
€ Uses a state-of-the-art deep neural network developed in 2020
by Microsoft Research
€ Supports faster processing of your photos using the GPU

the referenced paper, for those interested the details:
<https://arxiv.org/pdf/2004.09484.pdf>
We propose to restore old photos that suffer from severe degradation
through a deep learning approach...

source code, should anyone wish to write their own app:
<https://github.com/microsoft/Bringing-Old-Photos-Back-to-Life>
The code is tested on Ubuntu with Nvidia GPUs and CUDA installed.
Python>=3.6 is required to run the code.

[J. P. Gilliver (John)]

On Sun, 27 Dec 2020 at 13:06:02, Frank Slootweg <th...@ddress.is.invalid>

wrote (my responses usually follow points raised):
>"J. P. Gilliver (John)" <G6...@255soft.uk> wrote:
>> On Sun, 27 Dec 2020 at 11:36:36, Frank Slootweg <th...@ddress.is.invalid>
>> wrote (my responses usually follow points raised):
>> >[Disclaimer: I know relatively little about this subject matter, so ...]
>> >
>> >"J. P. Gilliver (John)" <G6...@255soft.uk> wrote:
>> >[...]
>> >
>> >> Yes, all good examples. So why aren't there ones (widely known, anyway)
>> >> that can work with, in particular, faded colour photographic material,
>> >> and restore the colour, at least _faster_ than a human can?
>> >
>> > FWIW, the 'ScanGear' software, which came with our Canon CanoScan

[]

> The 'IJ Scan Utility' is a frontend to the ScanGear software. It
>allows to name the output file/folder, select the viewer, etc.. All
>settings, etc. are in the ScanGear software. I wouldn't call it a
>'driver', because it's much, much more than that.
>
> General support page for this scanner:
>
><https://www.canon.co.uk/support/consumer_products/products/scanners/can
>oscan_series/canoscan_9000f_markii.html>
>
>> > AFAIK, this function works during the scanning, but I think something
>> >like it could also work with an already scanned picture, provided the
>> >scan is of sufficient quality.

[]
I should have thought this through: if ScanGear only works during the
scanning, I can't use it as I don't have that scanner.

Anyone know of anything that works with already-scanned source material
(to correct the colours of faded slides, negatives, and particularly
prints)? I don't just mean general saturation and similar tweakers, I
mean things that are very specific to faded photographic material - that
knows, for example, that the blue and green layers need different
treatment in an area that is red, to what they need in an area that is
blue.

(Sorry for wasting Frank's time.)

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Some cause happiness wherever they go; others, whenever they go. - Oscar Wilde

[Woody]

Any good photo processing software should be able to do it. The best in
that way is Lightroom but as that costs you could try downloading The
Gimp which is a comprehensive package and best of all is FREE!

[John Williamson]

On 27/12/2020 14:09, J. P. Gilliver (John) wrote:

> Anyone know of anything that works with already-scanned source material
> (to correct the colours of faded slides, negatives, and particularly
> prints)? I don't just mean general saturation and similar tweakers, I
> mean things that are very specific to faded photographic material - that
> knows, for example, that the blue and green layers need different
> treatment in an area that is red, to what they need in an area that is
> blue.
>
> (Sorry for wasting Frank's time.)

Yes, I use the per-channel gamma correction in the GIMP and Photoshop
for that.

It can (manually) correct even situations where one or more of the
colours has reverted to a negative image.

I am not aware of any automatic way to do the job, but have found that
as the fading in each layer has been uniform, there is no need to take
account of the other layers when adjustments are made to one of the layers.

--
Tciao for Now!

John.

[J. P. Gilliver (John)]

On Sun, 27 Dec 2020 at 14:23:02, John Williamson
<johnwil...@btinternet.com> wrote (my responses usually follow
points raised):

>On 27/12/2020 14:09, J. P. Gilliver (John) wrote:
>
>> Anyone know of anything that works with already-scanned source material
>> (to correct the colours of faded slides, negatives, and particularly
>> prints)? I don't just mean general saturation and similar tweakers, I

[]

>Yes, I use the per-channel gamma correction in the GIMP and Photoshop
>for that.
>
>It can (manually) correct even situations where one or more of the
>colours has reverted to a negative image.
>
>I am not aware of any automatic way to do the job, but have found that
>as the fading in each layer has been uniform, there is no need to take
>account of the other layers when adjustments are made to one of the
>layers.
>

All hail great GIMP (-:

Actually, nothing against GIMP (other than that it appears to always be
presented as the cure for everything).

But it's that word "manually". Sure, for some final tweaking, but I am
surprised no-one (that I know of) has by now come up with something that
does at least the _preliminary_ stages of faded-photo correction,
_automatically_. (Maybe _as_ a plugin - or whatever the preferred term
is - _to_ GIMP.)

And _is_ the fading in each layer uniform? I'd have thought they _would_
affect each other, especially for prints: surely, if there's an area
where the top layer is dark, the other layers under that area will have
faded less than in an area where the top layer is light?

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

It is important to write so that you can be understood. It is far more
important to write so that you cannot be misunderstood.

[nospam]

In article <t6oI3Ybq...@255soft.uk>, J. P. Gilliver (John)

<G6...@255soft.uk> wrote:

> All hail great GIMP (-:
>
> Actually, nothing against GIMP (other than that it appears to always be
> presented as the cure for everything).

only by those who don't know any better and do not value their time.

> But it's that word "manually". Sure, for some final tweaking, but I am
> surprised no-one (that I know of) has by now come up with something that
> does at least the _preliminary_ stages of faded-photo correction,
> _automatically_. (Maybe _as_ a plugin - or whatever the preferred term
> is - _to_ GIMP.)

several companies have done so, with more on the way, especially with
hardware-based neural engines.

> And _is_ the fading in each layer uniform? I'd have thought they _would_
> affect each other, especially for prints: surely, if there's an area
> where the top layer is dark, the other layers under that area will have
> faded less than in an area where the top layer is light?

it's not uniform. different dyes fade at different rates, independent
of ambient light.

[Woody]

Generally if you ask software to correct a picture it will do its best
to get the final product as overall near as possible to a Kodak 18% grey
card by tweaking not just the brightness and contrast but the hue and
saturation as well. Some software is much better at it than others and
it doesn't mean that expemsive is best. In many ways IMO Coral Paintshop
Pro exceeds the like of Photoshop Elements, and Ability Photo (evolved
from Serif PhotoPlus) is not far behind and both are a darned sight
easier to use than any dialect of Photoshop!

[John Williamson]

On 27/12/2020 15:14, J. P. Gilliver (John) wrote:
> All hail great GIMP (-:
>

<Grin> It is rather good, isn't it? I prefer it to Photoshop for most
jobs. Certainly for minor tonal adjustments and such, I find it a lot
easier to get good results from than Photoshop, though Photoshop is
better for some jobs.

> Actually, nothing against GIMP (other than that it appears to always be
> presented as the cure for everything).
>
> But it's that word "manually". Sure, for some final tweaking, but I am
> surprised no-one (that I know of) has by now come up with something that
> does at least the _preliminary_ stages of faded-photo correction,
> _automatically_. (Maybe _as_ a plugin - or whatever the preferred term
> is - _to_ GIMP.)
>

<Grin> There's nothing to stop you writing a plugin, as the API is
available to the public, and the program and other plugins are all open
source, or you could club together and ask the developers to add the
functionality (For a fee, programmers aren't cheap)

What I do, though, is open the image, and use the gamma curves and the
live preview to roughly adjust a copy of the image. This takes a few
seconds per channel, which is as quick as loading a plugin to do the
job, with more control. It also lets me use a different slope for
different ranges of the image density. Then, I zoom in and use the clone
tool or the pen and brush tools to repair any scratches or other
physical damage.

> And _is_ the fading in each layer uniform? I'd have thought they _would_
> affect each other, especially for prints: surely, if there's an area
> where the top layer is dark, the other layers under that area will have
> faded less than in an area where the top layer is light?

The chemically induced fading is normally uniform, and I've had no
problems ignoring the light induced fading in the past, though if there
is a problem, then using a non-linear gamma curve will help.

[J. P. Gilliver (John)]

On Sun, 27 Dec 2020 at 15:40:20, Woody <harro...@ntlworld.com> wrote

(my responses usually follow points raised):

>On Sun 27/12/2020 15:24, nospam wrote:
>> In article <t6oI3Ybq...@255soft.uk>, J. P. Gilliver (John)
>> <G6...@255soft.uk> wrote:
>>
>>> All hail great GIMP (-:
>>>
>>> Actually, nothing against GIMP (other than that it appears to always be
>>> presented as the cure for everything).
>> only by those who don't know any better and do not value their time.
>>
>>> But it's that word "manually". Sure, for some final tweaking, but I
>>>

>>> surprised no-one (that I know of) has by now come up with something that
>>> does at least the _preliminary_ stages of faded-photo correction,
>>> _automatically_. (Maybe _as_ a plugin - or whatever the preferred term
>>> is - _to_ GIMP.)
>> several companies have done so, with more on the way, especially
>>with
>> hardware-based neural engines.
>>
>>> And _is_ the fading in each layer uniform? I'd have thought they
>>>_would_
>>> affect each other, especially for prints: surely, if there's an area
>>> where the top layer is dark, the other layers under that area will have
>>> faded less than in an area where the top layer is light?
>> it's not uniform. different dyes fade at different rates,
>>independent
>> of ambient light.
>>
>
>Generally if you ask software to correct a picture it will do its best
>to get the final product as overall near as possible to a Kodak 18%
>grey card by tweaking not just the brightness and contrast but the hue
>and saturation as well. Some software is much better at it than others

Isn't that affected by the picture content though? I _want_ it to
remain, say, predominantly red if it was.

>and it doesn't mean that expemsive is best. In many ways IMO Coral
>Paintshop Pro exceeds the like of Photoshop Elements, and Ability Photo
>(evolved from Serif PhotoPlus) is not far behind and both are a darned
>sight easier to use than any dialect of Photoshop!
>

I'm thinking of a preliminary automated stage, where no "use" is
involved, other than perhaps selecting a white point.

>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Electricians do it 'till it Hz.

[J. P. Gilliver (John)]

On Sun, 27 Dec 2020 at 15:40:25, John Williamson

<johnwil...@btinternet.com> wrote (my responses usually follow
points raised):

>On 27/12/2020 15:14, J. P. Gilliver (John) wrote:
>> All hail great GIMP (-:
>>
><Grin> It is rather good, isn't it? I prefer it to Photoshop for most

I'll admit I've never actually used it, just that people recommend it a
lot (-:

>jobs. Certainly for minor tonal adjustments and such, I find it a lot
>easier to get good results from than Photoshop, though Photoshop is
>better for some jobs.

I'm thinking of an original automated stage, rather than any "get".
[]

><Grin> There's nothing to stop you writing a plugin, as the API is
>available to the public, and the program and other plugins are all open
>source, or you could club together and ask the developers to add the
>functionality (For a fee, programmers aren't cheap)
>
>What I do, though, is open the image, and use the gamma curves and the
>live preview to roughly adjust a copy of the image. This takes a few
>seconds per channel, which is as quick as loading a plugin to do the
>job, with more control. It also lets me use a different slope for
>different ranges of the image density. Then, I zoom in and use the
>clone tool or the pen and brush tools to repair any scratches or other
>physical damage.

I'm thinking of, I suppose, a small set of predefined curves - maybe for
different manufacturers of film stock. It seems to me it _ought_, by
now, to be possible for software to be able to figure out automatically
the filmstock/paper by itself (and _maybe_ give the user a single slider
for _degree_ of fade). Not the fine detail of spot/scratch repair; just
something you could do once, then throw all the images from, say, that
particular roll of film at, and it'd colour-correct all of them. (_Then_
you'd go in with the repair tools.)

>
>> And _is_ the fading in each layer uniform? I'd have thought they _would_
>> affect each other, especially for prints: surely, if there's an area
>> where the top layer is dark, the other layers under that area will have
>> faded less than in an area where the top layer is light?
>
>The chemically induced fading is normally uniform, and I've had no
>problems ignoring the light induced fading in the past, though if there
>is a problem, then using a non-linear gamma curve will help.
>

Wouldn't, sometimes, what's in one layer affect what curves the other
layers need? Or are you saying that doesn't in fact happen?

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

[John Williamson]

On 27/12/2020 16:14, J. P. Gilliver (John) wrote:

> I'm thinking of an original automated stage, rather than any "get".
> []

I'm having trouble visualising what you expect it to do, and how you
expect to save time and effort, given that the major adjustment to get a
reasonable starting point are so quick an easy to do manually. Unless
your plan is to set up a commercial service.

> I'm thinking of, I suppose, a small set of predefined curves - maybe for
> different manufacturers of film stock. It seems to me it _ought_, by
> now, to be possible for software to be able to figure out automatically
> the filmstock/paper by itself (and _maybe_ give the user a single slider
> for _degree_ of fade). Not the fine detail of spot/scratch repair; just
> something you could do once, then throw all the images from, say, that
> particular roll of film at, and it'd colour-correct all of them. (_Then_
> you'd go in with the repair tools.)

It's not hard to save a gamma curves preset in GIMP. However, certainly
for prints, each one is likely to be different.

As has been said by another poster, there are AI powered solutions, but
they may well turn out to be too expensive for casual use.

> Wouldn't, sometimes, what's in one layer affect what curves the other
> layers need? Or are you saying that doesn't in fact happen?

I'm not saying it doesn't or can't happen, just that I've never noticed it.

All this automation might save time of you are doing dozens of rolls of
film, but for a single roll, the setting up will probably take longer
than the job would take to do manually.

[nospam]

In article <urchufp629csj9q8m...@4ax.com>, jetjock

<jet...@unkown.com> wrote:

> >> >> Yes, all good examples. So why aren't there ones (widely known, anyway)
> >> >> that can work with, in particular, faded colour photographic material,
> >> >> and restore the colour, at least _faster_ than a human can?
> >> >
> >> > there are several.
> >> >
> >> seems they haven't filtered down to us common folk
> >> else there wouldn't be threads like this.
> >> ~~
> >> care to list a few... for we, the less informed?
> >
> >start here:
> ><https://www.microsoft.com/en-us/p/ai-photo-restore-enhancement-restorat
> >ion/9p6h9wx643c4?activetab=pivot:overviewtab>
> > AI Photo Restore is the best and most modern photo restoration
> > software available as it uses the latest machine learning technology.
> > The technology behind the app is a state-of-the-art deep neural
> > network for photo restoration that was presented in 2020 by
> > Microsoft Research in their paper "Bringing Old Photos Back to Life".
> >...
> > € Restores old photos to their former glory using machine learning
> > € Fixes all kinds of defects such as noise, blurriness, film grain,
> > color fading, etc.
> > € Uses a state-of-the-art deep neural network developed in 2020
> > by Microsoft Research
> > € Supports faster processing of your photos using the GPU
>

> Requires Win 10! Not much good in a Win 7 group. :-(

time to upgrade.

[nospam]

In article <rsa9t5$c3k$1...@dont-email.me>, Woody

<harro...@ntlworld.com> wrote:


>
> Generally if you ask software to correct a picture it will do its best
> to get the final product as overall near as possible to a Kodak 18% grey
> card by tweaking not just the brightness and contrast but the hue and
> saturation as well.

not very good software, since that makes a lot of assumptions that are
very likely to be incorrect.

for example, a red sunset won't look particularly good if the software
corrects for the red and makes it look like midday sun.

[nospam]

In article <or3ZD$dX$K6f...@255soft.uk>, J. P. Gilliver (John)

<G6...@255soft.uk> wrote:

> >Generally if you ask software to correct a picture it will do its best
> >to get the final product as overall near as possible to a Kodak 18%
> >grey card by tweaking not just the brightness and contrast but the hue
> >and saturation as well. Some software is much better at it than others
>
> Isn't that affected by the picture content though? I _want_ it to
> remain, say, predominantly red if it was.

yep.

a red sunset corrected to neutral will look like midday sun, and
definitely *not* what is desired.

[nospam]

In article <i4ro7e...@mid.individual.net>, John Williamson

<johnwil...@btinternet.com> wrote:

> > All hail great GIMP (-:
> >
> <Grin> It is rather good, isn't it? I prefer it to Photoshop for most
> jobs. Certainly for minor tonal adjustments and such, I find it a lot
> easier to get good results from than Photoshop, though Photoshop is
> better for some jobs.

people who claim the gimp is better than photoshop do not know what
photoshop can actually do.

the gimp is where photoshop was roughly 15 years ago and lacks critical
features that photoshop has had for 20+ years and according to the
gimp's road map, never will, plus it's substantially slower on the same
hardware than photoshop.

> > And _is_ the fading in each layer uniform? I'd have thought they _would_
> > affect each other, especially for prints: surely, if there's an area
> > where the top layer is dark, the other layers under that area will have
> > faded less than in an area where the top layer is light?
>
> The chemically induced fading is normally uniform, and I've had no
> problems ignoring the light induced fading in the past, though if there
> is a problem, then using a non-linear gamma curve will help.

it is not uniform and a gamma curve is the wrong approach.

[nospam]

In article <i4rtah...@mid.individual.net>, John Williamson

<johnwil...@btinternet.com> wrote:

>
> As has been said by another poster, there are AI powered solutions, but
> they may well turn out to be too expensive for casual use.

the microsoft app is $20. that's *cheap*.

in the event that's too much money, there are websites that implement
microsoft's algorithm, which can be used for free, however, that's not
practical for more than one or two photos, plus the privacy concerns of
uploading it to some website.

[J. P. Gilliver (John)]

On Sun, 27 Dec 2020 at 17:07:28, John Williamson

<johnwil...@btinternet.com> wrote (my responses usually follow
points raised):

>On 27/12/2020 16:14, J. P. Gilliver (John) wrote:
>
>> I'm thinking of an original automated stage, rather than any "get".
>> []
>I'm having trouble visualising what you expect it to do, and how you
>expect to save time and effort, given that the major adjustment to get
>a reasonable starting point are so quick an easy to do manually. Unless

They might be for a very experienced tweaker.

>your plan is to set up a commercial service.

No.

>
>> I'm thinking of, I suppose, a small set of predefined curves - maybe for
>> different manufacturers of film stock. It seems to me it _ought_, by
>> now, to be possible for software to be able to figure out automatically
>> the filmstock/paper by itself (and _maybe_ give the user a single slider
>> for _degree_ of fade). Not the fine detail of spot/scratch repair; just
>> something you could do once, then throw all the images from, say, that
>> particular roll of film at, and it'd colour-correct all of them. (_Then_
>> you'd go in with the repair tools.)
>
>It's not hard to save a gamma curves preset in GIMP. However, certainly

But creating them before saving - see above.

>for prints, each one is likely to be different.

Certainly, if one print has been left in the sun in a frame. If they've
all been put in an album kept out of sunlight, i. e. the fading is
entirely chemical, less so.

>
>As has been said by another poster, there are AI powered solutions, but
>they may well turn out to be too expensive for casual use.

Someone mentioned a Microsoft one for $20. That would be acceptable.

>
>> Wouldn't, sometimes, what's in one layer affect what curves the other
>> layers need? Or are you saying that doesn't in fact happen?
>
>I'm not saying it doesn't or can't happen, just that I've never noticed it.
>
>All this automation might save time of you are doing dozens of rolls of
>film, but for a single roll, the setting up will probably take longer
>than the job would take to do manually.
>

Only for a person experienced in this, I still think.

>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"OLTION'S COMPLETE, UNABRIDGED HISTORY OF THE UNIVERSE
Bang! ...crumple." - Jery Oltion

[Ken Hart]

On 12/26/20 3:53 PM, J. P. Gilliver (John) wrote:
> On Fri, 25 Dec 2020 at 22:32:23, William Unruh <un...@invalid.ca> wrote

> (my responses usually follow points raised):

> []
>> The question is whether you want the picture to look like it did when
>> you first got back the developed prints, or do you want it to look "more
>> real". Taking bits and pieces of the print and altering them is almost
>> certainly not making it look like what it was. ( And also you probably
>> should not have scanned it into jpeg-- jpeg throws away information and
>> bleeds one pixel into it neighbour, making colour correction and edges
>> hard to do. Of course getting it to look like it did when you were 9 may
>> not be the purpose.
>>
> I am surprised that, by now, the fading characteristics of the various
> film stocks aren't pretty well known by now - even including the effects
> of different parts having different exposures (i. e. the algorithm
> knowing that, say, a red area causes the blue and green - or magenta and
> cyan, etc. - layers to fade in a specific way). Surely it's not beyond

> the wit of man (or algorithm) to automate _most_ of the correction
> needed now, maybe offering several options, rather than a human having
> to manually tweak, especially different patches of the same image?
>

> I guess it's money, as usual - not enough money in it; lots that need
> correcting (including movie material), but in small amounts. Still, it
> does seem odd nobody's released anything by now. The movie companies
> must have something (I remember reading quite a few years ago that the
> Star Trek masters had needed restoration for example), but maybe they're
> guarding their software jealously. (Or it needs so long per frame - but
> surely processing power should have conquered that by now.)

The fading characteristics can also be influenced by the original
chemistry and procedures used to develope the film. Film may fade
differently if it was processed in Kodak chemicals versus Fuji
chemicals. Even the water used to mix the chemicals may have an effect.
The processing times/temperatures for each chemical can have an effect.
Basically, too many variables to come up with a reliable, one size fits
all algorithm. And we haven't even talked about the film base or color
mask (overall orange-ish color cast) used by different manufacturers.

If you're keen to work this out, I recommend shooting a color chart and
18% grey card at the beginning and end of rolls of film from different
manufacturers, and have them processed with different variations of the
C-41 process. Then seal up the negatives with complete instructions to
be followed 50+ years from now.

--
Ken Hart
kwh...@frontier.com

[nospam]

In article <rsbcml$1d9i$1...@gioia.aioe.org>, Ken Hart

<kwh...@frontier.com> wrote:

> The fading characteristics can also be influenced by the original
> chemistry and procedures used to develope the film. Film may fade
> differently if it was processed in Kodak chemicals versus Fuji
> chemicals. Even the water used to mix the chemicals may have an effect.
> The processing times/temperatures for each chemical can have an effect.
> Basically, too many variables to come up with a reliable, one size fits
> all algorithm. And we haven't even talked about the film base or color
> mask (overall orange-ish color cast) used by different manufacturers.

that doesn't matter anywhere near as much as you might think (as in not
at all), one of many reasons why such algorithms exist and work quite
well, without needing to know what the film or paper chemistry was,
which is almost certainly unknown.

> If you're keen to work this out, I recommend shooting a color chart and
> 18% grey card at the beginning and end of rolls of film from different
> manufacturers, and have them processed with different variations of the
> C-41 process. Then seal up the negatives with complete instructions to
> be followed 50+ years from now.

a much better idea is scan the film and then toss it.

an even better idea is a fully digital workflow, moving beyond the
limitations of film.

[Ken Hart]

Automated systems have to correct toward a specific target. For simple
systems, it assumes that the world is 18% grey. A system with some
'intelligence' may know that the sky is a specific blue and the grass is
a specific green. But not all skies are the same shade of blue, nor all
grasses the same shade of green.

In the color printing lab (old-school darkroom), you start by balancing
everything to 18% grey. You shoot a photo of a grey card, develope the
film, print it, and adjust filtration until the picture of the grey card
looks 18% grey (using a densitometer). And so long as you include a grey
card in every photo, it's easy to color balance.

But a grey card in front of the baby, or grandma, or the bride is
generally not a pleasing photo composition. (Although the color balance
can be made perfect!) So, when you are attempting to color balance, you
do something very 'un-computer-like': you guess. You balance the colors
until you can say "I like that".

>
>> and it doesn't mean that expemsive is best. In many ways IMO Coral
>> Paintshop Pro exceeds the like of Photoshop Elements, and Ability
>> Photo (evolved from Serif PhotoPlus) is not far behind and both are a
>> darned sight easier to use than any dialect of Photoshop!
>>
> I'm thinking of a preliminary automated stage, where no "use" is
> involved, other than perhaps selecting a white point.

The more 'standard' color and density points you can provide an
automated system, the better the final results. Ideally, you would show
it at least white and black to get contrast and density right, and the
three primary (or secondary) colors to get color balance.


--
Ken Hart
kwh...@frontier.com

[Ron C]

Note that the gray card correction assumes uniform spectral
qualities of the light source. Multi-source situations complicate
the process. Attending a seminar by Edmund Land on the topic
of differential color perception and his Retinex Theory that opened
my mind to how 'we' perceive color.
[perhaps you had to be there to fully grasp his demonstrations]

[William Unruh]

On 2020-12-28, Ron C <r.c...@verizon.net> wrote:
>>
>> The more 'standard' color and density points you can provide an
>> automated system, the better the final results. Ideally, you would show
>> it at least white and black to get contrast and density right, and the
>> three primary (or secondary) colors to get color balance.
>>
>>
> Note that the gray card correction assumes uniform spectral
> qualities of the light source. Multi-source situations complicate
> the process. Attending a seminar by Edmund Land on the topic
> of differential color perception and his Retinex Theory that opened
> my mind to how 'we' perceive color.
> [perhaps you had to be there to fully grasp his demonstrations]

Yes, His demonstrations were brilliant and have become an integral part
of psycho-optics, and lighting. An example is being in a room where
flourescent lights are used-- our eyes see nothing wrong with the
colours, while a photograph gives a horrible greenish tinge to
everything. But you probably still want to have whites and greys be
whites and greys in the photograph, not sickly green, or pink. When you
look at a photograph you are almost certainly surrounded by much more
accurate colours, and so you would like the photograph to look right
when compared to white paper in the room say. Ie, you would want to also
correct the light sources used to take the photo, as well as the dye
degradation.

In the photo that started all this, one had a scene with a rich colour
pallete, but looking the RGB histograms, the reds had nothing below
about 50 (out of 255), and the green and blues had nothing below about
40 but also nothing above about 200. My correction was to spread out
the GB to cover the full gamut of intensities, but also to cut off the
brightest reds. Unfortunately there were no 18% grey cards in the scene,
but I guess the clouds sort of played that role. Of course had the time
been 8PM, then the coulds should have looked redish. That's the trouble,
one has no idea what the actual colours in the scene were.

[Frank Slootweg]

"J. P. Gilliver (John)" <G6...@255soft.uk> wrote:

> On Sun, 27 Dec 2020 at 17:07:28, John Williamson
> <johnwil...@btinternet.com> wrote (my responses usually follow
> points raised):

[...]

> >As has been said by another poster, there are AI powered solutions, but
> >they may well turn out to be too expensive for casual use.
>
> Someone mentioned a Microsoft one for $20. That would be acceptable.

It wasn't a Microsoft one, but one based on work by Microsoft Research
and available from the Microsoft Store.

But more to the point: Looking at the 'before-after' example
screenshots, the results are not that red hot at all. One could easily
get similar or better results with any halfway decent photo editing
software, albeit doing it manually instead of by 'AI'. But looking at
the example screenshots, IMO the 'I' part of the AI is rather limited.

Here's the/nospam's URL again:

'AI Photo Restore - Enhancement & Restoration' by HIG Studio

<https://www.microsoft.com/en-us/p/ai-photo-restore-enhancement-restoration/9p6h9wx643c4?activetab=pivot:overviewtab>

[...]

[NY]

"nospam" <nos...@nospam.invalid> wrote in message
news:271220202054427493%nos...@nospam.invalid...

There are a lot of variations that can be made when scanning negative film,
to map different parts of the exposure range onto the range that the digital
sensor can reproduce.

> an even better idea is a fully digital workflow, moving beyond the
> limitations of film.

For photos taken since good digital cameras became available, that is
definitely good advice, though I imagine that colour negative film is still
capable of recording a wider exposure latitude (detail in highlights and
shadows of the same exposure) than digital is. The problem comes when you
try to make a print from the negative that can only reproduce a subset of
the range of tones that are in the negative.



My experience of scanning colour negatives (as opposed to slides) is that it
is very difficult to get a realistic-looking scan. Most of my attempts
looked like the "colour plates" that were reproduced in books from the
1930s-50s: there was something indefinably unrealistic about them. I could
get far more highlight and shadow detail than was present in a print made by
a standard processing house, but there was something not quite right about
the scans. I also got a lot of muddy haloes around dark objects (ie light on
the negative). That was with a Minolta Scan Elite film scanner.

Slides were a great deal easier and needed a lot less tweaking of black and
white points, gamma and grey point. Grain was also a lot less noticeable:
slow 100 ASA negative film had horrendous grain that fast 400 ASA slide film
didn't have. I think it was an interference pattern during the scanning
process, because it was grain that was not visible in the photographic
(non-scanned) print.


How reproducible are standard processes like Kodachrome, C41 (negative) and
E6 (Ektachrome slide)? If rolls of the same type of film were exposed in the
same way and processed and printed by different labs, should the results be
pretty similar?


I once had a roll of Ektachrome processed at my local camera shop, along
with a couple of others (same type/speed of film) that were shot at the same
time in similar conditions. All the slides on one film had a strong
blue/green cast, and were muddy and dark. The shop were baffled because all
the films had been processed in the same batch (so same chemicals, same
temperature, same time). I remember sending a slide to Kodak quality control
for their comments, and they were baffled too, given the identical
processing conditions. Unfortunately I hadn't kept the boxes that the film
came in, which would have given manufacturing batch numbers.


I used to develop and print my black and white films, and got some pretty
good results. I never had the courage to try true colour neg/slide
developing, partly because of the higher temperatures needed and the
difficult to maintain those over the developing time. With better equipment
(a thermostatically controlled water bath etc) and with a colour enlarger
(with controllable filter levels) I might have attempted it. I did shoot a
couple of rolls of the Ilford film which was B&W but used a cut-down version
of the C41 process, and found it to be very tolerant of under- and
over-exposure, and under- and over-development. I deliberately took
exposures at +/- several stops either side of the metered exposure, and one
film was uniformly much darker so I may have over-developed it. But I got
good tonal range in all the prints, even though the print exposure times
needed varied considerably between frames.

[J. P. Gilliver (John)]

On Mon, 28 Dec 2020 at 13:43:15, Frank Slootweg <th...@ddress.is.invalid>

wrote (my responses usually follow points raised):

>"J. P. Gilliver (John)" <G6...@255soft.uk> wrote:

[]

>> Someone mentioned a Microsoft one for $20. That would be acceptable.
>
> It wasn't a Microsoft one, but one based on work by Microsoft Research
>and available from the Microsoft Store.
>
> But more to the point: Looking at the 'before-after' example
>screenshots, the results are not that red hot at all. One could easily
>get similar or better results with any halfway decent photo editing
>software, albeit doing it manually instead of by 'AI'. But looking at
>the example screenshots, IMO the 'I' part of the AI is rather limited.

Yes: they looked to me as if all that had been done was up the contrast
(and perhaps saturation). In particular, there seemed little or no
evidence - in the examples given (in the "before" sides) - of fading
that affected the various layers differently, which is what I was
concentrating on.

>
> Here's the/nospam's URL again:
>
>'AI Photo Restore - Enhancement & Restoration' by HIG Studio
>
><https://www.microsoft.com/en-us/p/ai-photo-restore-enhancement-restorat
>ion/9p6h9wx643c4?activetab=pivot:overviewtab>
>
>[...]

(Thanks, noted.)

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Very funny, Scotty. Now beam down my clothes

[nospam]

In article <rscpdg$ph5$1...@dont-email.me>, NY <m...@privacy.invalid> wrote:

>
> There are a lot of variations that can be made when scanning negative film,
> to map different parts of the exposure range onto the range that the digital
> sensor can reproduce.

digital can capture everything contained in film, so that's not needed.

> > an even better idea is a fully digital workflow, moving beyond the
> > limitations of film.
>
> For photos taken since good digital cameras became available, that is
> definitely good advice, though I imagine that colour negative film is still
> capable of recording a wider exposure latitude (detail in highlights and
> shadows of the same exposure) than digital is.

it is not.

digital surpasses film in every metric, something which has been the
case for many years.

yet for some reason, there remains a small number of film luddites who
refuse to accept reality, just as there are those who still think vinyl
records are capable of higher quality sound than digital audio.

> The problem comes when you
> try to make a print from the negative that can only reproduce a subset of
> the range of tones that are in the negative.

that is a significant limitation of film photography.

also, people don't print as much as they used to, instead using wide
gamut high dynamic range displays, even on their laptops and phones.

> My experience of scanning colour negatives (as opposed to slides) is that it
> is very difficult to get a realistic-looking scan. Most of my attempts
> looked like the "colour plates" that were reproduced in books from the
> 1930s-50s: there was something indefinably unrealistic about them. I could
> get far more highlight and shadow detail than was present in a print made by
> a standard processing house, but there was something not quite right about
> the scans. I also got a lot of muddy haloes around dark objects (ie light on
> the negative). That was with a Minolta Scan Elite film scanner.

that sounds like something you did rather than an issue with the
technology.

scanning negatives (versus slides) does have the issue of eliminating
the orange mask, but that's something which has been solved long ago.

> Slides were a great deal easier and needed a lot less tweaking of black and
> white points, gamma and grey point. Grain was also a lot less noticeable:
> slow 100 ASA negative film had horrendous grain that fast 400 ASA slide film
> didn't have.

iso 100 film should not have 'horrendous grain' under any circumstances.

> I think it was an interference pattern during the scanning
> process, because it was grain that was not visible in the photographic
> (non-scanned) print.

could be, however, grain and interference patterns do not look the same.

> How reproducible are standard processes like Kodachrome, C41 (negative) and
> E6 (Ektachrome slide)? If rolls of the same type of film were exposed in the
> same way and processed and printed by different labs, should the results be
> pretty similar?

even with the same labs, the results will never be identical due to
variations in the chemistry and the human(s) operating the equipment,
among other factors.

nevertheless, many old school photographers would buy bricks of film
from the same batch and then freeze it to minimize the variables, but
mostly, that was a waste of time, money and freezer space. doing that
also prevents using more advanced film formulations as they become
available because all the unused film still in the freezer would go to
waste.

> I once had a roll of Ektachrome processed at my local camera shop, along
> with a couple of others (same type/speed of film) that were shot at the same
> time in similar conditions. All the slides on one film had a strong
> blue/green cast, and were muddy and dark. The shop were baffled because all
> the films had been processed in the same batch (so same chemicals, same
> temperature, same time). I remember sending a slide to Kodak quality control
> for their comments, and they were baffled too, given the identical
> processing conditions. Unfortunately I hadn't kept the boxes that the film
> came in, which would have given manufacturing batch numbers.

that could have been due to any number of reasons, such as the film
being improperly stored or improperly exposed.

[NY]

"nospam" <nos...@nospam.invalid> wrote in message

news:281220201013049309%nos...@nospam.invalid...

> scanning negatives (versus slides) does have the issue of eliminating
> the orange mask, but that's something which has been solved long ago.

Yes, eliminating the orange mask seems to be the easier part of the process.
My scanner just needed to be calibrated on a bit of clear leader at the
beginning of the film - or to use one of several presets for typical colour
cast of each make of film. It was a contrast and fidelity of colours issue,
which none of the controls of the scanning software really solved.

>> Slides were a great deal easier and needed a lot less tweaking of black
>> and
>> white points, gamma and grey point. Grain was also a lot less noticeable:
>> slow 100 ASA negative film had horrendous grain that fast 400 ASA slide
>> film
>> didn't have.
>
> iso 100 film should not have 'horrendous grain' under any circumstances.
>
>> I think it was an interference pattern during the scanning
>> process, because it was grain that was not visible in the photographic
>> (non-scanned) print.
>
> could be, however, grain and interference patterns do not look the same.

I did read that some scanners can cause the fine pattern of film grain to
clump together in the resulting scan. It was an irregular noise, like on a
pencil sketch or with exceptionally grainy film, and not a regular moiré
pattern.

Although I bought all the film at the same time, exposed it all at the same
time, and had it processed soon after, there is always the possibility that
one canister was from a much older batch. If the slides had been lighter
(especially if there was lighter *patches*) I'd have blamed fogging (light
or X ray). But too dark suggests underexposure or wrong film speed (eg film
wrongly labelled). Kodak examined the slides I sent, looking at the edge
markings (for clues like wrongly labelled film or wrong development) and
couldn't find any problem; the strong dark-cyan colour cast particularly
puzzled them, because it affected that as well.

[nospam]

In article <rsd2du$vg6$1...@dont-email.me>, NY <m...@privacy.invalid> wrote:

> >> I think it was an interference pattern during the scanning
> >> process, because it was grain that was not visible in the photographic
> >> (non-scanned) print.
> >
> > could be, however, grain and interference patterns do not look the same.
>
> I did read that some scanners can cause the fine pattern of film grain to
> clump together in the resulting scan. It was an irregular noise, like on a
> pencil sketch or with exceptionally grainy film, and not a regular moiré
> pattern.

i don't know what you read, but that cannot happen unless it's a shitty
scanner, in which case, the solution is to replace it with one that is
not shitty.

[William Unruh]

It could also be a result of say jpeg compression of the image. Do not
save in jpeg. Save in a lossless format.

[Ken Hart]

Film has an exposure curve. (The curve varies for various types of film.
A discussion of it would be incredibly lengthy and boring.) In the
center (or 'normal') range of the curve's exposure, light and the film's
reaction are a straight line. When you get to the brightest or dimmest
exposure, the curve flattens out. For some films, that flattening is
gradual, for others there is little flattening. With a digital sensor,
there is no flattening: when you have extreme over- or under- exposure,
the sensor goes off the ranch. Film not so much.

Color photo paper (actual, old-school, darkroom photo paper, not inkjet
paper for photos) does have a "subset" of film's density range, but it
is a large subset, larger than ink. Additionally, the surface of the
paper has an influence on the perceived brightness (or 'blackness') of
the image.

>
>
> My experience of scanning colour negatives (as opposed to slides) is
> that it is very difficult to get a realistic-looking scan. Most of my
> attempts looked like the "colour plates" that were reproduced in books
> from the 1930s-50s: there was something indefinably unrealistic about
> them. I could get far more highlight and shadow detail than was present
> in a print made by a standard processing house, but there was something
> not quite right about the scans. I also got a lot of muddy haloes around
> dark objects (ie light on the negative). That was with a Minolta Scan
> Elite film scanner.

I have never gotten a neg scan that I was pleased with. (Epson
Perfection 4490) I have gotten good scans from prints that I printed in
the darkroom. I suspect you can have a good flatbed scanner or a good
transmission scanner, but putting them both in the same package is a
bridge too far.

>
> Slides were a great deal easier and needed a lot less tweaking of black
> and white points, gamma and grey point. Grain was also a lot less
> noticeable: slow 100 ASA negative film had horrendous grain that fast
> 400 ASA slide film didn't have. I think it was an interference pattern
> during the scanning process, because it was grain that was not visible
> in the photographic (non-scanned) print.
>
>
> How reproducible are standard processes like Kodachrome, C41 (negative)
> and E6 (Ektachrome slide)? If rolls of the same type of film were
> exposed in the same way and processed and printed by different labs,
> should the results be pretty similar?

There are several C41, E6, and RA4 chemical processes, often depending
on the processor throughput, and in some cases, the environmental
impact. I tend to 'batch' my printing, so I run RA-4 for heavy
throughput- it's usually cheaper. If I were keeping my processor charged
and ready all the time for printing a couple photos a week, I would use
a low-utilization chemistry. I use 4-step C-41 process for longest neg
life; there are processes that combine the bleach and fix step. But most
say the negs won't last so long.

Commercial labs are supposed to run control strips at least daily. The
control strips are checked with a densitometer for proper chemical
activity. Additionally, the specific gravity of the chemicals is to be
checked. If that is done, then the negatives or slides should be very
similar from two different labs. Printing the negatives is another
matter. Unless the photo contains a properly exposed 18% grey card, the
printer operator is going to make a print that "looks good".

>
>
> I once had a roll of Ektachrome processed at my local camera shop, along
> with a couple of others (same type/speed of film) that were shot at the
> same time in similar conditions. All the slides on one film had a strong
> blue/green cast, and were muddy and dark. The shop were baffled because
> all the films had been processed in the same batch (so same chemicals,
> same temperature, same time). I remember sending a slide to Kodak
> quality control for their comments, and they were baffled too, given the
> identical processing conditions. Unfortunately I hadn't kept the boxes
> that the film came in, which would have given manufacturing batch numbers.

Two explanations come to mind: the emulsion batch, but that wouldn't
affect just your film; hundreds of rolls would be affected. Most likely
is storage in adverse temperature conditions at some point in the film's
unexposed lifetime. It would leave no physical indication on the
packaging or film.

>
>
> I used to develop and print my black and white films, and got some
> pretty good results. I never had the courage to try true colour
> neg/slide developing, partly because of the higher temperatures needed
> and the difficult to maintain those over the developing time. With
> better equipment (a thermostatically controlled water bath etc) and with
> a colour enlarger (with controllable filter levels) I might have
> attempted it. I did shoot a couple of rolls of the Ilford film which was
> B&W but used a cut-down version of the C41 process, and found it to be
> very tolerant of under- and over-exposure, and under- and
> over-development. I deliberately took exposures at +/- several stops
> either side of the metered exposure, and one film was uniformly much
> darker so I may have over-developed it. But I got good tonal range in
> all the prints, even though the print exposure times needed varied
> considerably between frames.

I never used the C41 processed B&W film. As I recall, it used standard
C41 process and had the orange mask, so that it could just be run
through with regular color negative film.
You can actually develope true B&W film in C-41 chemicals- just leave
out the bleach step. The times are ridiculously long to get a normal
contrast.

--
Ken Hart
kwh...@frontier.com

[Liz Tuddenham]

J. P. Gilliver (John) <G6...@255soft.uk> wrote:

>... there seemed little or no

> evidence - in the examples given (in the "before" sides) - of fading
> that affected the various layers differently, which is what I was
> concentrating on.

I have found that sometimes it needs the gamma of each colour correcting
separately, not just the luminance range. Have any of these programs
addressed that?

--
~ Liz Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[nospam]

In article <rsdev8$1q9e$1...@gioia.aioe.org>, Ken Hart

<kwh...@frontier.com> wrote:

> Film has an exposure curve. (The curve varies for various types of film.
> A discussion of it would be incredibly lengthy and boring.) In the
> center (or 'normal') range of the curve's exposure, light and the film's
> reaction are a straight line. When you get to the brightest or dimmest
> exposure, the curve flattens out. For some films, that flattening is
> gradual, for others there is little flattening. With a digital sensor,
> there is no flattening: when you have extreme over- or under- exposure,
> the sensor goes off the ranch. Film not so much.

known as the hurter-driffield curve, but the part you're ignoring is
that film is non-linear at either ends of the curve, and since digital
has a wider dynamic range than film, digital can accurately capture
those ends without the non-linearities, clipping and losses that are
unavoidable with film, resulting in a more accurate rendition of the
scene.

> Color photo paper (actual, old-school, darkroom photo paper, not inkjet
> paper for photos) does have a "subset" of film's density range, but it
> is a large subset, larger than ink.

false.

inkjet printer gamut and dynamic range is *larger* than chromogenic
photo paper. this has been explained to you many times before.

<https://www.insideimaging.com.au/wp-content/uploads/2019/04/Gamut-Compa
rison-Chart-Inkjet-Vs.gif>

and as i said in another post, people don't print that much anymore,
preferring to display photos on their phones, tablets and laptops, many
of which have wide gamut high dynamic range displays that are *much*
better than any print can reproduce.

> Additionally, the surface of the
> paper has an influence on the perceived brightness (or 'blackness') of
> the image.

as do the various inkjet printer papers and inks as well as the ambient
light in which the print is viewed.

> I have never gotten a neg scan that I was pleased with. (Epson
> Perfection 4490)

no surprise there. that's not a negative scanner, so why would someone
expect it to produce optimal results when scanning negatives?

> I have gotten good scans from prints that I printed in
> the darkroom. I suspect you can have a good flatbed scanner or a good
> transmission scanner, but putting them both in the same package is a
> bridge too far.

that's why the best scanners are dedicated to *either* slides/negatives
*or* prints, not both.

the ones that offer both add convenience while bringing compromises.

[NY]

"nospam" <nos...@nospam.invalid> wrote in message

news:281220201607123329%nos...@nospam.invalid...

> In article <rsdev8$1q9e$1...@gioia.aioe.org>, Ken Hart
> <kwh...@frontier.com> wrote:
>
>> Film has an exposure curve. (The curve varies for various types of film.
>> A discussion of it would be incredibly lengthy and boring.) In the
>> center (or 'normal') range of the curve's exposure, light and the film's
>> reaction are a straight line. When you get to the brightest or dimmest
>> exposure, the curve flattens out. For some films, that flattening is
>> gradual, for others there is little flattening. With a digital sensor,
>> there is no flattening: when you have extreme over- or under- exposure,
>> the sensor goes off the ranch. Film not so much.
>
> known as the hurter-driffield curve, but the part you're ignoring is
> that film is non-linear at either ends of the curve, and since digital
> has a wider dynamic range than film, digital can accurately capture
> those ends without the non-linearities, clipping and losses that are
> unavoidable with film, resulting in a more accurate rendition of the
> scene.

>> I have never gotten a neg scan that I was pleased with. (Epson
>> Perfection 4490)
>
> no surprise there. that's not a negative scanner, so why would someone
> expect it to produce optimal results when scanning negatives?

Before I got my Minolta film scanner, I experimented with my flatbed Epson
Perfection 1200 using its backlight. The results for slides were
surprisingly good, albeit low in resolution (as you'd expect with only 1200
dpi). The results for negatives were truly horrendous, no matter what
exposure, brightness, contrast or gamma settings I chose in the driver (ie
before mapping to a mere 8 bits for each of R, G and B) - and really
disgusting flare and haloes around dark objects on a light background (eg
chimneys against the sky). Flat bed scanners which auto-calibrate from a
strip of plain glass alongside the film carrier suffer badly if there is the
slightest bit of dust or dirt in the calibration region: the scanner thinks
that the pixel where the dust is is less responsive, so it boosts the gain
for that pixel throughout the scan, leading to coloured tramlines parallel
to the direction of the scan head motion.

But I wasn't too surprised - that's why I got the film scanner. Shame the
results for colour negatives were never as good (leaving aside their better
shadow and highlight detail) as scans of prints from the negs. I actually
got better results by photographing negatives with a macros lens on my DSLR
(using the Epson flat-bed scanners light as a backlight!) and then
correcting for the orange cast.

I found that I got better results with B&W negs if I configured the software
as if it were a colour neg - when told that it was seeing a B&W neg, I
sometimes got bleached-out highlights that no amount of tweaking would
completely cure - and that was true for under- correctly- and over-exposed
negs, so it was a contrast/gamma rather than simple brightness issue.

[nospam]

In article <rsdlpg$hmj$1...@dont-email.me>, NY <m...@privacy.invalid> wrote:

> Before I got my Minolta film scanner, I experimented with my flatbed Epson
> Perfection 1200 using its backlight. The results for slides were
> surprisingly good, albeit low in resolution (as you'd expect with only 1200
> dpi). The results for negatives were truly horrendous, no matter what
> exposure, brightness, contrast or gamma settings I chose in the driver (ie
> before mapping to a mere 8 bits for each of R, G and B) - and really
> disgusting flare and haloes around dark objects on a light background (eg
> chimneys against the sky).

the results should be similar, other than the orange mask issue. it's
possible that the software you used did not properly correct for that,
but that's a software issue that alternate software could avoid.



> ...I actually

> got better results by photographing negatives with a macros lens on my DSLR
> (using the Epson flat-bed scanners light as a backlight!) and then
> correcting for the orange cast.

that can produce usable results (although with a clumsy setup), but not
as good as a dedicated film scanner.

[NY]

"nospam" <nos...@nospam.invalid> wrote in message

news:281220201744202958%nos...@nospam.invalid...

Surprisingly, for colour negatives, the results from photographing the
negative, removing the cast and reversing were generally better than for the
dedicated film scanner. I think the Minolta's own software with the film
scanner was better than VueScan (Hamrick) - but sadly the Minolta software
won't run on Win 7 or higher: I was last able to use it on my XP computer.

The film scanner is showing signs of it age now. The lead-screw which
advances the scanner sensor over the film consists of a plastic collar that
fits around the shaft of the stepper motor. And that collar has split so it
no longer grips tightly. I've found that a bit of magic tape round the motor
shaft allows a good tight push fit so the sensor advances properly, without
causing aspect ratio distortion and irregular vertical scaling within a
photo, as happened before I fixed it. (Note that I use magic tape rather
sellotape because the glue on sellotape can become gooey and slimy over
time.)

[Java Jive]

On Mon, 21 Dec 2020 21:20:45 +0000, Java Jive <ja...@evij.com.invalid>
wrote:

> Apologies for the cross-posting - this is a post about a new problem
> that might be solved either using Linux or Windows software, I have
> both available as below.
>
> Linux: GIMP
> Windows 7: IrfanView
> Paint
> Paint Shop Pro 8
>
> The problem concerns the following picture and a few others like it,
> all taken with a Brownie Starmite camera when I was a boy, this one
> being of the salmon ladder at the hydro dam at Pitlochry, Scotland.
>
> This is the original scan of the negative corrected to be positive ...
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-OriginalScan.png
>
> ... this the above put through the Linux program pnnorm to improve its
> saturation ...
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-Pnnormed.png

> As you can see, the problem is that the greys in the clouds still have
> a marked reddish cast. If instead of correcting to bring whites to
> true white, I correct to bring these greys to true grey, then nothing
> else in the picture looks right because of the strong cyan cast that
> results. Although the problem doesn't look so bad in the original
> scan before applying pnnorm, it's still definitely there, so it's not
> pnnorm's fault, but the program, while improving the rest of the
> picture, has made the problem worse.
>
> I'm not sure what has caused this, but presumably it's something to do
> with the aging of the film over the intervening half century that has
> caused the pigments to fade differentially according to their original
> density in the picture, but BTAIM ...
>
> Using any of the software listed above, can anyone suggest how to
> correct the greys in the clouds to remove the red cast, while leaving
> the rest of the picture alone? I don't mind a reasonable amount of
> effort, say an hour per picture for that alone, but don't want to
> spend much longer than that.

Thanks for all the various replies. As time allowed, I revisited this
problem several times over the following days using several different
methods, and finally found a solution that fixed nearly all of these
problem photos, which I describe here in case it helps others ...

The solution used Paint Shop Pro v8. I selected only the sky, and
colour corrected this using ...
Adjust
Color Balance
Channel Mixer
... with the following settings
Red: Red 0%, Green 90%, Blue 0%
Green: Red 0%, Green 90%, Blue 0%
Blue: Red 0%, Green 0%, Blue 100%

In other words, I removed the flawed red input altogether, and tied
the Red channel to the Green channel, reducing both slightly compared
to the Blue.

Then I inverted the selection, and colour corrected the rest of each
photo by bringing a white point to be truly white.

Here are the results in pairs, first the original scan after the
application of the Linux program 'pnnorm', then the results of
applying the above procedure:

www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(nrm).png
www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(fixed).png

www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png
www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(fixed).png

www.macfh.co.uk/Temp/Scotland_-_Holiday_1_(nrm).png
www.macfh.co.uk/Temp/Scotland_-_Holiday_1_(fixed).png

This one was done similarly but from an enlargement print, because the
original neg is missing:

www.macfh.co.uk/Temp/Scotland_-_Holiday_3_(nrm).png
www.macfh.co.uk/Temp/Scotland_-_Holiday_3_(fixed).png

This took my previously posted solution and applied only a similar
channel correction to that described above:


www.macfh.co.uk/Temp/Scotland_-_Salmon_Ladder_At_Pitlochry_0_(nrm).png

www.macfh.co.uk/Temp/Scotland_-_Salmon_Ladder_At_Pitlochry_0_(fixed).png

This one couldn't be done, because the reddish tint has affected the
distant landscape and, particularly, the rims of the leaves of the
trees where they're silhouetted against the sky ...

www.macfh.co.uk/Temp/Scotland_-_Holiday_2_(cleaned).png

... so, although I don't think it was originally, it's now officially
a sunset!
--
========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

[Mayayana]

"Java Jive" <ja...@evij.com.invalid> wrote

| www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(nrm).png
| www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(fixed).png
|

Interesting. It still looks slightly too blue/purple to me.
But certainly far better than the original. There's only so
much you can do with limited color data.

[Roger Mills]

On 09/01/2021 17:46, jetjock wrote:
> On Sat, 09 Jan 2021 16:12:09 +0000, Java Jive <ja...@evij.com.invalid>

> None of the links here take you to a photo. They all redirect to your
> "File not found" page.
>
> >>>>>>>>>>jetjock<<<<<<<<<<
>

Must be something to do with your settings - they took me to photos!
--
Cheers,
Roger

[Java Jive]

On Sat, 9 Jan 2021 12:28:00 -0500, "Mayayana"
<maya...@invalid.nospam> wrote:

> "Java Jive" <ja...@evij.com.invalid> wrote
>
> | www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(nrm).png
> | www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(fixed).png

I should have added that for this one I included the water with the
sky in the channel colour correction.

> Interesting. It still looks slightly too blue/purple to me.
> But certainly far better than the original. There's only so
> much you can do with limited color data.

Yes, once I realised that this was going to produce a reasonable
result, I experimented a bit with different channel settings. It was
several days ago that I completed them, but AFAICR, I could either get
the greys of the clouds grey, or their whites white, but not both
together, so I chose the latter, with the result that the greys are
slightly bluish.

Despite being corrected to bring the gable end of the building to
white, the rest of that photo in particular does still look pinkish in
places - particularly the concrete of the dam and rocks of the river
bank in the foreground, and some bits of the horizon in the distance -
but these were not so amenable to the same technique, and, as you
agreed, it's a whole lot better than the original, so I decided to
accept it like that.

I think the most miraculous rescue is the Holiday #1 picture. When
you compare the original with the fixed version, you'd almost not know
that there was ever such an apparently insoluble problem!

[Java Jive]

On Sat, 09 Jan 2021 11:46:33 -0600, jetjock <jet...@unkown.com>
wrote:

>
> None of the links here take you to a photo. They all redirect to your
> "File not found" page.

Sorry, but it's most probably your newsreader - some of them, such
as Agent, don't include brackets as being valid URL, though WTF I
don't know, but instead cut short the URL at the preceding character.
If you really want to see the images, you'll have to select and copy
each entire URL up to and including '.png' and paste it into the
address bar of your browser.

[nospam]

In article <2dtjvftphoe5fvia2...@4ax.com>, Java Jive

<ja...@evij.com.invalid> wrote:

> >
> > None of the links here take you to a photo. They all redirect to your
> > "File not found" page.
>
> Sorry, but it's most probably your newsreader - some of them, such
> as Agent, don't include brackets as being valid URL, though WTF I
> don't know, but instead cut short the URL at the preceding character.
> If you really want to see the images, you'll have to select and copy
> each entire URL up to and including '.png' and paste it into the
> address bar of your browser.

the main problem is you are not prefixing the urls with https:// and
secondarily, not enclosing the entire url in <> delimiters.

basically, the links you've posted are invalid.

[nospam]

In article <8ntjvfds0i0rm9rhg...@4ax.com>, Char Jackson

<no...@none.invalid> wrote:

> >None of the links here take you to a photo. They all redirect to your
> >"File not found" page.
> >

> > >>>>>>>>>>jetjock<<<<<<<<<<
>
> If you enclose them in angle brackets, they should work fine. The problem
> is that they contain an embedded space. It would have been nice if the OP
> had included the brackets for us, but in fairness not all newsreaders have
> this problem.

there isn't an embedded space.

> Examples (c/p from above):
> <www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(nrm).png>
> <www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(fixed).png>
> >>
> <www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>
> <www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(fixed).png>

those are still broken since they do not include the protocol, in this
case https:

this is the correct format:
<https://www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>

[Java Jive]

On Sat, 09 Jan 2021 12:37:44 -0600, Char Jackson <no...@none.invalid>
wrote:

>
> If you enclose them in angle brackets, they should work fine. The problem
> is that they contain an embedded space.

No, I removed all the spaces, it's the brackets () that are the
problem here.

> It would have been nice if the OP
> had included the brackets for us, but in fairness not all newsreaders have
> this problem.

Yes, normally I use Thunderbird, which doesn't have any problem at all
with these URLs as posted. Sorry about that, wrist slap accepted.

[Char Jackson]

On Sat, 09 Jan 2021 13:43:03 -0500, nospam <nos...@nospam.invalid> wrote:

>In article <8ntjvfds0i0rm9rhg...@4ax.com>, Char Jackson
><no...@none.invalid> wrote:
>
>> >None of the links here take you to a photo. They all redirect to your
>> >"File not found" page.
>> >
>> > >>>>>>>>>>jetjock<<<<<<<<<<
>>
>> If you enclose them in angle brackets, they should work fine. The problem
>> is that they contain an embedded space. It would have been nice if the OP
>> had included the brackets for us, but in fairness not all newsreaders have
>> this problem.
>
>there isn't an embedded space.

You're right. My fixed pitch font and my carelessness got the best of me.

>> Examples (c/p from above):
>> <www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(nrm).png>
>> <www.macfh.co.uk/Temp/Scotland_-_From_The_Dam_At_Pitlochry_(fixed).png>
>> >>
>> <www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>
>> <www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(fixed).png>
>
>those are still broken since they do not include the protocol, in this
>case https:
>
>this is the correct format:
><https://www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>

My systems don't need the protocol and they default to http://, which works
fine. Https:// also works, but isn't required in this case. Most servers,
if they require https://, will simply issue a redirect.

--

Char Jackson

[Rene Lamontagne]

They all work fine on my system, also without any changes. :-)

Rene

[nospam]

In article <mk0kvfh4a6h68eqi6...@4ax.com>, Char Jackson

it's more so that apps (not just newsreaders) can auto-detect it being
a clickable link.

[Char Jackson]

You T-bird users are special that way. :-)

--

Char Jackson

[Ken Hart]

I had no problem with the OP's links, without angle brackets or http. I
use linux Thunderbird.

--
Ken Hart
kwh...@frontier.com

[nospam]

In article <rtevqp$1k0p$1...@gioia.aioe.org>, Ken Hart

<kwh...@frontier.com> wrote:

> >> <www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>
> >> <www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(fixed).png>
> >
> > those are still broken since they do not include the protocol, in this
> > case https:
> >
> > this is the correct format:
> > <https://www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>
> >
>
> I had no problem with the OP's links, without angle brackets or http. I
> use linux Thunderbird.

that just means thunderbird is non-compliant in yet another way.

the protocol is *required*. without it, it's just plain text.

[Mark Lloyd]

On 1/9/21 11:46 AM, jetjock wrote:

[snip]

>> www.macfh.co.uk/Temp/Scotland_-_Holiday_2_(cleaned).png
>>
>> ... so, although I don't think it was originally, it's now officially
>> a sunset!
>

> None of the links here take you to a photo. They all redirect to your
> "File not found" page.
>
> >>>>>>>>>>jetjock<<<<<<<<<<

I got photos. I wonder if the links were posted before the photos (when
they were invalid).

--
Mark Lloyd
http://notstupid.us/

"Some people miss the message because they are too busy checking the
spelling." - NW

[Ken Hart]

So, since my software provides the results that I want and expect, it's
bad? If it didn't do what I want, that would be good?


--
Ken Hart
kwh...@frontier.com

[nospam]

In article <rtfoel$17u7$1...@gioia.aioe.org>, Ken Hart

<kwh...@frontier.com> wrote:

> >>>
> >>> this is the correct format:
> >>> <https://www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>
> >>>
> >>
> >> I had no problem with the OP's links, without angle brackets or http. I
> >> use linux Thunderbird.
> >
> > that just means thunderbird is non-compliant in yet another way.
> >
> > the protocol is *required*. without it, it's just plain text.
> >
>
> So, since my software provides the results that I want and expect, it's
> bad? If it didn't do what I want, that would be good?

it is bad if it's non-compliant with industry specs which provides for
people to communicate with one another.

it's also bad that you can't see beyond your own needs and desires and
insist that your preference is the new standard which everyone must
obey.

[William Unruh]

On 2021-01-10, nospam <nos...@nospam.invalid> wrote:
> In article <rtfoel$17u7$1...@gioia.aioe.org>, Ken Hart
><kwh...@frontier.com> wrote:
>
>> >>>
>> >>> this is the correct format:
>> >>> <https://www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>
>> >>>
>> >>
>> >> I had no problem with the OP's links, without angle brackets or http. I
>> >> use linux Thunderbird.
>> >
>> > that just means thunderbird is non-compliant in yet another way.
>> >
>> > the protocol is *required*. without it, it's just plain text.
>> >
>>
>> So, since my software provides the results that I want and expect, it's
>> bad? If it didn't do what I want, that would be good?
>
> it is bad if it's non-compliant with industry specs which provides for
> people to communicate with one another.

Oh nuts. Almost all browsers will accept a wide range of address
formats. Standards mean that that it has to accept addresses in the
form of the address. It can also accept others.

>
> it's also bad that you can't see beyond your own needs and desires and
> insist that your preference is the new standard which everyone must
> obey.

It is bad you cannot see beyond your Soviet lawyer mentality and
that your opinion on the rules are all that that is allowed (everything
not explicity allowed is forbidden).

Noone MUST obey the given standard. Almost all browers will
accept a wide range of forms for the addresses. The user can decide to use a more
restrictive browser if they so desire. But they are under no obligation
to do so.

If you decide to do so, then either refuse to look at any forms which
deviate from your standard, or, do like most browers do, translate it
into a form which is acceptable to your restrictive brower. You
apparently know how to do so.

[nospam]

In article <rtg5gt$hq0$1...@dont-email.me>, William Unruh

<un...@invalid.ca> wrote:

> > it is bad if it's non-compliant with industry specs which provides for
> > people to communicate with one another.
>
> Oh nuts. Almost all browsers will accept a wide range of address
> formats. Standards mean that that it has to accept addresses in the
> form of the address. It can also accept others.

the issue is not the browser.

the standard is so that *apps* can auto-detect links within ordinary
text and make them clickable.

it's not just newsreaders either, but messaging apps, text editors,
word processors and much more.

without a standard format, it would be impossible to auto-detect a
domain such as delicious.pizza in a block of text.

meanwhile, <http://delicious.pizza> works. it's even available for
purchase.

[William Unruh]

On 2021-01-11, nospam <nos...@nospam.invalid> wrote:
> In article <rtg5gt$hq0$1...@dont-email.me>, William Unruh
><un...@invalid.ca> wrote:
>
>> > it is bad if it's non-compliant with industry specs which provides for
>> > people to communicate with one another.
>>
>> Oh nuts. Almost all browsers will accept a wide range of address
>> formats. Standards mean that that it has to accept addresses in the
>> form of the address. It can also accept others.
>
> the issue is not the browser.

Sure, the issue is the browser. The context of the email you were
replying to was someone complaining that attempting to connect to the
given URLS produced a "No such page" error. That was a browser. You then
popped in with your excathedra "law" that the problem was that the
format of the listed URLS is wrong, and that explained the posters
problem. It was not. It might be that the poster was using one of the
brain dead browsers which refused to connect to the addresses (but it
seems to have tried to give that error message). It was NOT that he when
he clicked on the string, it did not try to connect. It was that when he
tried to connect, his browser tried to connect and failed.

>
> the standard is so that *apps* can auto-detect links within ordinary
> text and make them clickable.

Who cares if apps cannot autodetect those links? That was not the
problem.

>
> it's not just newsreaders either, but messaging apps, text editors,
> word processors and much more.

Who cares?

>
> without a standard format, it would be impossible to auto-detect a
> domain such as delicious.pizza in a block of text.

Find.

>
> meanwhile, <http://delicious.pizza> works. it's even available for
> purchase.

Well, go buy it

[nospam]

In article <rtgbcc$p2m$1...@dont-email.me>, William Unruh

<un...@invalid.ca> wrote:

> >> > it is bad if it's non-compliant with industry specs which provides for
> >> > people to communicate with one another.
> >>
> >> Oh nuts. Almost all browsers will accept a wide range of address
> >> formats. Standards mean that that it has to accept addresses in the
> >> form of the address. It can also accept others.
> >
> > the issue is not the browser.
>
> Sure, the issue is the browser.

it is not.

as i said, it's so that text-based apps (newsreaders, email, messaging,
text editors, etc.) can reliably auto-detect urls from ordinary text
and make them clickable, or at a minimum, highlight them appropriately.

> The context of the email you were
> replying to

that is also incorrect. i was replying to a usenet post, not an email.

> was someone complaining that attempting to connect to the
> given URLS produced a "No such page" error. That was a browser.

that is partly because it was an invalid url and partly because the
reader probably did something wrong in copy/pasting it into their
browser, something that is more likely if it's invalid.

> You then
> popped in with your excathedra "law" that the problem was that the
> format of the listed URLS is wrong, and that explained the posters
> problem. It was not. It might be that the poster was using one of the
> brain dead browsers which refused to connect to the addresses (but it
> seems to have tried to give that error message). It was NOT that he when
> he clicked on the string, it did not try to connect. It was that when he
> tried to connect, his browser tried to connect and failed.

the problem is that the url was not properly formatted as per the rfcs.

standards are there for a reason.

ignoring standards is going to cause problems. this is one example of
that.

> > the standard is so that *apps* can auto-detect links within ordinary
> > text and make them clickable.
>
> Who cares if apps cannot autodetect those links? That was not the
> problem.

users of those apps care, and yes it was the problem.

prefixing it with https:// and enclosing it in <> makes it clickable
and it properly resolves. problem solved.

> > it's not just newsreaders either, but messaging apps, text editors,
> > word processors and much more.
>
> Who cares?

users of those apps care.

it's a lot easier to click a link than manually copy/paste a block of
text, remove any embedded whitespace and then paste it into a browser.

computers are there to do work for you, not the other way around.

> > without a standard format, it would be impossible to auto-detect a
> > domain such as delicious.pizza in a block of text.
>
> Find.

that is impractical and actually, impossible.

> > meanwhile, <http://delicious.pizza> works. it's even available for
> > purchase.
>
> Well, go buy it

maybe i will. i'll even give you a discount on your first order.

[William Unruh]

On 2021-01-11, nospam <nos...@nospam.invalid> wrote:

> In article <rtgbcc$p2m$1...@dont-email.me>, William Unruh
><un...@invalid.ca> wrote:
>
>> The context of the email you were
>> replying to
>
> that is also incorrect. i was replying to a usenet post, not an email.

I will give you that one. The rest I am afraid are still rediculous.
copy and past is not that difficult. And clicking on embedded urls is
NOT something you or anyone else should be doing. It is extremely
dangerous, since the url that is actually accesses could easily be
entirely different from the url listed especially with html posts.

The more one can do to prevent people from doing that, the better it is.
If posting "non-standard" URLS stops people from clicking, then that is
a huge point in its favour.

>
>> was someone complaining that attempting to connect to the
>> given URLS produced a "No such page" error. That was a browser.
>
> that is partly because it was an invalid url and partly because the

You have zero evidence that that was why the reader had problems.

> reader probably did something wrong in copy/pasting it into their
> browser, something that is more likely if it's invalid.
>
>> You then
>> popped in with your excathedra "law" that the problem was that the
>> format of the listed URLS is wrong, and that explained the posters
>> problem. It was not. It might be that the poster was using one of the
>> brain dead browsers which refused to connect to the addresses (but it
>> seems to have tried to give that error message). It was NOT that he when
>> he clicked on the string, it did not try to connect. It was that when he
>> tried to connect, his browser tried to connect and failed.
>
> the problem is that the url was not properly formatted as per the rfcs.

As I said who cares, and as I say, Good on the original poster.

>
> standards are there for a reason.
>
> ignoring standards is going to cause problems. this is one example of
> that.

Again you have zero evidence for that contention.

>
>> > the standard is so that *apps* can auto-detect links within ordinary
>> > text and make them clickable.
>>
>> Who cares if apps cannot autodetect those links? That was not the
>> problem.
>
> users of those apps care, and yes it was the problem.

And was the person a user of those apps?

>
> prefixing it with https:// and enclosing it in <> makes it clickable
> and it properly resolves. problem solved.

Nonesense.

>
>> > it's not just newsreaders either, but messaging apps, text editors,
>> > word processors and much more.
>>
>> Who cares?
>
> users of those apps care.
>
> it's a lot easier to click a link than manually copy/paste a block of
> text, remove any embedded whitespace and then paste it into a browser.

Yes, and far easier to find oneself down the rabbit hole of security
eating rabbit.

[Java Jive]

On Sun, 10 Jan 2021 21:04:02 -0500, Ron C <r.c...@verizon.net> wrote:
>
> Seems the photos part of this [sub] thread has gotten derailed
> for non-photo related link issues. :-(
> ~~
> I took a stab at fixing the Salmon-Ladder photo before the holidays,
> them got a bit distracted.
> Anyway, for what it's worth, here's a link to my effort.
> [Sorry, this was done in Photoshop and I know you don't have that tool.]
> <
> https://www.dropbox.com/s/jg1sy2elxdhdyzi/SalmonLadderAtPitlochry-%5BB1%5D.jpg
> >
> Note: I did not do any zone selection/masking stuff in
> correction/adjustment my process.

I'd class that as a good effort. I think my sky and clouds are better
than yours, but your rest of picture is better than mine.

Perhaps for the benefit of others you'd like to share the steps you
took in Photoshop?

[Frank Slootweg]

William Unruh <un...@invalid.ca> wrote:
> On 2021-01-10, nospam <nos...@nospam.invalid> wrote:
> > In article <rtfoel$17u7$1...@gioia.aioe.org>, Ken Hart
> ><kwh...@frontier.com> wrote:
> >
> >> >>> this is the correct format:
> >> >>> <https://www.macfh.co.uk/Temp/Scotland_-_Holiday_0_(nrm).png>
> >> >>
> >> >> I had no problem with the OP's links, without angle brackets or http. I
> >> >> use linux Thunderbird.
> >> >
> >> > that just means thunderbird is non-compliant in yet another way.
> >> >
> >> > the protocol is *required*. without it, it's just plain text.
> >>
> >> So, since my software provides the results that I want and expect, it's
> >> bad? If it didn't do what I want, that would be good?
> >
> > it is bad if it's non-compliant with industry specs which provides for
> > people to communicate with one another.
>
> Oh nuts. Almost all browsers will accept a wide range of address
> formats. Standards mean that that it has to accept addresses in the
> form of the address. It can also accept others.
>
> > it's also bad that you can't see beyond your own needs and desires and
> > insist that your preference is the new standard which everyone must
> > obey.
>
> It is bad you cannot see beyond your Soviet lawyer mentality and
> that your opinion on the rules are all that that is allowed (everything
> not explicity allowed is forbidden).

Isn't - unintended - self-satire always a pleasure to observe!?

So funny to see someone, who insists on posting in all lower-case and
snips attributions and relevant context, give lessons on standards and
complain about people who "can't see beyond their own needs and
desires"!

[...]

[nospam]

In article <rtglqs$36i$1...@dont-email.me>, William Unruh

<un...@invalid.ca> wrote:

> >> The context of the email you were
> >> replying to
> >
> > that is also incorrect. i was replying to a usenet post, not an email.
>
> I will give you that one. The rest I am afraid are still rediculous.
> copy and past is not that difficult. And clicking on embedded urls is
> NOT something you or anyone else should be doing. It is extremely
> dangerous, since the url that is actually accesses could easily be
> entirely different from the url listed especially with html posts.

you're confused. this is not about html posts. it's about a url in
plain text (usenet, email, messaging, text document, etc.)

if a link is dangerous, there is no difference between copy/pasting it
and clicking on it, other than it requires additional steps that are
not needed.

regarding the format:
<https://tools.ietf.org/html/rfc3986#appendix-C>
URIs are often transmitted through formats that do not provide a
clear context for their interpretation. For example, there are many
occasions when a URI is included in plain text; examples include text
sent in email, USENET news, and on printed paper. In such cases, it
is important to be able to delimit the URI from the rest of the text,
and in particular from punctuation marks that might be mistaken for
part of the URI.
...
Using <> angle brackets around each URI is especially recommended as
a delimiting style for a reference that contains embedded whitespace.

The prefix "URL:" (with or without a trailing space) was formerly
recommended as a way to help distinguish a URI from other bracketed
designators, though it is not commonly used in practice and is no
longer recommended.

> The more one can do to prevent people from doing that, the better it is.
> If posting "non-standard" URLS stops people from clicking, then that is
> a huge point in its favour.

that's absurd. making things more difficult to use is not a useful goal.

[Anton Shepelev]

Java Jive:

> This is the original scan of the negative corrected to be
> positive ...

So one crucial step is already done. Negative-to-positive
conversion is the most important step and takes great care
to perform correctly:

http://www.c-f-systems.com/Docs/NegativePositiveCFS-244.pdf

I have a draft of an article somewhere that explains the
same thing in simpler and more convenient terms, and can
share it upon request.

Correct scanning is also very important: do not let your
scanner process the image in any way! Unfortunately,
default scanner software will do nasty things to your scans
whatever you do, so I use VueScan. With my NikonScan film
scanner, I make an initial adjustment of the white balance
by setting such expusures for the scaller's R, G, B LEDs as
will make the orange unexposed area on the film nearly white
(e.g. 248/248/248). I never let scanner software do anything
except scanning.

> ... and this is the above after applying colour correction
> to bring the white of the clouds to true white, in other
> words 255,255,255:
>
> www.macfh.co.uk/Temp/SalmonLadderAtPitlochry-PnormColourCorrected.png

That may be a case of violated color integrity:

http://www.c-f-systems.com/Complete/CompleteColorIntegrity.html

I see you are using NetPbm. Try my NetPbm programs for color
correction:

For white balance in linear RGB:
http://netpbm.sourceforge.net/doc/pamlevels.html

For saturation:
http://netpbm.sourceforge.net/doc/pamaltsat.html

I will now brag a little and post an example of the
application of these two programs to a test image: first
`pamlevels' and then `pamaltsat':

https://freeshell.de/~antonius/img_host/horse_sample.png

--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]