«

In article <OG_Mp.25793$_>, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

> >>> Virtually *all* modern "sensors" capture far in excess
> >>> of 48 bits per pixel.
> >>
> >> No, none of them are doing that. As I've said, that's an accuracy of one part
> >> in about 280 trillion, and there is no ADC anywhere that can come close to
> >> that kind of resolution. So most of the bits are wasted, since they are
> >> essentially random.
> >
> > high end sensors have 16 bit a/d converters, for each of red, green and
> > blue, for a total of 48 bits per pixel.
>
> Unless they are actively cooled they are capturing 3 bits of thermal
> random noise in the least significant bits. And all that does is
> increase file sizes by about 20% without any benefit to the user.

roger clark has measured the noise to be much less than 3 bits worth,
typically a couple of electrons in the better cameras. for instance,
the canon 1d mark iv is 1.7 electrons and the 5d mark ii is 2.5. see
table 2:

<http://www.clarkvision.com/imagedeta...formance.summa
ry/>

> > most cameras have 12 or 14 bit a/d converters, so it's 36 or 42 bits
> > total.
>
> Every pixel measures just one colour channel. You have around 13 bits of
> independent data for each pixel on the sensor. When it is processed then
> you end up with a conventional RGB16 image that needs to be stored in 3x
> 16bit integers to accommodate the full linear dynamic range.

from the above link, he also shows that a 14 bit a/d converter is
limiting factor with the sensor those cameras. the canon 1d mark iv is
15 stops. see figure 4 (and table 2):

<http://www.clarkvision.com/imagedeta...formance.summa
ry/dynamic_range_a.gif>

> The total evidence you have for this image is still the original dataset
> of NxM 13bit values and it can be compressed on that basis.
>
> Foveon sensors really do measure all three colours at every pixel

not exactly. foveon layers are *not* measuring red green and blue. the
sensor takes three samples that overlap quite a bit and then the raw
converter tries to guess at the actual rgb components. it mostly works
but not always, and it can be anywhere from a little wrong to hideously
wrong, like with this one:

<http://forums.dpreview.com/galleries/286305481/photos/647382/SDIM0196>

> but they have significant other failings

that they do, and in addition to those, the new sd1 has a ridiculous
price as yet another significant failing.

> so unless you really spend your
> time photographing test charts in complementary colours their notional
> advantage over Bayer sampled images is largely illusory.

it's entirely illusory.

> You never get something for nothing. What you measured is all you have.

true, which is why some of the claims for foveon are crazy, if not
outright fraud.

On Jun 23, 11:08*pm, fl...@apaflo.com (Floyd L. Davidson) wrote:
> Whisky-dave <whisky.d...@gmail.com> wrote:
> >On Jun 23, 3:25 pm, fl...@apaflo.com (Floyd L. Davidson) wrote:


>
> >> And there is *always* something "storing that voltage".
>
> >Such as what...... and how is it relevant .
>
> Reactance... *(an electromagnetic field).

That does not store voltage, you do know that if we found something
that simple that could store voltage as you say we wouldn't need
batteries would we.


> >If a sensor captures the light from a scene and measures the
> >amount of light on it, you're saying it's wrong because that value
> >gets stored
> >so it can't update, because it has to go through all the voltages.
>
> Nobody said anything like that.

You've implied that, you've said that the voltage has to go through
all values.


> What has been said is that there is a finite speed at which it can
> be updated. *Remember... slew rate, rise time, etc.?

Which depend on the devices themselves and each are different.

>
> >> It *necessarily* goes through every voltage, absolutely every time.
> >> It is *impossible* to do otherwise.
>
> >So you can't actually take a valid reading of the voltage then can
> >you.
> >Is that what you're saying.
>
> You can't take readings too quickly.

What do you mean by that, are yuo saying that measuring instruments
don;t have a settle time or is it that they don't take into account
rise times or fall times ?
You';ve claimed that when you switch something off (from say 5V)
it has to go through all the voltages before it is off or 0V
So how will you know when it is at 0V if you don't measure it.



> >You have 5V switched to 0V or 0 to 5 up to you.
> >shown the calculation for rise time.
>
> There have been several webpages cited that show the
> formulas for rise time calculations.

Yes and each are because of other components
I've run labs here that check the operational; delays of relays
it's not a rise time.
Semiconductors can have rise times switches don;t they have mechanical
delays
of switching, these delays are caused by springs, latches and other
mechanical things
this is NOT rise time.

