h a l f b a k e r yI CAN HAZ CROISSANTZ?
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
All digital cameras that I know of take (boring) rectangular pictures with a square grid of pixels, and display them with a rectangular display screen, or on a rectangular computer monitor, or print them out onto a rectangular piece of paper, and frame them with a rectangular picture frame.
I believe
this is because squares are much easier for people to comprehend than most other shapes. And people like squares because they don't waste space when they are flat against each other. And squares are compatible with many existing technologies. And squares are traditionally used.
I believe hexagons and triangular grids are better.
Anyway, my idea is a digital (or a superior technology which might be used in the far future) camera with a hexagonal image sensor which would have a triangular grid of hexagonal pixel sensors. The camera would also have a hexagonal display, and possibly a hexagonal viewfinder.
More vertical images such as portraits could be accomplished by rotating the camera 30 degrees (compared to current cameras which have to be rotates 90 degrees).
This technology could also be applied to digital video cameras, as well as cellular phones and other devices. Most digital cameras nowadays have a video mode anyway.
The created images could also be viewed and edited with the linked idea.
Hexagonal Display
Hexagonal_20Display
[BJS, Jul 01 2007]
Hexagon
http://en.wikipedia.org/wiki/Hexagonal
[BJS, Jul 01 2007]
a similar idea
Circular_20CCD_20ch...20digital_20cameras
Circular CCD chip for digital cameras [BJS, Jul 01 2007]
Hex Grid Example
http://i211.photobu...CD.gif?t=1183324554
[BJS, Jul 01 2007]
Charge-coupled device
http://en.wikipedia...device#Applications
[BJS, Jul 02 2007]
[link]
|
| |
[Ian] Do they take turns using it? |
|
| |
I would like to hear some details on how you are going to manage pixel ordination. A rectangular CCD with pixels in a regular array maps neatly to a two dimensional grid. Each pixel is clearly identified by horizontal count and a vertical count. What do you see replacing this for a hexagonal CCD? |
|
| |
I'll have to think about that. |
|
| |
You can use the same coordinate system.
It's just that each row is offset by half a
cell from the one above. In the vertical
direction, each row slightly interdigitates
with those above and below. |
|
| |
If you keep the same x,y coordinate system there is no intrinsic information as to valid versus invalid pixels (the corners are invalid.) As an example in the simplest case, a seven pixel image using x.y coordinates has two dead pixels 0,0 and 0,2. |
|
| |
I cant picture what you mean Galbinus_Caeli by "two dead pixels 0,0 and 0,2.". |
|
| |
I'm thinking that the pixel coordinates could be identified by starting with the number of pixels in the center row, then half of that number minus half a pixel would be the number of rows above or below the centerline. The pixel location would then be measured by a + or a - meaning above or below the center line (move the + or - for the center line), and would be followed by a row number for how far away from the center row it is, then there would be a pixel number for how far away it is from one side or the other, accounting for the fact that each row away from the center row is one less pixel than the previous row. Three examples are: +211,409 , 0,89 , -112,46. |
|
| |
Or a third way that I haven't thought enough about yet. |
|
| |
Lets see if I can draw it: |
|
| |
ok, there is hour seven pixel array.
You see that in order to keep things line up, you have to start every other line with an unused pixel. Line one is 0,0 (unused) 0,1(used) 0,2 (used).
Then line two is 1,0(used) 1,1(used) 1,2(used). And line three is 2,0(unused) 2,1(used) 2,2 (unused). |
|
| |
If we do a larger array it might be more clear, also we start having unused coordinates at the beginning and end of each line. |
|
| |
The pixels marked with a "O" are never used and need to be somehow accounted for OUSIDE of the actual array. Notice that in the first array above, pixel 0,1 is used, and is valid in the image. In the second array, that location is meaningless and has no value. So if I am writing a rendering engine for this image I either have to KNOW how big the image is before I start processing it, or I have to evaluate its properties before I can even start. |
|
| |
OK, I understand what you mean (except for maybe the last part of the last paragraph). I think we wouldn't use a normal X,Y coordinate system like you are thinking of. We would probably have to make a new system. |
|
| |
My thought exactly. We need something more elegant than x,y. |
|
| |
And sorry if the last paragraph is confusing. My real job is deeply involved in image processing. |
|
| |
Have you read my second annotation (*edited*), or looked at the fourth link? |
|
| |
I have looked at both. And I was intending to agree with you that some new system was needed. Sorry if it did not come out that way. |
|
| |
You came out fine, I just wanted to know if you've read all that I typed and if you have any ideas or suggestions. |
|
| |
Well, one way to do it would be to use ring, radial count. First number is the count of rings from the center of the image. The second is a count of hexes around that ring. So the center hex is 0,0 The ring around that one is 1,0; 1,1; 1,2; 1,3; 1,4; and 1,5. The ring around that is 2,0 to 2,11. |
|
| |
One complication of this is that the ring number and the radial number will not be the same magnitude. (On ring 256 there are 1536 hexes. It would take one byte to record the ring, one and a half to record the radial.) Not really a problem if the encoding includes some sort of End Of Ring marker. |
|
| |
One other difficulty (sorry, thinking this through as I go) is that by ending the ring at a radial like this, you could be putting image defects in a line across the image. (In a rectangular image, if there is an error in a line of pixels it might only be perceivable at the end of that line, which is the right hand edge of the image, the human eye typically doesn't even notice this.) But a smart rendering image could just average the surrounding pixels and make it unnoticeable. |
|
| |
Sorry to go on like this, but I think you have a very interesting idea, and I am having fun playing with it in my head. |
|
| |
A hexagonal array would also make it easier to allocate pixels into R, G and B than a square array (which usualy has two "G" pixels in every block of 4, I think). |
|
| |
The doubled green is kind of an artifact of using a rectangular grid CCD. I am not sure it would apply to a hexagonal grid. Basically you need to record three light levels at each location, one each for red green and blue. |
|
| |
My expertise is more in gray scale and monochrome imaging. But color is really just triple gray scale. I would record a strings of double bytes, each recording a red green and blue level. At the end of each ring I would include an end of line marker, perhaps 0D0A0D0A0D0A. (If that byte code were to come up in actual data, I would bump the red channel up by 1.) This would give the rendering algorithm two ways to establish end of line (byte counting, and EOL marker). I would probably also include a header including the number of rings in the file, to allow prespacing during rendering. |
|
| |
By "hexes" do you mean pixels? |
|
| |
I don't know a lot about computer programming or how microprocessors and such work, but, I know in CAD programs the angle measurement goes counter-clockwise starting from the right, does the same type of thing apply for what you where suggesting? |
|
| |
I would do it like [GC] suggests. He really sounds like he knows what he's talking about. |
|
| |
Yeah, I mean pixels when I say hexes. The pixels are in a hexagon relationship. |
|
| |
Clockwise or counterclockwise would work. The choice would be arbitrary, so lets say clockwise. Also the angle zero is arbitrary, I would put it pointing up and to the right. This would make pixel 1,0 is up and left of pixel 0,0(center), pixel 1,1 is up right, 1,2 is directly right, 1,3 is down right, 1,4 is down left, and 1,5 is straight left. |
|
| |
[cblunds] "sounds like" being the operative term. |
|
| |