A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » General Hardware & Peripherals » Scanners
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Archival scans, 48bit, Nikon Coolscan 5000 ED, ? Gamma 1.0 ?



 
 
Thread Tools Display Modes
  #1  
Old August 16th 04, 09:52 PM
Gary Whitehead
external usenet poster
 
Posts: n/a
Default Archival scans, 48bit, Nikon Coolscan 5000 ED, ? Gamma 1.0 ?

Hi All,

I wish to scan ~3-4000 slides, for two reasons, one to have the images
available electronically but mainly to have a safe archive/backup of the
images (most of these slides cover the period when I used to work for the
British Antarctic Survey, are c20 years old and I would be gutted if I lost
them...).

I've had a Nikon Coolscan 5000 ED for a couple of months, and have spent the
time becoming familiar with it.... and colour management. On the colour
management issues I am now just starting to get a good overall idea of how
things work (and I must admit it was not simple, and I am speaking as a
lapsed physicist!).

I would like to scan these slides ONCE - i.e. I would like to get it right
the first time. I intend to scan at 48bits and 4000dpi (i.e. the max
resolution of the scanner).

Can anyone comment on the scenario below:

---------------------

* 16bits/channel / 4000dpi
* Raw scanner RGB at - gamma 1.0 - (Nikon colour management turned off).
* Only processing performed by the scanner being digital ICE
* Scanner calibrated using it8 targets and resultant icc profiles used to
perform conversion to the working colour space (presently Wide Gamut RGB)
on import of the raw gamma 1.0 files to Photoshop

----------------------

I am aware that there is a somewhat heated discussion on the subject of
gamma 1.0 editing, which is not what I am proposing here. My concern is
complete retention of the data delivered by the scanner. My reasoning is:

