RE: So it's the bits? (Was: filmscanners: Sprintscan 120
> Rafe thanks - I do this sort of thing regularly (shows I am not good at > taking flat, well-lit shots!). The problem I was discussing arises when > you get blooming from one scanner exposure to another - then it becomes > difficult if not impossible to combine them satisfactorily using these > techniques. The difficulty is that the blooming extends over a small > "dark" area of the hi-exposure scan that is therefore not covered > satisfactorily by that scan, but it is also not covered satisfactorily by > the low- exposure scan (still too dark). You get horrible edges, whether > you use the manual masking that you describe, or a kind of semi-automatic > masking such as using one of the image exposures (inverted) as the mask. > (the last technique was described here some time ago, but I have found > doing it manually to be better in general). > > It is only a problem where your image has very high contrast at an edge, > not when you get more gradual changes. It is possible that if I were more > > careful I might be able to do it better, so that I was using the low > exposure pass for the edges of the "dark side", which you probably would > not notice. This I gather is what Dean is doing in his software - > which I think would make a great photoshop plug-in. > > Dean wrote: > >Some CCDs feature anti-blooming so that this does not happen. Anyone know > >if any of the linear CCDs used in scanners have this? A way around this > >problem is to throw away any pixels above a certain value PLUS its > >neighbors. These pixels get their values from a lower exposure pass. I > >have implemented this type of multi exposure for a completely different > type > >of application and it works fairly well. > > >Afraid this won't be of any use to you - the combining of multiple > exposure > >levels was done in a custom application written in C++ running under > Unix. > >It was just one small part of a much larger program that I helped write. > > > Let me describe some of what the software did and how it might relate to combining images taken with different exposure levels. The software was using multiple exposure levels to obtain information from scenes containing extremely high dynamic ranges. In order to capture the entire range, we would take 3 or 4 sets of images, each with 4 times the exposure of the previous set. The limitation was haze from the bright reflections swamping out the dark regions and blooming causing entire regions of the CCD to be unusable. In order to eliminate this, we would physically block the light from the very brightest regions while taking the longer exposure images. Our base image would be the darkest image - the brightest spot would be just below saturation on the camera. We would then take the next brightest image and create a mask for all pixels above some threshold level (below saturation). Because the blooming causes light to spill over from the blooming pixel to the adjacent pixels, we would perform a dilation operation (Photoshop grow region?) on the mask. Typically we would increase the size of the mask by two pixels in all directions. This mask would then be used to combine the information from the two images. Repeat for each additional exposure level. We were not after the image itself, but rather other information within the set of images. I expect that the hardest part for obtaining a good image would be matching the intensity levels from one image to the next. You wanted to increase the exposure time by exactly two stops but the shutter was may be off by 10-20% If I were writing a program or plugin to do the combining, I would define some overlap region where I expect pixels from both images to be reasonably good and to perform a regression on these pixels to match levels from the two images. > > Dean Shough > [EMAIL PROTECTED] >
RE: So it's the bits? (Was: filmscanners: Sprintscan 120
> > Some CCDs feature anti-blooming so that this does not happen. > > I think all current generation CCD's try to do this, but there's still a > point at > which charge leaks between pixels. > > This may be true for linear CCDs, but it is definitely not standard for scientific CCDs. When I last looked about 3 years ago, NO scientific CCDs were available with anti-blooming. > > Dean Shough > [EMAIL PROTECTED] >
RE: So it's the bits? (Was: filmscanners: Sprintscan 120
At 10:17 AM 1/17/01 +1100, Julian wrote: >At 04:42 17/01/01, Rafe wrote: >>It's not too difficult to make intelligent >>"composites" from multiple passes of a slide >>or negative -- provided the scanner and driver >>have good registration from pass to pass. > >Rafe thanks - I do this sort of thing regularly (shows I am not good at >taking flat, well-lit shots!). The problem I was discussing arises when >you get blooming from one scanner exposure to another - then it becomes >difficult if not impossible to combine them satisfactorily using these >techniques. The difficulty is that the blooming extends over a small >"dark" area of the hi-exposure scan that is therefore not covered >satisfactorily by that scan, but it is also not covered satisfactorily by >the low- exposure scan (still too dark). You get horrible edges, whether >you use the manual masking that you describe, or a kind of semi-automatic >masking such as using one of the image exposures (inverted) as the mask. >(the last technique was described here some time ago, but I have found >doing it manually to be better in general). I've never had good luck with this method when the layer masks had sharp edges, or were based on (for example) thresholding/blurring/otherwise processing the original, or one of the color channels. When I try that, the edges and the images themselves tend to look artificial. (I think this is what those $200 masking plugins are good for... ) The only layer mask that works in these cases is one with a smooth linear gradient, to blend from one exposure to the other (eg., foreground to background.) Hence my analogy to the graduated-ND filter -- which, when you think of it, should have been used in the first place. Granted, there's a limited range of photos on which this technique is based, but the situation comes up now and then in landscape photos. The layer mask just needs a smooth transition over the appropriate region of the photo. The gradient should be "hard" enough to achieve the desired effect, but not so hard as to be noticeable. The "manual" part of this method is simply deciding where to place the gradient, and how wide to make it. rafe b.
RE: So it's the bits? (Was: filmscanners: Sprintscan 120
On Mon, 15 Jan 2001 10:28:56 -0800 Shough, Dean ([EMAIL PROTECTED]) wrote: > Some CCDs feature anti-blooming so that this does not happen. I think all current generation CCD's try to do this, but there's still a point at which charge leaks between pixels. Regards Tony Sleep http://www.halftone.co.uk - Online portfolio & exhibit; + film scanner info & comparisons
RE: So it's the bits? (Was: filmscanners: Sprintscan 120
At 04:42 17/01/01, Rafe wrote: >It's not too difficult to make intelligent >"composites" from multiple passes of a slide >or negative -- provided the scanner and driver >have good registration from pass to pass. Rafe thanks - I do this sort of thing regularly (shows I am not good at taking flat, well-lit shots!). The problem I was discussing arises when you get blooming from one scanner exposure to another - then it becomes difficult if not impossible to combine them satisfactorily using these techniques. The difficulty is that the blooming extends over a small "dark" area of the hi-exposure scan that is therefore not covered satisfactorily by that scan, but it is also not covered satisfactorily by the low- exposure scan (still too dark). You get horrible edges, whether you use the manual masking that you describe, or a kind of semi-automatic masking such as using one of the image exposures (inverted) as the mask. (the last technique was described here some time ago, but I have found doing it manually to be better in general). It is only a problem where your image has very high contrast at an edge, not when you get more gradual changes. It is possible that if I were more careful I might be able to do it better, so that I was using the low exposure pass for the edges of the "dark side", which you probably would not notice. This I gather is what Dean is doing in his software - which I think would make a great photoshop plug-in. Dean wrote: >Some CCDs feature anti-blooming so that this does not happen. Anyone know >if any of the linear CCDs used in scanners have this? A way around this >problem is to throw away any pixels above a certain value PLUS its >neighbors. These pixels get their values from a lower exposure pass. I >have implemented this type of multi exposure for a completely different type >of application and it works fairly well. >Afraid this won't be of any use to you - the combining of multiple exposure >levels was done in a custom application written in C++ running under Unix. >It was just one small part of a much larger program that I helped write. Thanks again, Julian Julian Robinson in usually sunny, smog free Canberra, Australia
RE: So it's the bits? (Was: filmscanners: Sprintscan 120
On Tue, 16 Jan 2001, Shough, Dean wrote: > > more specific method? I have the same problem when trying to extract the > > most from some high contrast slides, and have not been really happy with > > some of my multiple exposure scans for this reason. > > Regards, > > Julian It's not too difficult to make intelligent "composites" from multiple passes of a slide or negative -- provided the scanner and driver have good registration from pass to pass. I've used this method on several occasions, on contrasty images. You'd use this in pretty much the same situations as you'd use a graduated-ND filter in taking the photo in the first place. A layer mask consisting of a gradient is quite helpful here. Eg., make one scan optimized for the sky, one for foreground. The top layer (say, the sky layer) would have a mask that goes from white to black in the region of the horizon of the photo. It's easy to set up Photoshop so that you can experiment with different gradients in the layer mask, while viewing the composite image. rafe b.
RE: So it's the bits? (Was: filmscanners: Sprintscan 120
> At 05:28 16/01/01, "Shough, Dean" <[EMAIL PROTECTED]> wrote: > >Some CCDs feature anti-blooming so that this does not happen. Anyone > know > >if any of the linear CCDs used in scanners have this? A way around this > >problem is to throw away any pixels above a certain value PLUS its > >neighbors. These pixels get their values from a lower exposure pass. I > >have implemented this type of multi exposure for a completely different > type > >of application and it works fairly well. > > Can you tell me how you do this - do you do it in PS or do you use some > more specific method? I have the same problem when trying to extract the > most from some high contrast slides, and have not been really happy with > some of my multiple exposure scans for this reason. > Regards, > Julian > > Afraid this won't be of any use to you - the combining of multiple exposure levels was done in a custom application written in C++ running under Unix. It was just one small part of a much larger program that I helped write. > > Dean Shough > [EMAIL PROTECTED] > > --
RE: So it's the bits? (Was: filmscanners: Sprintscan 120
At 05:28 16/01/01, "Shough, Dean" <[EMAIL PROTECTED]> wrote: >Some CCDs feature anti-blooming so that this does not happen. Anyone know >if any of the linear CCDs used in scanners have this? A way around this >problem is to throw away any pixels above a certain value PLUS its >neighbors. These pixels get their values from a lower exposure pass. I >have implemented this type of multi exposure for a completely different type >of application and it works fairly well. Can you tell me how you do this - do you do it in PS or do you use some more specific method? I have the same problem when trying to extract the most from some high contrast slides, and have not been really happy with some of my multiple exposure scans for this reason. Regards, Julian Julian Robinson in usually sunny, smog free Canberra, Australia
RE: So it's the bits? (Was: filmscanners: Sprintscan 120
> Not really following this thread so I may be missing your intent...but > whenever I've tried increasing exposure beyond "proper exposure", the CCD > saturates (ie blooms) on those pixels that were already bright. This > spills > over into the neighbouring dark pixels and ruins them. > > Some CCDs feature anti-blooming so that this does not happen. Anyone know if any of the linear CCDs used in scanners have this? A way around this problem is to throw away any pixels above a certain value PLUS its neighbors. These pixels get their values from a lower exposure pass. I have implemented this type of multi exposure for a completely different type of application and it works fairly well.
Re: So it's the bits? (Was: filmscanners: Sprintscan 120
- Original Message - From: "Julian Robinson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, January 14, 2001 6:58 PM Subject: Re: So it's the bits? (Was: filmscanners: Sprintscan 120 > And then I wonder why, when they already do > multi-passes to reduce noise as in the LS2000, why they don't up the > exposure for subsequent scans? Maybe it is hard to keep things linear? > Not really following this thread so I may be missing your intent...but whenever I've tried increasing exposure beyond "proper exposure", the CCD saturates (ie blooms) on those pixels that were already bright. This spills over into the neighbouring dark pixels and ruins them. So extra exposure has limited utility AFIAK. Byron
Re: So it's the bits? (Was: filmscanners: Sprintscan 120
At 07:45 15/01/01, Pete wrote: >All the available CCDs on the market today are limited to a dynamic range of >5000:1 (~12 bits) at normal temperatures. Aha! That is the figure I was wondering about. Thanks so much for this useful and factual piece of info. Given the physics I would guess that noise figures are already towards thermal limits (?)and if so it is not possible to do much better without cooling. So I guess too that drum scanners etc must use photomultipliers or something other than CCDs. But we don't know whether the new Nikons do or don't use split exposures - which seems to be the logical way to go for CCD scanners - and should be easy for Nikon to implement given LED sources. Maybe they do? And probably they don't looking at the fast scan times. Multiple exposures would significantly add to the scan time. I wonder if they have considered this as a slower option. And then I wonder why, when they already do multi-passes to reduce noise as in the LS2000, why they don't up the exposure for subsequent scans? Maybe it is hard to keep things linear? Just thinking aloud, Julian Julian Robinson in usually sunny, smog free Canberra, Australia
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 nowonB+H web
Hi Pete, At 10:11 13/01/01, [EMAIL PROTECTED] wrote: >And nobody, as far as I've read, is arguing that bit depth DOES define Dmax.. What I understood from Ed's and others' original point was that manufacturers were stating their Dmax (or dynamic range or density range) based only on their D/A bit depth. That was the point of this whole discussion for my part. >The original argument was that ANY old density range could be squeezed >into any >number of bits, wasn't it? Yes that is where I started from, but after reading the posts from the last time this was discussed, I now know this is wrong - rather it is one-way thing. You can have a density range which is anything you like so long as it is worse than that implied by the number of bits, but you can't have a density range that is better than implied by the number of bits. It is this last point that is the bone of contention - manufacturers are saying "ours is 14 bits so our density range is 4.2 wow isn't that a good figure", and that is probably crap in the case of the consumer level scanners we are talking about. It MAY be 4.2 but is most likely is much less than that - that is all I am saying ... I think. Cheers, Julian Julian Robinson in usually sunny, smog free Canberra, Australia
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 nowonB+H web
> And nobody, as far as I've read, is arguing that bit depth DOES define Dmax.. Correct, but it DOES define the best Dmax that the system can achieve. The system is ONLY as good as its weakest point. > The original argument was that ANY old density range could be squeezed into any > number of bits, wasn't it? There was a confusion between input voltage range of the A/D and the resolution within that range. They are separate issues, and only one is Dmax, the other is irrelevant (if designed properly).
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 nowonB+H web
Hi Julian. > But linearity explains only one half of the issue - that is, that you can't > do BETTER for dynamic range than what is implied by the number of > bits. Linearity doesn't make the most useful point that number of bits has > NOTHING to do with the actual achieved density range performance when the > noise level is the same as or more than the LSB. In other words number of > bits does NOT define Dmax, it only defines what the best possible might > be. I read most of the old "last time" posts and still didn't see any such > useful conclusion. And nobody, as far as I've read, is arguing that bit depth DOES define Dmax.. Of course it's possible to not fully utilise the available bit depth, or dynamic range, of the A/D converter. In fact it's probably desirable not to do so, since a 1 bit level change to represent a change of 0.3D isn't of much use to anyone. The original argument was that ANY old density range could be squeezed into any number of bits, wasn't it? That just isn't the case, not unless some deliberate non-linearity is introduced into the system. Hence the emphasis on linearity. Regards, Pete.
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 nowon
On Fri, 12 Jan 2001 12:22:47 +1100 Julian Robinson ([EMAIL PROTECTED]) wrote: > In other words number of > bits does NOT define Dmax, it only defines what the best possible might > be. Odd, 'cos that was the point of the whole original argument :) IE that bit depth constrains maximum OD range in scanners where there is linear mapping of intensity. Which is pretty much all of the ones any of us use. Regards Tony Sleep http://www.halftone.co.uk - Online portfolio & exhibit; + film scanner info & comparisons
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 nowon B+H web
Finally!? - Original Message - From: Austin Franklin <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 11, 2001 5:59 PM Subject: RE: So it's the bits? (Was: filmscanners: Sprintscan 120 nowon B+H web > > > In other words number of > > bits does NOT define Dmax, it only defines what the best possible might > > be. > > Absolutely correct! It is but one piece of the system, and the system is > only as good as its worst part. > > >
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 now
> > Devices are not really linear. There are a number of 'distortions'. One is > > offset, the second is linearity, and the third is gain. > I think Austin was refering to the analogue pre-amplifiers built into a lot of A/D > converters. You are correct, but I was not limiting the source of the distortion to anything in particular. These distortions can be corrected in the digital or the analog domain. I prefer the digital domain. Gain and offset can be corrected for by simple multiplication and addition (you do need to do the gain multiply first), but linearity requires a LUT. > I think the difficulty is in predicting or calculating the exact value of any offset. > Since it'll vary with individual CCD, and with temperature. Calibration can be as simple or as difficult as the designer wants to make it, but it certainly can be done.
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 nowon B+H web
> In other words number of > bits does NOT define Dmax, it only defines what the best possible might > be. Absolutely correct! It is but one piece of the system, and the system is only as good as its worst part.
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 nowon B+H web
> > Oh no! > > Not this again. > > The answer is one word - linearity. > >My reaction entirely :-) But linearity explains only one half of the issue - that is, that you can't do BETTER for dynamic range than what is implied by the number of bits. Linearity doesn't make the most useful point that number of bits has NOTHING to do with the actual achieved density range performance when the noise level is the same as or more than the LSB. In other words number of bits does NOT define Dmax, it only defines what the best possible might be. I read most of the old "last time" posts and still didn't see any such useful conclusion. Julian Robinson in usually sunny, smog free Canberra, Australia
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now
Hi Tony, Austin. Tony Sleep wrote: > Austin Franklin ([EMAIL PROTECTED]) wrote: > > > Devices are not really linear. There are a number of 'distortions'. One is > > offset, the second is linearity, and the third is gain. > > CCD's are AIUI inherently very linear. 'Offset' = CCD noise in this context, gain > = 1.0 I think Austin was refering to the analogue pre-amplifiers built into a lot of A/D converters. These allow control of gain, and can also insert or remove a deliberate analogue offset voltage. An offset voltage is the only way to alter the 'slope' of the A/D conversion, by changing the analogue value that corresponds to the LSB. Altering the gain simply sets the maximum input voltage that the A/D can handle. If you think of the A/D conversion as an anti-logarithmic (to the base 2) process, then it's easy to see that an addition or subtraction, at the input, is converted to a multiplcation or division at the output. (apologies if this isn't what you meant, Austin) > as fancy analogue amplification seems to be viewed as creating more problems > than it solves, and such things are better (and cheaper) done to the digitised > signal. I think the difficulty is in predicting or calculating the exact value of any offset. Since it'll vary with individual CCD, and with temperature. Regards, Pete.
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 now
On Wed, 10 Jan 2001 12:54:31 -0500 Austin Franklin ([EMAIL PROTECTED]) wrote: > Devices are not really linear. There are a number of 'distortions'. One is > offset, the second is linearity, and the third is gain. CCD's are AIUI inherently very linear. 'Offset' = CCD noise in this context, gain = 1.0 as fancy analogue amplification seems to be viewed as creating more problems than it solves, and such things are better (and cheaper) done to the digitised signal. Regards Tony Sleep http://www.halftone.co.uk - Online portfolio & exhibit; + film scanner info & comparisons
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 nowon B+H web
On Wed, 10 Jan 2001 23:16:57 + photoscientia ([EMAIL PROTECTED]) wrote: > Oh no! > Not this again. > The answer is one word - linearity. My reaction entirely :-) Regards Tony Sleep http://www.halftone.co.uk - Online portfolio & exhibit; + film scanner info & comparisons
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 now
On 10 Jan 2001 09:04:51 -0800 Frank Paris ([EMAIL PROTECTED]) wrote: > I'm still not convinced that there's a > necessary mapping between actual density and ADC resolution. It's not 'necessary' inasmuch as it /could/ be done differently, but AFAIK the only CCD prosumer unit to do non-linear mapping was the Olympus ES10. It usually isn't because of cost, complexity, and the extra noise imposed by analogue processing - though the technique is common in PMT scanners. However it is the only way to escape the hard limit of DMax (=noise voltage):DMin (max volts), a voltage ratio which must be mapped to available bits. Regards Tony Sleep http://www.halftone.co.uk - Online portfolio & exhibit; + film scanner info & comparisons
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
Julian writes ... > At 02:31 11/01/01, shAf wrote: > > What you say is true, but you haven't taken into > account the CCD's > >response to exposure ... that is, it can't be changed. > This means if > >you overexpose, then you either need a very high value to represent > >the thin area of the film, or you lose the detail in that > area (washes > >out). For 10bits, this pixel value would have to be contrained to > >1023 ... for 12bits, these values can be put between 1024 and 4096, > >therefore extending the range of the CCD's exposure and > increasing its > >dynamic range (... or reducing the possibility of no detail in the > >shadows or highlights ...). > > > >shAf :o) > > I understand what you are saying but don't think it contradicts my > thoughts... you might try wading through my other post and > tell me if we agree. In the context of mapping density/exposure data with a scanner CCD, what I said would contradict what you said earlier ... "I am having a fundamental problem comprehending why the number of bits is even vaguely related to any supposed density range." shAf :o)
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
At 02:31 11/01/01, shAf wrote: > What you say is true, but you haven't taken into account the CCD's >response to exposure ... that is, it can't be changed. This means if >you overexpose, then you either need a very high value to represent >the thin area of the film, or you lose the detail in that area (washes >out). For 10bits, this pixel value would have to be contrained to >1023 ... for 12bits, these values can be put between 1024 and 4096, >therefore extending the range of the CCD's exposure and increasing its >dynamic range (... or reducing the possibility of no detail in the >shadows or highlights ...). > >shAf :o) I understand what you are saying but don't think it contradicts my thoughts... you might try wading through my other post and tell me if we agree. Julian R Julian Robinson in usually sunny, smog free Canberra, Australia
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 nowon B+H web site ...)
Hi Julian. Julian Robinson wrote: > Can someone help me here with some basic facts regarding this > dynamic/density range business? > ...snip... > What is to stop me representing this by 4 bits or instead by 40 > bits? The only thing that changes is the resolution. Oh no! Not this again. The answer is one word - linearity. You can expand a smaller ratio into a larger one, but not vice versa. Quarts into pint pots just don't go. Regards, Pete.
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
Hi Erik. Erik Kaffehr wrote: > ...Practical measurements on existing scanners seem to indicate that the > real > dynamic range (including CCD, elektronics, external light internal > refkections seem in the order of 2.5, that is 8-9 aperture stops. Acer claim a 3.2 D range for the Scanwit 2720, and I've verified that this is actually acheived in practise. I used neutral density filter gels in 0.3D steps down to 3.9D, and the variation in returned RGB level bottomed out at 3.3D. The Dmin seen by the scanner is about 0.15D (about average for the base+fog of a real transparency), giving a density range of 3.3-0.15 = 3.15D. I did the same test with the 2740, which has a 14 bit A/D, and got virtually identical results. ie. nearly no discrimination of density change below 3.3D Acer, quite rightly, are still only claiming a 3.2D range for the 2740, and not even making a big deal of the 14 bit A/D fitted. This leads me to the conclusion that the limiting factor determining true dynamic range is the CCD sensor, and not the A/D converter chip. (Acer's R&D confirmed this, when I queried the lack of dynamic range improvement in the 2740) There is a consideration of Infrared fog, or breakthrough, and the reduction of real contrast by the optical system, (the system OTF), but this is a different issue, and doesn't change the fact that a real density range of around 3.2D can be captured at the film plane. It's easily possible to increase the density (Dmax) seen by a scanner by simply increasing the exposure time or the light source intensity, but this leads to saturation and possible 'blooming' of the CCD at the top end. The (real) dynamic range is what is important, not a spurious Dmax figure as quoted by some manufacturers. However, if scanner makers really wanted to confuse the issue, they could state their dynamic range figures in dB, as per the CCD data sheets. (using power dB, a bit naughty!) Regards, Pete.
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now
Hi! The psychological issue is not really relevant, as we already have an image, having a certain intensity. If we want to show it on the computer screen we have to take into account that the phosphors of the screen are not linear. Their intensity is not proportional to the voltage. This is handled as far as I understand by the gamma correction. This make the colors look like on the screen, but also makes for a better utilisation of the available bits. For this reason it's good to have many bits in the raw scan (which has a gamma of 1), this can than be read into a image processing program where gamma and other corrections are made and the results be converted to a well utilized and visually correct density range, represented normally by 8 bits. You can try this if your scanner software can produce a raw scan. The raw scan will be very dark. If you set black and white points reasonably and change gamma (the center figure in the levels dialogue) to 1.8 (Mac) or 2.2 (PC) you should get pretty close to a normal scan done with the TWAIN module from Photoshop. Some of this conversion can be made in scanner hardware, or in the TWAIN module, or in PhotoShop. Regards Erik Kaffehr On Wednesday 10 January 2001 18:04, you wrote: > > Because at the ADC, optical brightness ratios (as analogue > > voltages) are mapped to > > bits in a linear fashion. > > But that mapping might not be correct, if the sensor is insensitive to low > levels of light. That's what I got out of Julian's post. So you map what > the sensor delivers in voltage to brightness and you still might not get > all the details in shadows that are in the original slide. Instead the rest > of the image is spread out unrealistically. I'm still not convinced that > there's a necessary mapping between actual density and ADC resolution. > Also, the eye doesn't work linearly to brightness. Where along the path > from sensor to scanned image is the mapping performed that actually > corresponds to the psychological way we perceive brightness levels? > > Frank Paris > [EMAIL PROTECTED] > http://albums.photopoint.com/j/AlbumList?u=62684 > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Sleep > > Sent: Wednesday, January 10, 2001 5:36 AM > > To: [EMAIL PROTECTED] > > Subject: Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now > > > > > > On Wed, 10 Jan 2001 19:41:35 +1100 Julian Robinson > > ([EMAIL PROTECTED]) > > > > wrote: > > > I am having a fundamental problem comprehending why the number > > > > of bits is > > > > > even vaguely related to any supposed density range. I > > > > understand the maths > > > > > quoted here and in many other posts, but fail to understand why > > > > the fact > > > > > that the ratio of smallest bit size to largest number > > > > represented should be > > > > > related to density range. > > > > Because at the ADC, optical brightness ratios (as analogue > > voltages) are mapped to > > bits in a linear fashion. > > > > There was a long and involved discussion about this a while back. > > You should be > > able to locate the thread at the archive at > > http://phi.res.cse.dmu.ac.uk/Filmscan/ > > - I think it was entitled 'Bit depth vs. OD'. > > > > Regards > > > > Tony Sleep > > http://www.halftone.co.uk - Online portfolio & exhibit; + film > > scanner info & > > comparisons -- Erik Kaffehr[EMAIL PROTECTED] alt. [EMAIL PROTECTED] Mariebergsvägen 53 +46 155 219338 (home) S-611 66 Nyköping +46 155 263515 (office) Sweden -- Message sent using 100% recycled electrons --
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now
On Wed, 10 Jan 2001 19:41:35 +1100 Julian Robinson ([EMAIL PROTECTED]) wrote: > I am having a fundamental problem comprehending why the number of bits is > even vaguely related to any supposed density range. I understand the maths > quoted here and in many other posts, but fail to understand why the fact > that the ratio of smallest bit size to largest number represented should be > related to density range. Because at the ADC, optical brightness ratios (as analogue voltages) are mapped to bits in a linear fashion. There was a long and involved discussion about this a while back. You should be able to locate the thread at the archive at http://phi.res.cse.dmu.ac.uk/Filmscan/ - I think it was entitled 'Bit depth vs. OD'. Regards Tony Sleep http://www.halftone.co.uk - Online portfolio & exhibit; + film scanner info & comparisons
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 now
> Because at the ADC, optical brightness ratios (as analogue > voltages) are mapped to > bits in a linear fashion. But that mapping might not be correct, if the sensor is insensitive to low levels of light. That's what I got out of Julian's post. So you map what the sensor delivers in voltage to brightness and you still might not get all the details in shadows that are in the original slide. Instead the rest of the image is spread out unrealistically. I'm still not convinced that there's a necessary mapping between actual density and ADC resolution. Also, the eye doesn't work linearly to brightness. Where along the path from sensor to scanned image is the mapping performed that actually corresponds to the psychological way we perceive brightness levels? Frank Paris [EMAIL PROTECTED] http://albums.photopoint.com/j/AlbumList?u=62684 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Sleep > Sent: Wednesday, January 10, 2001 5:36 AM > To: [EMAIL PROTECTED] > Subject: Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now > > > On Wed, 10 Jan 2001 19:41:35 +1100 Julian Robinson > ([EMAIL PROTECTED]) > wrote: > > > I am having a fundamental problem comprehending why the number > of bits is > > even vaguely related to any supposed density range. I > understand the maths > > quoted here and in many other posts, but fail to understand why > the fact > > that the ratio of smallest bit size to largest number > represented should be > > related to density range. > > Because at the ADC, optical brightness ratios (as analogue > voltages) are mapped to > bits in a linear fashion. > > There was a long and involved discussion about this a while back. > You should be > able to locate the thread at the archive at > http://phi.res.cse.dmu.ac.uk/Filmscan/ > - I think it was entitled 'Bit depth vs. OD'. > > Regards > > Tony Sleep > http://www.halftone.co.uk - Online portfolio & exhibit; + film > scanner info & > comparisons
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
Julian writes ... > Can someone help me here with some basic facts regarding this > dynamic/density range business? > > I am having a fundamental problem comprehending why the > number of bits is even vaguely related to any > supposed density range. ... > > For example, I could have a density range of 1000:1 - ie > 3.0 on the log scale. What is to stop me > representing this by 4 bits or instead by 40 > bits? The only thing that changes is the resolution. > ... What you say is true, but you haven't taken into account the CCD's response to exposure ... that is, it can't be changed. This means if you overexpose, then you either need a very high value to represent the thin area of the film, or you lose the detail in that area (washes out). For 10bits, this pixel value would have to be contrained to 1023 ... for 12bits, these values can be put between 1024 and 4096, therefore extending the range of the CCD's exposure and increasing its dynamic range (... or reducing the possibility of no detail in the shadows or highlights ...). shAf :o)
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
No I did mean 10^12 being the approximate result of my postulated 40 bits i.e. 2^40 = 1.0995x10^12 ~= 10^12 I should have said... The difference of course is the resolution... In the former case, there are only 2^4 = 16 levels between darkest and lightest density. In the latter case, there are 2^40 or about 10^12 i.e. 1,000,000,000,000 levels. BTW if this is in HTML can someone tell me - on another list I had posted HTML even though I think I do not - now I look at my posts they have some indication that they could be in HTML although I cannot tell because it may be the way Eudora interprets things. Thanks, Julian At 20:27 10/01/01, you wrote: >Julian, > slight typing error... > > You said...2^4 gives 16 >levels. > and should have said...2^12 gives 4096 levels. > and NOT 10^12 gives > >Chris. > Julian Robinson in usually sunny, smog free Canberra, Australia
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
Julian, slight typing error... You said...2^4 gives 16 levels. and should have said...2^12 gives 4096 levels. and NOT 10^12 gives Chris. - Original Message - From: "Julian Robinson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 10, 2001 8:41 AM Subject: Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...) > Can someone help me here with some basic facts regarding this > dynamic/density range business? > > I am having a fundamental problem comprehending why the number of bits is > even vaguely related to any supposed density range. I understand the maths > quoted here and in many other posts, but fail to understand why the fact > that the ratio of smallest bit size to largest number represented should be > related to density range. > > For example, I could have a density range of 1000:1 - ie 3.0 on the log > scale. What is to stop me representing this by 4 bits or instead by 40 > bits? The only thing that changes is the resolution. > > In the former case, log10 (2 to the power 4) = 1.2 = "so-called calculated > density range" > In the latter case, log10(2 to the power 40) = 12.0 = "so-called calculated > density range", > > but in both cases the actual density range represented is still 3.0. > > The difference of course is the resolution... > In the former case, there are only 16 levels between darkest and lightest > density. > In the latter case, there are about 10^12 i.e. 1,000,000,000,000 levels. > > I cannot shake off the belief that the number of bits affects nothing > except the resolution with which the densities are recorded, and has > nothing whatsoever to do he usable density range. > > I thought that the density range is the ratio of: > > [the brightest accurately measured value through clear (fully exposed) > slide film or orange mask (unexposed) neg film] vs > [the darkest accurately measured value] > > which has nothing to do with the number of bits in the D/A. > > The brightest value will be determined by the level that can be read by the > CCD with reasonable (predictable) linearity. > The darkest value will be determined by noise performance of the CCD. > > What am I doing wrong? > > Julian > > At 17:44 10/01/01, you wrote: > >Hi! > > > >A 14 bit number means a range 2 raised to the power of fourteen, that is > >16384. > > > >Density units are log 10 so we get log (16384) -> 4.21 > > > >A simpler way: > > > >1 bit means essentially one one aperture stop which is 0.3 Density units (log > >2). > > > >14 * 0.3 -> 4.2 > > > >Or you could also say that the range is 14 aperture stops. > > > >This is more than the density range of any film... > > > >Practical measurements on existing scanners seem to indicate that the real > >dynamic range (including CCD, elektronics, external light internal > >refkections seem in the order of 2.5, that is 8-9 aperture stops. > > > >Regards > > > >Erik > > > > > > > > > >On Tuesday 09 January 2001 19:05, you wrote: > > > > In summary, dynamic range is just another way of saying how > > > > many bits the A/D converter uses: > > > > > > > > 10 bits = 3.0 > > > > 12 bits = 3.6 > > > > 14 bits = 4.2 > > > > > > Would you please explain this more? What is the source of the information, > > > or the algorithm, you used to come up with these numbers? > > > >-- > >Erik Kaffehr[EMAIL PROTECTED] alt. [EMAIL PROTECTED] > >Mariebergsvägen 53 +46 155 219338 (home) > >S-611 66 Nyköping +46 155 263515 (office) > >Sweden -- Message sent using 100% recycled electrons -- > > > Julian Robinson > in usually sunny, smog free Canberra, Australia >
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
Can someone help me here with some basic facts regarding this dynamic/density range business? I am having a fundamental problem comprehending why the number of bits is even vaguely related to any supposed density range. I understand the maths quoted here and in many other posts, but fail to understand why the fact that the ratio of smallest bit size to largest number represented should be related to density range. For example, I could have a density range of 1000:1 - ie 3.0 on the log scale. What is to stop me representing this by 4 bits or instead by 40 bits? The only thing that changes is the resolution. In the former case, log10 (2 to the power 4) = 1.2 = "so-called calculated density range" In the latter case, log10(2 to the power 40) = 12.0 = "so-called calculated density range", but in both cases the actual density range represented is still 3.0. The difference of course is the resolution... In the former case, there are only 16 levels between darkest and lightest density. In the latter case, there are about 10^12 i.e. 1,000,000,000,000 levels. I cannot shake off the belief that the number of bits affects nothing except the resolution with which the densities are recorded, and has nothing whatsoever to do he usable density range. I thought that the density range is the ratio of: [the brightest accurately measured value through clear (fully exposed) slide film or orange mask (unexposed) neg film] vs [the darkest accurately measured value] which has nothing to do with the number of bits in the D/A. The brightest value will be determined by the level that can be read by the CCD with reasonable (predictable) linearity. The darkest value will be determined by noise performance of the CCD. What am I doing wrong? Julian At 17:44 10/01/01, you wrote: >Hi! > >A 14 bit number means a range 2 raised to the power of fourteen, that is >16384. > >Density units are log 10 so we get log (16384) -> 4.21 > >A simpler way: > >1 bit means essentially one one aperture stop which is 0.3 Density units (log >2). > >14 * 0.3 -> 4.2 > >Or you could also say that the range is 14 aperture stops. > >This is more than the density range of any film... > >Practical measurements on existing scanners seem to indicate that the real >dynamic range (including CCD, elektronics, external light internal >refkections seem in the order of 2.5, that is 8-9 aperture stops. > >Regards > >Erik > > > > >On Tuesday 09 January 2001 19:05, you wrote: > > > In summary, dynamic range is just another way of saying how > > > many bits the A/D converter uses: > > > > > > 10 bits = 3.0 > > > 12 bits = 3.6 > > > 14 bits = 4.2 > > > > Would you please explain this more? What is the source of the information, > > or the algorithm, you used to come up with these numbers? > >-- >Erik Kaffehr[EMAIL PROTECTED] alt. [EMAIL PROTECTED] >Mariebergsvägen 53 +46 155 219338 (home) >S-611 66 Nyköping +46 155 263515 (office) >Sweden -- Message sent using 100% recycled electrons -- Julian Robinson in usually sunny, smog free Canberra, Australia
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
Hi! A 14 bit number means a range 2 raised to the power of fourteen, that is 16384. Density units are log 10 so we get log (16384) -> 4.21 A simpler way: 1 bit means essentially one one aperture stop which is 0.3 Density units (log 2). 14 * 0.3 -> 4.2 Or you could also say that the range is 14 aperture stops. This is more than the density range of any film... Practical measurements on existing scanners seem to indicate that the real dynamic range (including CCD, elektronics, external light internal refkections seem in the order of 2.5, that is 8-9 aperture stops. Regards Erik On Tuesday 09 January 2001 19:05, you wrote: > > In summary, dynamic range is just another way of saying how > > many bits the A/D converter uses: > > > > 10 bits = 3.0 > > 12 bits = 3.6 > > 14 bits = 4.2 > > Would you please explain this more? What is the source of the information, > or the algorithm, you used to come up with these numbers? -- Erik Kaffehr[EMAIL PROTECTED] alt. [EMAIL PROTECTED] Mariebergsvägen 53 +46 155 219338 (home) S-611 66 Nyköping +46 155 263515 (office) Sweden -- Message sent using 100% recycled electrons --
Re: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
So what you are saying is that the dynamic range is the number of bits in the Analogue Digital Converter, and has very little to do with the dynamic range of the CCD? Wouldn't it be nice with a signal to noice ration instead, like -50 dB? Regards Erik On Tuesday 09 January 2001 11:02, you wrote: > In a message dated 1/8/2001 11:55:37 PM EST, [EMAIL PROTECTED] writes: > > The 3.9 dynamic range sounds unbelievable. I wonder how they achieve > > that? > > 3.9 just means 13 bits of dynamic range. They're using a 14-bit A/D > converter, which most vendors convert to a dynamic range of 4.2. > I suspect Polaroid is just being conservative. > > Note that the Nikon 4000 ED and 8000 ED (I love these names ) > have a 14-bit A/D converter, and Nikon says the dynamic range is 4.2. > The CoolScan IV ED has a 12-bit A/D converter, and Nikon says the > dynamic range is 3.6 (log10(2^12) = 3.6). > > In summary, dynamic range is just another way of saying how > many bits the A/D converter uses: > > 10 bits = 3.0 > 12 bits = 3.6 > 14 bits = 4.2 > > Regards, > Ed Hamrick -- Erik Kaffehr[EMAIL PROTECTED] alt. [EMAIL PROTECTED] Mariebergsvägen 53 +46 155 219338 (home) S-611 66 Nyköping +46 155 263515 (office) Sweden -- Message sent using 100% recycled electrons --
RE: So it's the bits? (Was: filmscanners: Sprintscan 120 now on B+H web site ...)
> In summary, dynamic range is just another way of saying how > many bits the A/D converter uses: > > 10 bits = 3.0 > 12 bits = 3.6 > 14 bits = 4.2 Would you please explain this more? What is the source of the information, or the algorithm, you used to come up with these numbers?