> >> >When you put a battery in your camera the voltage doesn't increase
> >> >when you put the battery in or when you switch on.
> >> >otherwise it'd be better than perpetual motion.
>
> >> Nonsense. The reactance of the leads within the camera can
> >> often lead to spikes that are significantly higher than the
> >> battery voltage.
>
> >Where do you get that idea from.
> >The physical properties are what make batteries the voltages they are.
>
> Batteries are in fact pretty good filters and do remove
> a great deal of the higher frequency noise from any
> conductor to which they are connected;

yes, but they don't create these frequencies which was your claim.
Batteries are DC not AC.



> however, since
> circuit board traces are virtually always very thin and
> narrow the *fact* is that at any distance from the
> battery that filtering effect is non-existant.

So why claim it happens then.

> Switching transients from digital chips result in huge
> noise spikes that can be significantly higher in voltage
> than the battery supply.

Yes but they are NOT from the battery as you claimed.


>
> This is all very fundamental to the design of digital
> equipment of any kind.
>
> >> >That is not the use of a switch, what high frequencies 'components'
> >> >do you get when you insert a battery into say a torch.
> >> >Where do these high frequencies come from the bulb !
>
> >> From the switching transients due to circuit reactance.
> >> Here, I've already explained it:
>
> >There's no circuit it's a switch.
>
> A switch has leads.

So do dogs.
What's your point ?


>
> >of course if you add a capacitor or any other component then that
> >changes thins because it depends
> >on the component.
>
> The leads form capacitors.

So.


>
> >> >So now you've dropped this down to speed,
>
> >> That is exactly what "rise time" is. Slew rate... remember?
>
> >They are not the same.
>
> They are the same.

Idiot
http://en.wikipedia.org/wiki/Rise_time
rise time is defined as "the time required for the response to rise
from x% to y% of its final value",

http://en.wikipedia.org/wiki/Slew_rate
The output slew-rate of an amplifier or other electronic circuit is
defined as the maximum rate of change of the output voltage for all
possible input signals.

Just because black and white look the same to a blind man it doesn't
make them the same.



>
> Makes no difference. *Just try switching your 5 volts on an off at
> a 100 GHz rate.

Is 100GHz rate the same as a 100GHz signal ?

>
> >What is 100GHz rate are you sure rate isn't your word for frequency.
>
> "Frequency" is a rate.

No frequency is 1/periodic time .
Rate can be the number of times you through up in an evening.
It can be how much rain falls in a day.

>
> >And will you measure this frequency, if the voltage goes through every
> >level
> >you won;t be able to tell the start from end point.
>
> Oh, yes you will! *Think about how many wavelengths
> long, at 100GHz, your paper clip is; and then ask
> yourself how much voltage will ever show up at the end
> of the paper clip! *Because the amount of reactance in
> even a paper clip happens to have a huge effect at 100
> GHz, the rise time will be long enough that the voltage
> at the end of the clip can never get anywhere close to 5
> volts. (Your paper clip will have a very low slew rate,
> compared to 100 GHz, for transmission from one end to
> the other.)

So how can you measure such things using cables
how can anything run at these speeds if the voltage
can get from the one device to another ?
http://www.tomshardware.co.uk/ibm-tr...ews-32738.html


> >> >> When you switch the voltage... bingo, you've got AC.
>
> >> >NO AC goes between + 0 and - Plus zero/gnd and negative.
> >> >Also in case you've missed it AC is alternating current.
> >> >Going from 0 to + and from + to 0 is NOT AC, that is DC
>
> >> Sure, plus or minus... *compared to what?*
>
> >Compared to your reference point which is normally 0V or GND.
>
> >> You don't seem to
> >> realize that switching between 5 volts and 0 volts is a 2.5 volt
>
> >No ) to 5 is a potential difference of 5V.
>
> And it is an AC signal by definition, when it is switched.

No it is not.
Are you saying your car runs from an AC battery because you switch it
on and off ?
The term alternating current is from the fact that the current flows
in one direction and then the other.
if you go from 0V to 2.5V and then to 5V and then back to 2.5 and then
to 0v the current flows in
exactly the same direction, only if you go into negative Voltages does
the current change direction.
Or of course reverse the battery connections has the same effect.
This is basic school stuff, you might have learnt that current goes
fro +ve to _ve
but what actually happens is the current flows via electrons from -ve
to +ve