* The scanner sensor has a 16bit resolution.
* I acknowledge the sense in outputing a higher gamma file when using 8
bits/channel in order to space the resultant resolution perceptually.
However when performing such a transform on the full bit data all I see is
an increase in spacing of the scanner resolution at the shadow end at the
cost of lost information in the highlights. I.e. I see no gain.
* The scans are archival - I might wish to use the data in a couple of
decades, with display technologies that may be completely different from
today (i.e. why gamma encode the data with a value that derives from
today's display technology).

I would be particularly interested to hear from people in the high gamma
camp(!), since I would guess from the gamma 1.0 camp I am going to hear "Go
for it". The only potential problem that I can see here is whether the
application of a gamma 2.2 curve through Photoshop/icc profile is any less
accurate than in the scanner itself. I acknowledge that there may be
others I have missed....

Cheers,

Gary Whitehead.



N.B. I too fought with the colour management on the scanner, and gave up in
near disgust. Wolf Faust's targets, and resultant ICC profiles gave the
best results I had seen within minutes of generating them!
  #2  
Old August 16th 04, 10:04 PM
Jim
external usenet poster
 
Posts: n/a
Default


"Gary Whitehead" wrote in message
...
Hi All,

Can anyone comment on the scenario below:

---------------------

* 16bits/channel / 4000dpi
* Raw scanner RGB at - gamma 1.0 - (Nikon colour management turned off).
* Only processing performed by the scanner being digital ICE
* Scanner calibrated using it8 targets and resultant icc profiles used to
perform conversion to the working colour space (presently Wide Gamut RGB)
on import of the raw gamma 1.0 files to Photoshop

This seems to me to be the preferred method. Create a profile of your
scanner with color management turned off. You then take the resultant
output to whichever program you prefer, apply the profile, and convert to
whichever working color space you desire. It works for me.
Jim


  #3  
Old August 16th 04, 11:03 PM
RSD99
external usenet poster
 
Posts: n/a
Default

Sounds good ... but jus to be sure include a raw scan of a well-known target ... such as
an IT-8 target for which you have the data, or an image of an Macbeth color checker ...
with your archives.





"Gary Whitehead" wrote in message
...
Hi All,

I wish to scan ~3-4000 slides, for two reasons, one to have the images
available electronically but mainly to have a safe archive/backup of the
images (most of these slides cover the period when I used to work for the
British Antarctic Survey, are c20 years old and I would be gutted if I lost
them...).

I've had a Nikon Coolscan 5000 ED for a couple of months, and have spent the
time becoming familiar with it.... and colour management. On the colour
management issues I am now just starting to get a good overall idea of how
things work (and I must admit it was not simple, and I am speaking as a
lapsed physicist!).

I would like to scan these slides ONCE - i.e. I would like to get it right
the first time. I intend to scan at 48bits and 4000dpi (i.e. the max
resolution of the scanner).

Can anyone comment on the scenario below:

---------------------

* 16bits/channel / 4000dpi
* Raw scanner RGB at - gamma 1.0 - (Nikon colour management turned off).
* Only processing performed by the scanner being digital ICE
* Scanner calibrated using it8 targets and resultant icc profiles used to
perform conversion to the working colour space (presently Wide Gamut RGB)
on import of the raw gamma 1.0 files to Photoshop

----------------------

I am aware that there is a somewhat heated discussion on the subject of
gamma 1.0 editing, which is not what I am proposing here. My concern is
complete retention of the data delivered by the scanner. My reasoning is:

* The scanner sensor has a 16bit resolution.
* I acknowledge the sense in outputing a higher gamma file when using 8
bits/channel in order to space the resultant resolution perceptually.
However when performing such a transform on the full bit data all I see is
an increase in spacing of the scanner resolution at the shadow end at the
cost of lost information in the highlights. I.e. I see no gain.
* The scans are archival - I might wish to use the data in a couple of
decades, with display technologies that may be completely different from
today (i.e. why gamma encode the data with a value that derives from
today's display technology).

I would be particularly interested to hear from people in the high gamma
camp(!), since I would guess from the gamma 1.0 camp I am going to hear "Go
for it". The only potential problem that I can see here is whether the
application of a gamma 2.2 curve through Photoshop/icc profile is any less
accurate than in the scanner itself. I acknowledge that there may be
others I have missed....

Cheers,

Gary Whitehead.



N.B. I too fought with the colour management on the scanner, and gave up in
near disgust. Wolf Faust's targets, and resultant ICC profiles gave the
best results I had seen within minutes of generating them!



  #4  
Old August 16th 04, 11:44 PM
Greg
external usenet poster
 
Posts: n/a
Default

Go for it.

The scanner hardware, I believe, *always* scans with a gamma of 1, with the
gamma adjustment
being performed by software.

The *only* reason I don't use a gamma of 1 is that the profiler I use (the
Little CMS scanner profiler)
will only use 8-bit scans. If I feed the profiler higher bit depth target
scans, the profiler definitely
does not make use of the extra resolution. So, I use a gamma of 2.2 to get
around this problem.

I think your workflow makes complete sense, and aside from the difference in
gamma, it's
the same as my workflow for all intents & purposes.

Greg.

"Gary Whitehead" wrote in message
...
Hi All,

I wish to scan ~3-4000 slides, for two reasons, one to have the images
available electronically but mainly to have a safe archive/backup of the
images (most of these slides cover the period when I used to work for the
British Antarctic Survey, are c20 years old and I would be gutted if I
lost
them...).

I've had a Nikon Coolscan 5000 ED for a couple of months, and have spent
the
time becoming familiar with it.... and colour management. On the colour
management issues I am now just starting to get a good overall idea of how
things work (and I must admit it was not simple, and I am speaking as a
lapsed physicist!).

I would like to scan these slides ONCE - i.e. I would like to get it right
the first time. I intend to scan at 48bits and 4000dpi (i.e. the max
resolution of the scanner).

Can anyone comment on the scenario below:

---------------------

* 16bits/channel / 4000dpi
* Raw scanner RGB at - gamma 1.0 - (Nikon colour management turned off).
* Only processing performed by the scanner being digital ICE
* Scanner calibrated using it8 targets and resultant icc profiles used to
perform conversion to the working colour space (presently Wide Gamut RGB)
on import of the raw gamma 1.0 files to Photoshop

----------------------

I am aware that there is a somewhat heated discussion on the subject of
gamma 1.0 editing, which is not what I am proposing here. My concern is
complete retention of the data delivered by the scanner. My reasoning is:

* The scanner sensor has a 16bit resolution.
* I acknowledge the sense in outputing a higher gamma file when using 8
bits/channel in order to space the resultant resolution perceptually.
However when performing such a transform on the full bit data all I see is
an increase in spacing of the scanner resolution at the shadow end at the
cost of lost information in the highlights. I.e. I see no gain.
* The scans are archival - I might wish to use the data in a couple of
decades, with display technologies that may be completely different from
today (i.e. why gamma encode the data with a value that derives from
today's display technology).

I would be particularly interested to hear from people in the high gamma
camp(!), since I would guess from the gamma 1.0 camp I am going to hear
"Go
for it". The only potential problem that I can see here is whether the
application of a gamma 2.2 curve through Photoshop/icc profile is any less
accurate than in the scanner itself. I acknowledge that there may be
others I have missed....

Cheers,

Gary Whitehead.



N.B. I too fought with the colour management on the scanner, and gave up
in
near disgust. Wolf Faust's targets, and resultant ICC profiles gave the
best results I had seen within minutes of generating them!



  #5  
Old August 18th 04, 07:10 PM
Gary Whitehead
external usenet poster
 
Posts: n/a
Default

Greg wrote:

The *only* reason I don't use a gamma of 1 is that the profiler I use (the
Little CMS scanner profiler)
will only use 8-bit scans. If I feed the profiler higher bit depth target
scans, the profiler definitely
does not make use of the extra resolution. So, I use a gamma of 2.2 to get
around this problem.


I have been thinking about this and looking at my scans of the IT8 targets.
I don't think that it actually matters much that we profile the scanners
using 8 bit scans.

Reasoning:

1. The scanned targets are actually quite noisy (film grain/target surface),
giving in the midtones (using Photoshop's histogram tool) a standard
deviation ~4-5bit (out of 256) on each channel, and maybe 1.5bits in the
highlights, and 0.5bits in the shadows (for a single target square).
Before anyone shouts at Wolf Faust, as I will explain below this is "Good
Thing".

2. At 4000dpi we are averaging around 10000 samples for a colour square and
maybe 40000 for a greyscale square. The resolution of the average can be
approximated to the standard error which will be

SD/SquareRoot(NoOfSamples).

This gives me in the case of the midtones a standard error of around 1/25th
of a bit for a colour square, which is almost an extra 5 bits of precision,
i.e. around 13bits. No useful improvement would be seen by using a 16 bit
scan. The other way of looking at it is that the quantisation noise of
8bit sampling (0.5bit) is insignificant compared to the target noise.
(Errors should be added as a sum of squares).

This is actually a standard technique in digital measurement, where it is
recognised that the mixture of some noise (greater than the bit resolution)
and averaging multiple samples allows sub bit resolution.

The only area that I have some doubt on this argument is in the deep
highlights (1-3 bits) and shadows. It is possible that there may be some
clipping of the noise component which would tend to shift the average
towards the midtones. I will take a look at a 16bit image later which I
will range expand (i.e. expand levels 0-2 - 0-256). The test here is
whether I see a normal distribution of points. If I do, then this should
also be safe at the extremes.

Of course this does all depend on the profiler perfoming its calculation in
a sufficiently accurate data type and exporting the profiles in 16bits.
Little CMS does appear to use the LUT16Type in its output, but I have not
checked the code to see how it is calculated.
  #6  
Old August 19th 04, 12:26 AM
Greg
external usenet poster
 
Posts: n/a
Default

Gary,
I have not digested your notes in detail yet, but, I do know that the
version of the Little
CMS profiler I am using definitely will *not* use anything greater than
8-bits per channel
in the IT8 scans - I have even had this confirmed by the author himself. It
will load
the scan and process it, but it will not use the extra precision - it will
discard it.
Because of this, the author himself has said that it is very important *not*
to use a gamma
1 scan - it is important to use a perceptually uniform gamma, such as 2.2.
As you say, this issue is specific to the profiling software - other
profilers which really
can use the full precision would be entirelly suitable for use with gamma 1
IT8 target
scans.

Now, after saying all this, I am not sure whether there is a more recent
version of the
profiler available now - it's possible that this limitation has been
removed.

Greg.

"Gary Whitehead" wrote in message
...
Greg wrote:

The *only* reason I don't use a gamma of 1 is that the profiler I use
(the
Little CMS scanner profiler)
will only use 8-bit scans. If I feed the profiler higher bit depth target
scans, the profiler definitely
does not make use of the extra resolution. So, I use a gamma of 2.2 to
get
around this problem.


I have been thinking about this and looking at my scans of the IT8
targets.
I don't think that it actually matters much that we profile the scanners
using 8 bit scans.

Reasoning:

1. The scanned targets are actually quite noisy (film grain/target
surface),
giving in the midtones (using Photoshop's histogram tool) a standard
deviation ~4-5bit (out of 256) on each channel, and maybe 1.5bits in the
highlights, and 0.5bits in the shadows (for a single target square).
Before anyone shouts at Wolf Faust, as I will explain below this is "Good
Thing".

2. At 4000dpi we are averaging around 10000 samples for a colour square
and
maybe 40000 for a greyscale square. The resolution of the average can be
approximated to the standard error which will be

SD/SquareRoot(NoOfSamples).

This gives me in the case of the midtones a standard error of around
1/25th
of a bit for a colour square, which is almost an extra 5 bits of
precision,
i.e. around 13bits. No useful improvement would be seen by using a 16 bit
scan. The other way of looking at it is that the quantisation noise of
8bit sampling (0.5bit) is insignificant compared to the target noise.
(Errors should be added as a sum of squares).

This is actually a standard technique in digital measurement, where it is
recognised that the mixture of some noise (greater than the bit
resolution)
and averaging multiple samples allows sub bit resolution.

The only area that I have some doubt on this argument is in the deep
highlights (1-3 bits) and shadows. It is possible that there may be some
clipping of the noise component which would tend to shift the average
towards the midtones. I will take a look at a 16bit image later which I
will range expand (i.e. expand levels 0-2 - 0-256). The test here is
whether I see a normal distribution of points. If I do, then this should
also be safe at the extremes.

Of course this does all depend on the profiler perfoming its calculation
in
a sufficiently accurate data type and exporting the profiles in 16bits.
Little CMS does appear to use the LUT16Type in its output, but I have not
checked the code to see how it is calculated.



  #7  
Old August 19th 04, 11:45 AM
Greg
external usenet poster
 
Posts: n/a
Default

Gary,
I have checked with the author (Marti Maria), and there is in fact a new
version of the scanner
program, available he http://www.littlecms.com/profiler_qs.htm and this
really
does work with high resolution scans, and so in theory, gamma 1 should be
safe.
Marti cautions us that a) there is no support, and b) we should test it
thoroughly
with gamma 1 before relying on it too much, as gamma 1 still needs great
care.

If this is the version you're already using, then ignore my earlier warning.

Greg.
p.s I post this information with permission from Marti.


  #8  
Old August 17th 04, 03:28 AM
bmoag
external usenet poster
 
Posts: n/a
Default

Have you considered the practical realities of creating files this large,
about 100mbs per file?

Have you considered the real world utility of 16 bit color vs the ideal
(i.e. no monitor or printing method can utilize that much color information
and will in some way arbitrarily truncate it anyway)?

I hope your are a very young man so that you may live to complete this
project.



  #9  
Old August 17th 04, 03:59 AM
Greg
external usenet poster
 
Posts: n/a
Default

Good point - I forgot to mention that I use JPEG 2000 to archive my scans.

Gary - I suggest you look into JPEG 2000 as a possibility for storing your
achives. JPEG 2000 supports greater than 8-bit per channel encoding, whereas
standard JPEG doesn't.

Yes, I use JPEG 2000 in lossy mode, but it does have a lossless mode as
well.

Greg.
"bmoag" wrote in message
m...
Have you considered the practical realities of creating files this large,
about 100mbs per file?

Have you considered the real world utility of 16 bit color vs the ideal
(i.e. no monitor or printing method can utilize that much color
information
and will in some way arbitrarily truncate it anyway)?

I hope your are a very young man so that you may live to complete this
project.





  #10  
Old August 17th 04, 07:49 AM
Gary Whitehead
external usenet poster
 
Posts: n/a
Default

DAT tapes!

Having the disc space for this is not a problem nowadays, but I certainly
would not be doing it without backup. The entire collection should fit on
around 30 tapes (12GB), at a cost of about 150 euros.

I'm also reckoning on us being at a cusp, i.e. in a few years the amount of
data that this will produce will fit easily into normal spec machines.

Cheers,

Gary.

bmoag wrote:

Have you considered the practical realities of creating files this large,
about 100mbs per file?

Have you considered the real world utility of 16 bit color vs the ideal
(i.e. no monitor or printing method can utilize that much color
information and will in some way arbitrarily truncate it anyway)?

I hope your are a very young man so that you may live to complete this
project.


 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Nikon Coolscan LS50 slide feeder? Ian Scanners 3 May 7th 04 01:08 AM
Slides VERY dark with Nikon Super CoolScan 5000ED gabor Scanners 0 April 20th 04 04:31 PM
Nikon Coolscan 5000 ED Norman & Nancy Perry Scanners 8 February 9th 04 07:07 AM
Nikon CoolScan II & windows XP CSM1 Scanners 0 September 12th 03 04:00 PM
Film Scanners - Nikon about to replace the Super Coolscan 8000 ED? J. Smith Scanners 0 July 13th 03 02:55 AM


All times are GMT +1. The time now is 03:26 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.