Reading mode: Light Dark

Foveon: Line between deception and Marketing?

Go to last post
I am assuming we are using the same algorithm, since I tried these pics with my lame application and achieved identical results.

Each missing colour is simply the average of the nearest neighbors.

For example (using compass descriptions) a "RED" pixel has green neighbors (N+S+E+W) 4. Blue value is (NE+ NW+SE+ SW) 4.

I too was surprised at the lack of artifacts, but too sleepy to spot the problem.

Peter
Max Strandberg said:
Pete Cockerell said:
http://www.peter-cockerell.net:8080/Foveon/
Click to expand...
Thanks for your very informative post and images. This was kind of
what I expected also, as Peter's pictures and conclusions seemed a
bit strange. I thought that the artefacts were exaggerated on
Foveons image and a bit too large compared to the size of the
pixels to have been caused by interference, but naturally it was
just that the pictures had been enlarged from a smaller image and
that is also the main reason why Peter's reverse engineering didn't
produce those horrible artefacts as the pattern was not detailed
enough in the enlarged X3 image to produce the artefacts.

As I don't have photoshop, would you mind explaining what algorithm
you used when making your reverse engineering?
--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
http://hem.bredband.net/maxstr
Click to expand...
 
Peter G said:
For example (using compass descriptions) a "RED" pixel has green
neighbors (N+S+E+W) 4. Blue value is (NE+ NW+SE+ SW) 4.
Click to expand...
OK, that is logical and the same goes for BLUE pixels, since they also have 4 neigbouring pixels of the other colors.

The two values that will be least accurate in a mosaic sensor would be the red and blue values for the green pixels, since they only have 2 neighbours of each of those colors, because the other 4 locations are occupied by green pixels and those doesn't help in calculating the unknown blue and red values. That is why we get blue and red color noise in images captured with a mosaic sensor.-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ http://hem.bredband.net/maxstr
 
Max Strandberg said:
The two values that will be least accurate in a mosaic sensor would
be the red and blue values for the green pixels, since they only
have 2 neighbours of each of those colors, because the other 4
locations are occupied by green pixels and those doesn't help in
calculating the unknown blue and red values. That is why we get
blue and red color noise in images captured with a mosaic sensor.
Click to expand...
Yes, An indication why it might better to do filtering on the red or blue channel. Cool. :-)

I am clean sky fanatic. I can't wait to see how the skys look with the Foveon. It looks very promising.

Peter
 
Max Strandberg said:
...
As I don't have photoshop, would you mind explaining what algorithm
you used when making your reverse engineering?
Click to expand...
As Peter wrote, I used pretty much the avergaring algorithm you would expect. It's described here:

http://www.peter-cockerell.net:8080/Bayer

(I was surprised to find that the original article didn't contain the actual equations, so I updated it tonight to give a C-like version of the code.)

Cheers,
Pete
Max Strandberg said:
--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
http://hem.bredband.net/maxstr
Click to expand...
-- http://www.peter-cockerell.net:8080/
 
I don't have the credentials to discuss the methods that were used to analyze the Foveon images, but in all honesty, and to be simplistic (I've stated on the Sony Forum this same theme) who cares (other than prosumer/professional) how great the Foveon is. The truth is that its all going to come down to production costs. If the Foveon gives equal or better performance at a lower cost, and there are less penalties in power consumption and design complexity, then the Foveon designs will win the day. People (generally) don't "buy" a technology. They buy the benefits of the technology, and so far I haven't seen anything that makes me think that Foveon will upset the market.

It's ultimately just cool technology, and the market will decide its success.

I base this observation on the fact that I still read comments from people (on other forums) who are ecstatic about the images they are printing from their 1.3 Mp cameras. And I'll bet most consumers are very satisfied as they never print anything larger than an 8 x10 anyway.

In some ways, this reminds me of Transmeta. Cool technology that got caught up with production problems and was surpassed by the big guys. I don't expect that for Foveon, but neither do I expect its competition to roll over.

Tom
 
Gentlemen,