>
> >> It's also
> >> loaded with harmonics.
>
> > A pure sine wave does not contain harmonics.
>
> When you switch 5 volts on and off it is *not* a sine wave.

So what is it then I know it's not a sine wave.


>
> >> in that sense. If nothing else it will have 50/60Hz induction from
> >> nearby power lines.
>
> >Batteries don't.
>
> Yes they do. As I've suggested, look at one with a spectrum analyzer.

And if I did how would that prove anything to you.
I have spectrum analysers here in my lab.

You don;t have a clue do you.
You can;t tell AC for DC can you.





> >> >>That is why there are always
> >> >> many many little bypass capacitors... to aborb them.
>
> >> >That';s because of other elements in the circuit.
>
> >> That's an hilarious statement. You are clueless.
>
> >You haven't a clue have you.
> >De-coupling as it's called is needed due to either excessive demands
> >on power or
> >electromagnetic interference from other sources.
>
> So you agree with exactly what I just said.

NO You said
"That is why there are always many many little bypass capacitors."

That is untrue.
They aren't even called bypass capacitors anymore.
http://en.wikipedia.org/wiki/Bypass_capacitor



> >> >> >Are you getting slew rates confused with propagation delay.
>
> >> >> Interesting you bring that up. In fact it is related to propagation
> >> >> delay. Actually to something known as "group delay". Or "phase delay".
> >> >> Some frequencies have a different propagation delay than others,
>
> >> >it's not the frequencies that dictate that though.
> >> >it's the amount of components that the signal passes through.
>
> >> It's the frequencies.
>
> >No, propagation delay is that delay that a signal has from the input
> >of the device to the output frequency is irrelevant.
>
> Look up the term "group delay". *Here's the FS-1037C standard definition:


why not look up group rolling stone


>
> In other words, propagation delay is different for different frequencies,
> and that causes a phase shift. * Essentially it is a distortion (commonly
> called "noise").

NO it is NOT.

>
> Nonsense. *The world is full of low pass filters... *and high pass
> filters too.

yes so.

>
> >Is 0.5V us better than 13V us *? *(us= microseconds)
>
> Do you ever *think* before you say these things?

Yes, which means you're not capable of answering such a simple
question.

On 24/06/2011 13:20, nospam wrote:
> In article<OG_Mp.25793$_>, Martin Brown
> <|||newspam|||@nezumi.demon.co.uk> wrote:
>
>>>>> Virtually *all* modern "sensors" capture far in excess
>>>>> of 48 bits per pixel.
>>>>
>>>> No, none of them are doing that. As I've said, that's an accuracy of one part
>>>> in about 280 trillion, and there is no ADC anywhere that can come close to
>>>> that kind of resolution. So most of the bits are wasted, since they are
>>>> essentially random.
>>>
>>> high end sensors have 16 bit a/d converters, for each of red, green and
>>> blue, for a total of 48 bits per pixel.
>>
>> Unless they are actively cooled they are capturing 3 bits of thermal
>> random noise in the least significant bits. And all that does is
>> increase file sizes by about 20% without any benefit to the user.
>
> roger clark has measured the noise to be much less than 3 bits worth,
> typically a couple of electrons in the better cameras. for instance,
> the canon 1d mark iv is 1.7 electrons and the 5d mark ii is 2.5. see
> table 2:
>
> <http://www.clarkvision.com/imagedeta...formance.summa
> ry/>

Unfortunately you are taking that graph *entirely* out of context. At
the point where the read noise equivalent is 1.7 electrons the camera is
operating at ISO 12800 with a usable dynamic range of just 8 stops and a
very short exposure time so much less thermal noise accumulates.

At a more realistic ISO 200 the readout noise including the thermal
component is around 10e which is pretty much as I would expect.

http://www.clarkvision.com/articles/...div/index.html

See Table 1 for what he actually measured and choose your ISO.

The true dynamic range of any single exposure at 11bits on this camera
would actually appear to be worse than I guesstimated according to his
data as the full well maximum is half what I had allowed.

Note his conclusions at the end that the device as employed in that
camera is limited to just over 11 bits of usable dynamic range.

