h a l f b a k e r y
Go ahead. Stick a fork in it.
idea:
add, search, annotate, link, view, overview, recent, by name, best, random
meta:
news, help, about, links, report a problem
account:
Browse anonymously,
or get an account
and write.
Login
Create account.
|
|
|
instead of making pixel-based imagery, the camera produces vector graphics. you can adjust the complexity - less complex photos look disturbingly abstract. photorealistic vector images are not unheard of.
Is it like the background of this?
http://img154.image...=bagasandmedib0.gif
From Automatic Bag-a-sand™ [theleopard, Jan 09 2008]
björk vector image
http://www.melissac...n.com/image139.html
interesting, but the artist doesn't use gradients, so it kinda looks like those 256-color bitmaps [erlehmann, Jan 09 2008]
Raster to vector
http://en.wikipedia...ki/Raster_to_vector
refers to software and hardware technology for converting raster graphics to vector graphics. [baconbrain, Jan 09 2008]
[link]
|
| |
Can you show me an example of a vector image? Is it like an encapsulated post-script (.eps) file? |
|
| |
well... vector painting is more realistic because it's more.... umm... realistic, but how are you going to capture that on film ? |
|
| |
[theleopard], vector images are images defined by their geometrical characteristics. therefore, they are scalable without blurring. |
|
| |
a simple example would be the image of a circle. a vector image circle is defined by the coordinates of its centerpoint plus the radius. if you scale it up, it still will be rendered as a circle. in contrast, if you scale up a pixel image, it becomed blurry and, well, pixelated. |
|
| |
[FlyingToaster], i will use digital memory. |
|
| |
..... what ?
hmm.... nevermind, I'm thinking of something else, ie: I thought you were trying to take a picture of something and capture the different parts that make it up, as vectors... I'm still not sure what you actually *are* doing, mind. |
|
| |
A digital camera records a scene by detecting the light impinging on each pixel of a multi-pixel CCD. How would it detect the geometric properties of the scene in such a way as to produce a vector image? |
|
| |
Yeah, how would you do this? You can create an image in the usual way and then convert it inside the camera, but you can do that with Illustrator already. |
|
| |
[leopard] i think he's doing the Postscript thing. |
|
| |
//i think he's doing the Postscript thing.//
No, he/she is, not specifically at least, not. But, even more perversely, he/she is robbing the processing unit of the camera for things a computer should be doing. Peripherals should remain peripherals. OCR does not happen on the scanner, but in the "Machine". Machines are more upscalable because they are *processing* devices. To turn your image capturing/ audio capturing device into the processing unit is obscure, obtuse and would render the device obsolete, obviating its porpoise. Further, if this were possible (without *large* CPU taxation) it would have been done. In fact it is provable that there are images that machines will "never" parse, computationally. Once again I point to Luis and his CAPTCHAS. |
|
| |
why exactly should there be images that could never be parsed automagically, [4whom] ? |
|
| |
There are many reasons [ERlehmann], but I will outline the two most important, wrt, the image topic. But first, some how...
|
|
| |
A CCD array will capture the photons' frequency at a given "point" (i.e. in the array) at a specific shutter speed. Measurement from these charged coupled devices is controlled by a clock signal, already orders (possible hyperbole) of magnitude faster than the shutter. Significant oversampling/undersampling calculations already take place to give you your RAW/jpeg image per pixel. RAW being the aggregated raw data from each pixel, and Jpeg being the, following from raw data, standard compression.
|
|
| |
Now, some why....
1. Given the above between each pixel, but not every pixel, there will be a different read. The "processor" sees only like and dislike numbers. Our eyes can, not only *not* differentiate between certain shades and certain colours, but can also assimilate, or relate, certain shades and colours as one. This gives humans the innate ability to recognise. This ambiguity of assimilating some similar data, and discarding other, also similar, data is key to recognition. Computers still do not know which similar data to discard, and which to keep.
Given a RAW read, humans can say that those things growing out of Eli's head are palm trees, some distance back. For the "machine" the differential (of shades alone) in an algorithm, will differentiate between Eli's neck and Eli's chin, as two seperate objects, but (the same algorithm) not perhaps between his hair and the palms behind him. This is, of course, an over simplification to illustrate a point. More and more the algorithms are being developed to overcome this problem. And more and more, computers take several passes over the data. One algorithm seperates x, another x1 and another x2, etc.
|
|
| |
2. Context. It is not possible, mathematically, for a computer, at this time, to distinguish between a circle tilted in a specific environment, under specific lighting, from an elipse under specific lighting producing a similar display on the array, in one pass. This kills the vector conversion. This is also disorienting to the human observer. But the human observer has the power of association of different perceived elements in the image, or different POV (points of view, whether in sequence or temporal ie historic). The variation of these associations, and the fact there are un-differentiable associations (i.e chin v neck), are such that a "computer" cannot parse it without multiple, and I mean *multiple* inputs (see link to blaise Aguera' y Arcas's SeaDragon and Photosynth).
|
|
| |
Those are just two reasons why computers may *never* parse information that travels at the speed of light, in the medium, from one point of view (one point in space-time). That is why CAPTCHAS are only offering you one view at one time interval. |
|
| |
1. of course the RAW data produced should be of very high dynamic range. algorithms today don't solve gradients good enough, but i think it isn't impossible to do it the right way ™. |
|
| |
2. i dont know why your differention between a tilted circle and a ellipse should be of any importance - i am talking about a 3D projection onto a 2D environment. i can define the same shape by different means - a simple example would be an ellipse that can be either created by just defining the two radiuses or by defining a circle and stretching it. |
|
| |
also, i am not talking about photosynth stuff or metadata or artificial intelligence that "understands" (and therefore deleted your link). |
|
| |
This is just stupid. Raster (pixels) to vector is baked, if a little obscure to most folks. Wishing for a camera that does it is goofy--a combination of baked, impossible and useless. |
|
| |
Raster to vector takes some serious computing power that would be hard to pack into a camera. Porting the image file over to a computer is too easy, nowadays, to bollix up a camera with added crap. |
|
| |
Besides, there's no damn point in doing it in camera, really. Vector images are almost always used in a computer, not printed out to paper. If it's to be viewed in a camera, it might as well be pixels. This is silly. |
|
| |
[erlehmann], I don't know what your background is, but either you don't know what the hell you are on about, or you are being deliberately rude. Don't delete annotations or links unless you absolutely have to, and don't post gibberish in response to careful explanations. |
|
| |
//i dont know why your differention between a tilted circle and a ellipse should be of any importance - i am talking about a 3D projection onto a 2D environment.//
|
|
| |
The defence rests, your honour. |
|
| |
If you are not going to listen to me, or Blaise, then at least have the decency to admit that peripherals should not "crunch" data, they should accept it. Leave data crunching to devices that can be upgraded. In fact the only reason I launched into a diatribe is because you asked the question. Computers cannot accept images on undulating, or even, tilted topographies, without multiple points of view. Humans can. That's the point. |
|
| |
[baconbrain], i would like it to record directly as a vector (cleaner) but have no good idea as of now. |
|
| |
[4whom], devices /do/ crunch data right now. cameras save jpegs, for example. |
|
| |
Jpeg is a compression of a bitmap image. Each bit (or 8 or 16 or 24 or 32 or ...) mapped to a pixel. There are no compressions of vector images, unless converted to a bitmap. A vector diagram is a mathematical construct of the image. You can tilt it in any of three dimensions. You can apply guage variance (zoom in, zoom out). It is almost a one-way function. Can go from vector to BMP, no problem. But BMP/<compression format of choice> to vector implies transalation, implies parse-ing. Can be done. Only in two dimensions, and keep it on the computer side and not the device.
|
|
| |
I few things I have said, that seem to have gone unnoticed.
1. Cameras accept, essentially, bitmapped data.
2. The clock speed of the processor correlating the charged coupled devices is big (as a denominator) and the procesor does millions of calculations just to deliver RAW data.
3. Jpeg compression is done on this RAW data, more processor drag.
4. This is all Shannon-Nyquist, Fast Fourier Transform stuff, programable, and accounted for, and fucking fast.
5. The addition of multiple algorithm passes on data that has been captured (to reduce it to vector, to correct histogram anamolies, etc), is the preserve of the machine to which the captured data has been sent.
6. I have never once said it was impossible (with the exception of certain elements, as with OCR). Only that in terms of processing power, give it to the machine with processing power. |
|
| |
Despite conventional photographic films being percieved as "analogue" they are in fact subject to quantisation, this being a function of the grain size in the emulsion. Theoretically, then, the lower limit of resolution would be a single molecule of light sensetive material, although this is not practically achievable. |
|
| |
The fim functions as a massively parallel image capture device. |
|
| |
With a CCD, all the pixels latch their data on a single clock pulse from the control system, this being exactly analagous to the shutter in a film camera. |
|
| |
The issue is the actual resolution of the CCD matrix. |
|
| |
It may be appropriate to consider another capture system, that of the original image orthicon tube used in the early TV cameras. This uses a coated image reception surface which is front surface scanned by an electron beam, the beam current being proportional to the photovoltaic excitation of the capture plate. Resolution is determined by the spot size of the scanning beam. |
|
| |
Traditionally, orthicons are raster scanned; but there is no practical reason why they cannot be vector scanned using a diddle yoke, producing a much higher resolution. |
|
| |
Dichroic prisms and three orthicons would be required for colour images, |
|
| |
Despite odds which I calculated to be in
excess of 476,000 to 1, "diddle yoke"
turns out to be a legitimate term. |
|
| |
//Traditionally, orthicons are raster scanned; but there is no practical reason why they cannot be vector scanned using a diddle yoke, producing a much higher resolution//
No, the resolution is still defined by the spot size. [-] |
|
| |