just a little point that justifies my keen interest in Foveon technology. All the pros working in still life I know use digital backs, and use the 4 shots method (4 shots of the same subject with the back moving 1 pixel in each sense) just to avoid interpolation. 1 shot would be faster, but 4 shots give no noise, better colour gradation and a quality that is easier to enlarge. Why bother with this, if interpolation is so good? There must be some reason to have the real pixels read the real image.
Yours,
Fabio
 
I understand that there will be more data available in a raw file from Foveon 3 MP sensor than from an ordinary 3 MP CCD.
What if those data are used to compute an interpolated 6 MP image ?

The underlying idea is that, if R G and B values from Foveon are as good as are R G and B values from a CCD, then added interpolated pixels will be as good as (Bayer interpolated) pixels from the CCD !
 
Pete Cockerell said:
As Peter wrote, I used pretty much the avergaring algorithm you
would expect. It's described here:

http://www.peter-cockerell.net:8080/Bayer
Click to expand...
I note that on the green pixels you use only the closest neigbours of red and blue pixels and divide them by 2 to get the value.

I know that this algorithm has been used, and I think this very algorithm is actually unfortunately used in my own Casio 2800. I think the biggest problem with this algorithm is that it produces terrible jaggies when two high contrast areas (one with a lot of red and one with a lot of blue) meet. You will get a staircase effect, instead of a smoothe borderline between the two areas.

To avoid those jaggies you would have to involve more than the two closest neighbours. The easiest equation would be to involve 4 more pixels (that I will call "across the street neigbours"), so that you have the total of 6 pixels to calculate the value from, but since the "across the street neigbours" are not as close as the 2 neigbours they are each worth less than the closest neigbours.

Example:
In this grid you want to know the red value of the green pixel in the center:

GRGRG
BGBGB
GRGRG
BGBGB
GRGRG

The 2 neigbouring pixels should be worth enough to make up something like aproximately 80% of the red value for the green pixel in the center, but the rest should be made up from the red pixels in the upper and lowest rows. That would mean that each neigbouring pixels make up about 40% of the red value and each "across the street neigbour" each make up about 5% of the red value.

I'm well aware that an algorithm using this type of advanced calculations would require either more time or better hardware, so that is probably why it's not always used in consumer cameras.-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ http://hem.bredband.net/maxstr
 
Yes, it all comes down to what is available at a point in time at what price.

When new technologies are introduced, they rightfully talk about all the advantages that they have. But they may or may not even know what there future problems are. They usually compare their new, not in production, technology to the existing/old technology. As we all know the existing digital camera technology is not standing still. Even if the new technology proves in the long run to be better, it usually takes a lot longer than people think to overtake the older technology just due to manufacturing costs and volume of the older technology.

Transmeta is an interesting example. They certainly had some bright people working there (even the guy that created Linux) and it was also a neat idea with lots of great theory that at least made sense on the surface (without gettinginto all the details, they were doing on the fly translation of X86 instructions into their processors native code and applying compiler type optimization on the fly). The market is tough place and competitors like Intel where not standing still. I only every saw them make it at all into a few portables.

Another example that I am particularly familiar with (since I was involved in the creation of Video RAMs and SDRAM) is RAMBUS. RAMBUS focused on peak bandwidth and fewer pins and got a lot of people, including Intel, to buy into it. The first RAMBUS devices had terrible latency (time to get the first bit back) and this was a killer in any real application. RAMBUS went through two generations, changes in architecture, to address the latency issue resulting the the architecture that Intel uses. But by the time they got the the DRAM makers, who did not want to pay royalties to RAMBUS, had finally adopted DDRAM (double data rate SDRAM). If you look at the benchmarks TODAY, DDRAM and RDRAM are virtually identical, but DDRAM is less expensive. Thus Intel is starting to support DDRAM.