It is a pity he doesn't show the dark frame stretched image for the
sensor at a nominal 1s exposure - that is usually very illuminating
about the limitations of the sensor - warm corners and stray IR photons.
>
>>> most cameras have 12 or 14 bit a/d converters, so it's 36 or 42 bits
>>> total.
>>
>> Every pixel measures just one colour channel. You have around 13 bits of
>> independent data for each pixel on the sensor. When it is processed then
>> you end up with a conventional RGB16 image that needs to be stored in 3x
>> 16bit integers to accommodate the full linear dynamic range.
>
> from the above link, he also shows that a 14 bit a/d converter is
> limiting factor with the sensor those cameras. the canon 1d mark iv is
> 15 stops. see figure 4 (and table 2):
>
> <http://www.clarkvision.com/imagedeta...formance.summa
> ry/dynamic_range_a.gif>

No it doesn't. You are not comparing like with like.

The fact that the systematic readout noise is low at high ISO does
nothing at all to prevent the buildup of thermal noise when you do a
normal ISO longer exposure.
>
>> The total evidence you have for this image is still the original dataset
>> of NxM 13bit values and it can be compressed on that basis.

In practice the real Canon 1D mark IV manages a shade over 11 bits
dynamic range. It is possible that a few cameras do slightly better.

You need a cooled CCD to get the thermal noise right down, or a *very*
powerful flash to make the exposure time extremely short.

Regards,
Martin Brown

On 23/06/2011 22:29, Floyd L. Davidson wrote:
> Martin Brown<|||newspam|||@nezumi.demon.co.uk> wrote:
>> On 23/06/2011 11:21, Floyd L. Davidson wrote:
>>> Martin Brown<|||newspam|||@nezumi.demon.co.uk> wrote:
>>>> On 23/06/2011 09:11, Floyd L. Davidson wrote:
>>>>> Mxsmanic<> wrote:
>>>>>> nospam writes:
>>>>>>
>>>>>>> not when the sensor is capable of capturing it.
>>>>>>
>>>>>> No sensor is capturing 48 bits of data.
>>>>>
>>>>> Virtually *all* modern "sensors" capture far in excess
>>>>> of 48 bits per pixel.
>>
>> You are double counting here. There is only one pixels worth of real
>> data sampled for each sensor site - everything else is interpolated.
>>>>
>>>> This is a clueless gibberish interpretation of bits per pixel.
>>>
>>> I've spent several *decades* working with digital image
>>> data, and have an extremely good understanding of
>>> exactly how it works.
>>
>> And then you go on to prove conclusively that you do not understand it.
>
> Actually, *you* are spouting the "clueless gibberish"
> and have made it very clear that this is something that
> you are guessing about what happens without actually
> understanding or knowing the details.

You really don't have the first clue. I have implemented Bayer demosaic
programs and wrote one of the first introductions to the simplest form
of Bayer demosaicing way back when the Kodak DC-120 first came onto the
market. Nominally a 1Mpixel camera but only after interpolation.

It is still online:
http://www.nezumi.demon.co.uk/photo/bayer/bayer.htm
>
>>>
>>>> A single photosite on a CCD at room temperature is dynamic range limited
>>>> by readout noise (~10e) at one end and full well overflow at the other
>>>> (~100,000e). The intrinsic dynamic range at the time of measurement is
>>>> typically 1:10000 or 13bits. Put a two stage Peltier cooler on it and
>>>> you can get nearly 16bits out of the better ones.
>>>
>>> You are discussing the dynamic range of luminance values.
>>
>> Which is the limiting factor for determining colour values - all the
>> interpolation ever does is compute a decent guess at the colour value
>
> It *calculates* color values, and very clearly gets the accurate to
> within the range of 48 bits per color. As I've pointed out, the actual
> capture data is significantly greater than that, and is *reduced* to
> only 48 bits per pixel when saved to an image format that can only
> deal with that many bits per pixel.

The evidence that nospam posted from Roger Clarkes site suggests that
for most cameras you would be lucky to have 33bits of real data content
in a full colour pixel - at most 11 bits dynamic range at ISO 200.

>> for each of the missing colours at every site. The colour image result
>> is then 3 x 13 bits of significant data and usually worse than that. The
>> blue channel is usually somewhat noiser than the others.
>
> There isn't a single RAW converter in common use that converts to
> "3 x 13 bits of significant data". Not one. Every one of them
> converts to at least 3 x 32 bits.

Only if the programmer doesn't understand how to scale into 16bits.

>>> The obvious fact that that is true is clear when you
>>> simply consider that when a RAW file (with color
>>> information encoded in the Bayer filter pattern) is
>>> converted to an RGB encoding the size of the data file
>>> is increased by generally 5 or 6 *times* the size of the
>>> RAW sensor data file.
>>
>> But that is empty data.
>
> That is an idiotic statement. If it were "empty data", don't you
> think every software developer in the world would have found ways
> not to waste "empty" space?