Karl
Tom May said:
I don't have the credentials to discuss the methods that were used
to analyze the Foveon images, but in all honesty, and to be
simplistic (I've stated on the Sony Forum this same theme) who
cares (other than prosumer/professional) how great the Foveon is.
The truth is that its all going to come down to production costs.
If the Foveon gives equal or better performance at a lower cost,
and there are less penalties in power consumption and design
complexity, then the Foveon designs will win the day. People
(generally) don't "buy" a technology. They buy the benefits of the
technology, and so far I haven't seen anything that makes me think
that Foveon will upset the market.

It's ultimately just cool technology, and the market will decide
its success.

I base this observation on the fact that I still read comments from
people (on other forums) who are ecstatic about the images they are
printing from their 1.3 Mp cameras. And I'll bet most consumers are
very satisfied as they never print anything larger than an 8 x10
anyway.

In some ways, this reminds me of Transmeta. Cool technology that
got caught up with production problems and was surpassed by the big
guys. I don't expect that for Foveon, but neither do I expect its
competition to roll over.

Tom
Click to expand...
--Karl
 
I also created a simple interpolation program. You can download it along with some sample images at:
http://users.ezwv.com/~bobander/Interpolate/interp.zip

You can use the program to compare original images with those that have been interpolated using a bilinear method.

I am trying not to get too excited about the Foveon imager until I see real results from a camera that is on the market. I am most impressed by the low noise in the images they have shown. That and the true color of each pixel should allow the images to be printed larger without visible errors. If a 3MP X3 image can make a print which is as good or better than a 6MP image from a Bayer type sensor, then we could store more images on a memory card, do less processing in the camera and cycle much faster between shots. That's the real news if it turns out to be true.
 
Yes, Part II of my article, which I never got round to writing, was going to discuss something like what you propose, though with more of a heuristic to detect edge transitions in order to reduce the color artifacts. It seemed so complex to implement using the Adobe Filter Maker (which is what I used fort he other one) that I never got round to it.

I did finally get round to coding the simple algorithms in Java last night, though, thank's to the impetus of Peter's original post, so maybe I'll be more inclined to tweak that one.

Cheers,
Pete
Max Strandberg said:
Pete Cockerell said:
As Peter wrote, I used pretty much the avergaring algorithm you
would expect. It's described here:

http://www.peter-cockerell.net:8080/Bayer
Click to expand...
I note that on the green pixels you use only the closest neigbours
of red and blue pixels and divide them by 2 to get the value.

I know that this algorithm has been used, and I think this very
algorithm is actually unfortunately used in my own Casio 2800. I
think the biggest problem with this algorithm is that it produces
terrible jaggies when two high contrast areas (one with a lot of
red and one with a lot of blue) meet. You will get a staircase
effect, instead of a smoothe borderline between the two areas.

To avoid those jaggies you would have to involve more than the two
closest neighbours. The easiest equation would be to involve 4 more
pixels (that I will call "across the street neigbours"), so that
you have the total of 6 pixels to calculate the value from, but
since the "across the street neigbours" are not as close as the 2
neigbours they are each worth less than the closest neigbours.

Example:
In this grid you want to know the red value of the green pixel in
the center:

GRGRG
BGBGB
GRGRG
BGBGB
GRGRG

The 2 neigbouring pixels should be worth enough to make up
something like aproximately 80% of the red value for the green
pixel in the center, but the rest should be made up from the red
pixels in the upper and lowest rows. That would mean that each
neigbouring pixels make up about 40% of the red value and each
"across the street neigbour" each make up about 5% of the red value.

I'm well aware that an algorithm using this type of advanced
calculations would require either more time or better hardware, so
that is probably why it's not always used in consumer cameras.
--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
http://hem.bredband.net/maxstr
Click to expand...
-- http://www.peter-cockerell.net:8080/
 
I am getting interested in playing with algorithms. Is there a better venue for this discussion? Retouching forum?

Peter
Pete Cockerell said:
I did finally get round to coding the simple algorithms in Java
last night, though, thank's to the impetus of Peter's original
post, so maybe I'll be more inclined to tweak that one.

Cheers,
Pete
Max Strandberg said:
Pete Cockerell said:
As Peter wrote, I used pretty much the avergaring algorithm you
would expect. It's described here:

http://www.peter-cockerell.net:8080/Bayer
Click to expand...
I note that on the green pixels you use only the closest neigbours
of red and blue pixels and divide them by 2 to get the value.

I know that this algorithm has been used, and I think this very
algorithm is actually unfortunately used in my own Casio 2800. I
think the biggest problem with this algorithm is that it produces
terrible jaggies when two high contrast areas (one with a lot of
red and one with a lot of blue) meet. You will get a staircase
effect, instead of a smoothe borderline between the two areas.

To avoid those jaggies you would have to involve more than the two
closest neighbours. The easiest equation would be to involve 4 more
pixels (that I will call "across the street neigbours"), so that
you have the total of 6 pixels to calculate the value from, but
since the "across the street neigbours" are not as close as the 2
neigbours they are each worth less than the closest neigbours.

Example:
In this grid you want to know the red value of the green pixel in
the center:

GRGRG
BGBGB
GRGRG
BGBGB
GRGRG

The 2 neigbouring pixels should be worth enough to make up
something like aproximately 80% of the red value for the green
pixel in the center, but the rest should be made up from the red
pixels in the upper and lowest rows. That would mean that each
neigbouring pixels make up about 40% of the red value and each
"across the street neigbour" each make up about 5% of the red value.

I'm well aware that an algorithm using this type of advanced
calculations would require either more time or better hardware, so
that is probably why it's not always used in consumer cameras.
--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
http://hem.bredband.net/maxstr
Click to expand...
--
http://www.peter-cockerell.net:8080/
Click to expand...
 
It seems to me like all the discussions about bayer filter algorithms are focused on spacial domain thinking. The algorithms in a good camera can afford to be a lot more complex. The cost of processing halves about every 18 to 24 months I don't think that bayer conversion is not a major part of the cost of a camera anyway.

The real issue is accurate capture of the Luma. With very rare exceptions, there is no need to capture chroma/color at any where near the resolution of the Luma/Intensity information. Futhermore in the REAL world chroma does not change that rapidly (more on that in the pictures below).

Having 3 sensors each pixel CAN be an advantage in more accurately capturing luma. With a Bayer pattern, there is luma information in all 3 colors but a lot of the light is thrown away. The real issue for Foveon will be how accurately they can capture the luma in each pixel. It has 3 sensors, but how effecient are these sensors.

Also Foveon is introducing a 3 Megapixel X3 when the other companies are introducing 6MP bayer devices. Now if the 6MP are noisy in the Luma, then they may not produce a better image, but they will have more resolution as they can at least detect the higher resolution.

The examples of herringbone cloth patterns are only an issue if you take a lot of pictures of gray toned weave patterns for most of your pictures (for most people a problem for less than 1 in 1000 pictures and usually very easily fixed in a photo editing package). This is a classic magician and marketing trick of getting you to focus on what the person wants you to focus on.

It is a bit hard to visualize the frequency domain verus spacial domain. To show what is going on, I took a picture in Photoshop, duplicated it twice and put a neutral Gray (R=G=B=128) layer underneath them (this is necessary so you can see the color only image). On one layer I specified COLOR (chroma), on another layer I specified LUMINOSITY (intensity).

The first image below shows the color only. You will notice that is appears to be very fuzzy and low in resolution (the real world is that way). It is amost hard to believe that this lousy set of color does anything. The second image is the Luminosity, notice all the detail. The third image shows it all combined.

Chroma/Color Only on neutral gray:
http://www.fototime.com/ {6CDE544E-3C28-4616-98AD-1A89D1F84073} picture.JPG

Luma Only:
http://www.fototime.com/ {0693E3EC-6AA5-4B60-BE23-0F9B004B94B3} picture.JPG

Combined Image
http://www.fototime.com/ {2BBF0604-99E5-400A-858A-D1668FA1C1CE} picture.JPG

--Karl
 
RAW file of a 3MPx3 is actually 50% bigger than a standard 6MP.
For Jpeg probably smaller due to lower noise (and only 3MP)

From drawing shown of the X3 patent, it is highly unlikely that the actual dimension of the RGB sensor inside each pixel is 100% identical in size or shape. So theoretically, if we do some postprocessing of the RAW file - more than 3MP of resolution is not impossible. With 10 Mpixels (50% more data than a 6MP) to play with, a lot can be possible.

I said post processing because the biggest problem of current generation of X3 is slowness to retrieve data (only 2fps maximum)

That's the theoretical maximum according to spec of x3. Practically (after adding the time need to process and store the data) it is so slow that Sigma spec say it can only shot in continous mode at 'LOW' resolution!.

That unfortunately seem to exactly the opposite as you mentioned below.

I would say these are all indications of an immature technology. It may change the whole industry in a few years but not now. I think in a few years when the technology of sensor became so good that the limiting factor of better picture is the optics but not sensor - the X3 may have a bigger advantage - less light is wasted. But then who know what breakthrough in sensor may happen in just a few years.
Robert Anderson said:
I also created a simple interpolation program. You can download it
along with some sample images at:
http://users.ezwv.com/~bobander/Interpolate/interp.zip
You can use the program to compare original images with those that
have been interpolated using a bilinear method.
I am trying not to get too excited about the Foveon imager until I
see real results from a camera that is on the market. I am most
impressed by the low noise in the images they have shown. That and
the true color of each pixel should allow the images to be printed
larger without visible errors. If a 3MP X3 image can make a print
which is as good or better than a 6MP image from a Bayer type
sensor, then we could store more images on a memory card, do less
processing in the camera and cycle much faster between shots.
That's the real news if it turns out to be true.
Click to expand...
 
Karlg said:
The first image below shows the color only. You will notice that
is appears to be very fuzzy and low in resolution (the real world
is that way). It is amost hard to believe that this lousy set of
color does anything.
Click to expand...
Well, the whole point is that the color information is not optimized for detail, as opposed to luminance. However, you might find it interesting that it is possible to transform your color image into a luminosity image if you tweak the colors. Changing the RGB relationship to 60% green, 29% red and 11% blue for the picture will yeld an image that has luminosity information and thereby will seem more detailed for the human eye than the color image. If you create a greyscale image from that tweaked color image you will not end up with a monotounous grey, but will actually get a visible image. If I'm not mistaken this is basically how Bayer images obtain luminosity in the first place.
-- ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ http://hem.bredband.net/maxstr
 
Hi,

I believe you are correct in your analysis. Keep in mind that nearly all the electronic images we have ever seen have been taken with one kind of color filter array or another (the main exception being 3-chip color video cameras). The image Foveon used to show color artifacts is really ugly. Have we seen any modern camera do such an awful job? I don't think so! There are probably subtle improvements they could claim, but the real issue is sensitivity. They should be able to achieve a high ISO roughly 3X a "normal" device (CCD or CMOS). Where is it? Could it be the the color processing needed to give good color from such poorly separated color channels increases the final image noise?
--Charles V. Stancampiano
 
You must log in or register to reply here.

Similar threads

left eye
Do you also use a Foveon sensor camera?
2 3
Replies
54
Views
55
marcio_napoli
marcio_napoli
TN Args
Colour Spectra charts Foveon vs Bayer
2
Replies
23
Views
24
fferreres
F
S
Digital vs Optical: HR pixel-shift; HHHR; Topaz Gigapixel AI and Adobe PS
Replies
0
Views
1
Serguei Palto
S
O
Canon EOS 750d poor colour representation with sky and detail with longer range (landscape) shots
Replies
12
Views
13
stevet1
S
T
Myths about RAW and JPEG -- A thorough (read: long) list.
6 7 8
Replies
150
Views
151
Bob A L
B

Keyboard shortcuts

f
Forum
m
My threads
Mobile site
About
Editorial content
Cameras & Lenses
Community
All content, design, and layout are Copyright © 1998–2025 Digital Photography Review All Rights Reserved.
Reproduction in whole or part in any form or medium without specific written permission is prohibited.
When you use DPReview links to buy products, the site may earn a commission.
©GPS Media - Guides, Products, Services.
Back
Top