No. You don't have to look further than all the bloatware to see this.

If you want to display it you have to have an RGB buffer with values for
all pixels.

> What you are missing is that the Bayer pattern *encodes color data*.
> As long as the data is kept in that form, the size of the data set
> is very significantly smaller. Once the color information is encoded
> into the digital data... the size of the data set becomes huge.
>
> That is very clearly *not* "empty" data!

Yes it is. The original sensor array is a more compact form and is a
rough measure of the total amount of information in the final image.
Interpolating it onto the classic RGB16 format makes it easier to
display but does not add any new information to the result.
>
>>>> And when you combine them you get another 14 bit number stored in a
>>>> 16bit register. There is no free lunch here.
>>>
>>> That is absolutely *not* true. When they are combined it is
>>> an integer the size of the machine's native integer. That is
>>> generally either a 32 or 64 bit integer.
>>
>> You really do not have the first clue do you?
>
> *Look* at the code that does it. Then talk about clues.

I have written code that does this stuff!
>
>> Manipulating large images goes memory bandwidth limited whenever you do
>> anything serious. No-one that understands what they are doing *ever*
>> makes the working image buffer larger than is absolutely necessary.
>
> But since they actually do need it, they do use it.
> Look at the source code for a RAW converter.
>
>>>>> Each *pixel* is therefore generated from 9 * 14 bits,
>>>>> or 126 bits *minimum*.
>>>>
>>>> That is a perverse and clueless way of looking at it.
>>>
>>> It is precisely *accurate*.
>>
>> It is clueless and utterly misleading to boot.
>
> So then you go on to say exactly the same thing... and just
> do not realize that is what you've said.

There is a very important difference. You are claiming that the number
of bits of data of each value adds together to give some silly large
number - that is not how the analysis works at all.
>
>> The RGB pixel data is generated from a bunch of 9 13bit numbers but the
>
> There you go. It's actually 14 bit value, and the calculations are
> done with integer arithmetic resulting in integer values at the native
> size for the CPU (32 or 64 bit).
>
> Don't guess, look at some of the available source code.

If it really does that I would prefer not to waste my time looking.
>
>> best that this could ever give in terms of additional signal to noise is
>> at most 1 additional bit. Conservatively you need at most 3 x 14 = 42
>> bits per pixel to store any digicam image in RGB format.
>>
>> Amusing that the answer is 42. Deep thought would be pleased.
>
> Wrong answser though.

Yes. Looks like 33 would be more realistic if the 11 bits actual
measured dynamic range of the Canon 1D Mk IV is reliable.
>
>> The main use for 64 bit data paths is for SIMD instructions to work on
>> smaller chunks of data in parallel. The data is not promoted to 64bit
>> integer values wasting 48 bits for every 16bit word processed.
>
> Never looked at any code for a raw converter, have you...

I have written them.
>
>> 4x 16 bit words or 8x 8 bit bytes are processed simultaneously if a
>> 64bit mode is used.
>
> The point is that a 64 bit integer is not large enough to hold the
> full precision of a 9x14 bit (126 bit) matrix. There is actually
> a loss of information.

You really do not have a clue.
>
>> You really do not have the first clue what you are talking about.
>
> I've looked at code to see how it's done. You might try it yourself...

Understanding mathematics is not your strong point.

Regards,
Martin Brown

In article <z70Np.3585$>, Martin Brown
<|||newspam|||@nezumi.demon.co.uk> wrote:

> In practice the real Canon 1D mark IV manages a shade over 11 bits
> dynamic range. It is possible that a few cameras do slightly better.

dxomark measured the nikon d7000 at 13.9 stops and the pentax k5 at
14.1 stops. that's quite a bit better than 'slightly.'

On Jun 24, 4:18*pm, nospam <nos...@nospam.invalid> wrote:
> In article <z70Np.3585$z67.1...@newsfe10.iad>, Martin Brown
>
> <|||newspam...@nezumi.demon.co.uk> wrote:
> > In practice the real Canon 1D mark IV manages a shade over 11 bits
> > dynamic range. It is possible that a few cameras do slightly better.
>
> dxomark measured the nikon d7000 at 13.9 stops and the pentax k5 at
> 14.1 stops. that's quite a bit better than 'slightly.'

I'm not so sure bits and stops are the same, but it's not something
I'm going to worry about Friday afternoon.

On 6/23/2011 6:02 PM, Savageduck wrote:
> On 2011-06-23 14:39:20 -0700, James Silverton
> <> said:
>
>> On 6/23/2011 2:23 PM, Wolfgang Weisselberg wrote:
>>> Mxsmanic<> wrote:
>>>> Wolfgang Weisselberg writes:
>>>
>>>>> Cheap TN dispays probably cannot. People who use them for colour
>>>>> critical stuff are stupid.
>>>
>>>> Even expensive displays generally cannot, and this is often visually
>>>> obvious
>>>> if you display the right test pattern.
>>>
>>> That very much depends on the displays.
>>> Especially as you use an absolute "expensive" whereas I use a
>>> relative "cheap".
>>>
>>>>> CRTs can (they are analog and thus can display infinite colours),
>>>>> better flatscreen panels can, etc.
>>>
>>>> CRTs can do better (in theory, sometimes in practice), but they are
>>>> limited,
>>>> too.
>>>
>>> Analog systems always beat digital system. --Mxsmanic
>>>
>>>
>>>>> [...] Which is why your "most displays cannot" is a singulary stupid
>>>>> argument.
>>>
>>>>> But he can tell the difference between 00..001111 and 00..0010000,
>>>>> especially when it's digitally boosted.
>>>
>>>> Which is really the difference between 0.01 and 0.00.
>>>
>>> Really? By which broken math do you make 16 and 15 into 0.01 and 0.00?
>>>
>>>> Which is one part in
>>>> four, hardly worth crowing about.
>>>
>>> one part in four is 0.25.
>>>
>>> BTW, the difference between $0.01 and $0.00 per kilobyte transmitted
>>> is a slight bit more than "hardly worth crowing about".
>>>
>> It's maybe not on topic for slr but I wonder what the effect is going
>> to be of the new Lytro focus fixing camera? You won't need autofocus
>> and a wide aperture, uniform but low quality lens might allow taking
>> pictures in dim light.
>
> It seems that Lytro has spent most of today distributing press releases,
> and when it does come along you will be looking at about $10K for a
> working camera.
>
People said similar things about auto-focus but it is provided on
point-and-shoots costing under $100.

--


James Silverton, Potomac

I'm *not*

Mxsmanic <> wrote:
>Floyd L. Davidson writes:

>> Bayer encoding is not contained in those 10-14 bits.
>
>Bayer encoding transforms and reduces information, it does not increase it.

Bayer interpolation (not encoding) does not reduce information. It
transforms it.

>> That information is external to the bit depth. And
>> rather clearly, as I've already pointed out, when the
>> Bayer encoding is re-encoded into another format, such a
>> an RGB imaage, the size of the data set is necessarily
>> hugely increased.
>
>The amount of information gathered by the sensor has an upper limit that no
>Bayer filter can increase.

Gesundheit.

> The filter reduces the amount of information
>gathered (by at least 2/3), it does not increase it.

The dumbass doesn't know the difference between the amount of
information and the information density. A Bayer interpolation
decreases information density but the amount of information
doesn't change significantly.

--
Ray Fischer | Mendocracy (n.) government by lying
| The new GOP ideal

David J. Littleboy <> wrote:
>"Ray Fischer" <> wrote:
>> Mxsmanic <> wrote:

>>> The filter reduces the amount of information
>>>gathered (by at least 2/3), it does not increase it.
>>
>> The dumbass doesn't know the difference between the amount of
>> information and the information density. A Bayer interpolation
>> decreases information density but the amount of information
>> doesn't change significantly.
>
>That's what uncle Claude would say. But a photographer looking at his prints
>would be convinced Dr. Shannon's math is completely wrong.

And what leads you to believe that you speak for the world's
photographers?

>To a photographer, it appears quite convincingly that Bayer increases
>information.

But clearly it does not. There is no information being added. The
information is transformed from non-visual to visual form.

--
Ray Fischer | Mendocracy (n.) government by lying
| The new GOP ideal

Floyd L. Davidson <> wrote:
>"David J. Littleboy" <> wrote:
>>To a photographer, it appears quite convincingly that Bayer increases
>>information. You get a very good n-pixel color image from n measurements.
>
>Exactly. The picture has color. Without the use of
>Bayer encoding there is no information recorded to
>indicate the colors.

Where does the color come from?

Hmmm?

--
Ray Fischer | Mendocracy (n.) government by lying
| The new GOP ideal