Yes it is compatible in the sense that with some temporal filtering you can probably convert the event-based representation to a difference image representation (and this is probably what I'd do if someone forced me to use this sensor for my work), but then you're stuck with the disadvantages of both representations.
I have seen this demo in person and chatted at length with its creator. It uses a custom sensor chip that does some analog temporal filtering and thresholding of light intensity at each pixel, sending events when the threshold is crossed. The intent of the authors seems to be to mimic the human visual system in silicon, even if it makes no engineering sense whatsoever. The demo was extremely sensitive to fluorescent lighting; the author had to run out and buy an incandescent desk lamp to get it to work at all. The event-based image representation makes it incompatible with everything that has been learned in computer vision over the last decade.
Are you a programmer? Intelligently choosing the layout of your data is a significant part of writing high performance code. It is not some exotic hack. It is supported in all of the languages one uses for writing high performance code (C, C++, Fortran, CUDA, OpenCL, etc.).
None of those languages have a ~standard strided array type, and library writers have produced a huge mess of incompatible matrix types as a result. Golang is headed down the same path.
Here's another example... They currently have an image reading library that has its own image type.
It doesn't support slicing out a sub-array to get a sub-image, i.e. im[10:20, 10:20,:]. It doesn't support slicing out the channel you want, i.e. im[:,:,0] for Red channel. It doesn't support even basic math operations, i.e. adding together two images. All of this is stuff that should get implemented in a very general, standardized way. The same will go for multi-channel audio data. If someone core to the project doesn't act quickly, it will be increasingly difficult to even achieve uniformity within the Go standard library.
This is all about having standardized container class for data stored in multi-dimensional arrays. Most users, most of the time, will use whatever the default storage is. However, users writing high performance numerical algorithms have a legitimate need to be able to manually manage the layout of their data in memory so that they can optimize their data access pattern. There is no avoiding this, and if golang follows it's current trajectory, array formats will be just as much of a fragmented mess as they are in the C/C++ world.
You can't. That's the problem. Because there is no good language-level support for multi-dimensional arrays, most languages are forced to deal with something as basic as storing an array of numbers in libraries. Since it's more difficult to write a library that supports multiple storage formats (even ignoring efficiency), most libraries don't, and the user is forced to write code to translate between them.
Compilers cannot be expected to decide what storage is appropriate for each of the arrays in your never-been-seen-before algorithm, and when it is appropriate to switch between storage types, when to duplicate the same array with different storage, etc...
Last I checked, Go has no language-level support for scientific computing whatsoever. At MINIMUM they should provide a standardized, fully-strided, ndarray data container, so that the libraries that developers add later will at least be able to easily share data. And if this is all they provide, I hope at least the language definition is flexible enough to extend the syntax to support things like slicing and broadcasting.
The scientific and engineering world really needs a language that combines the ease-of-use of python/numpy with language-level support for expressing concurrency. I hope Go will eventually become this language, but this is clearly not a priority for the Go developers at this time.
Unless you are using a high-end camera built for machine vision and scientific purposes that you are certain has a linear gamma curve, the numerical values in the image files are ~not proportional to photon counts. Likewise, if you display a linear ramp of data as an image (say using something like MATLAB's imshow(repmat(linspace(...),...)), your monitor will not emit a linear ramp of photon intensity. Until MATLAB, PIL, opencv, et al provide build-in conversion functions, you're going to have to use a home-rolled gamma conversion functions whenever you display data, and whenever you load data from an image file (unless you used a camera that you're sure is linear).
Unfortunately, RAW files are not even a guarantee of linearity; I've heard of cameras that do gamma compression in the analog domain, i.e. before digitization.
"the assumption one makes is that these integer values are not photons ^( 1/gamma) but simple photon counts (scaled to the 0-255 range)."
That is a very reasonable assumption to make, and one that most people who don't know anything about gamma make. Unfortunately, it's flat out false. Both MATLAB and PIL return the gamma compressed data, which, unless you used a linear machine vision camera (and you should if you're serious about this stuff), which of course had no gamma compression to begin with. If you need proof, load and save an image. The image data will be bit for bit identical to the original, indicating that no conversions were performed. (note that the header might have slightly different metadata, and JPEG re-compression is usually always lossy)
Gamma is so rarely handled properly, even by scientists and engineers, that OpenCV (the most popular library for computer vision) does not even contain a function for doing gamma (de)compression.
It comes from the nonlinear response of the phosphors in CRT's to the number of photons that hit them. Of course, monitors all differ slightly. IIRC magic 2.2 came from microsoft. Apple used (and probably still uses) a different magic number.
I was talking about scientific and engineering uses, which often depend on the gamma curve even if most authors ignore it.
Most photographic software is oriented towards deliberately messing with the gamma curves arbitrarily to achieve aesthetic goals. Consumer cameras are even starting to do this onboard the camera, in, as far as I know, completely un-documented ways (indeed, they probably consider them trade secrets). See features like iContrast in canon cameras.
Gamma is often poorly understood even by people doing scientific and engineering work using images.
Does your algorithm depend (explicitly or implicitly) on the light intensity -> pixel data mapping?
If NO: You're probably wrong. Go read about gamma. Just because the picture looks right to you, doesn't mean it looks right to your code.
If YES:
Do you have the luxury of taking the pictures yourself?
If NO: You're stuffed. Pretty much all images on the internet and most public research databases have unknown/unreliable gamma curves.
If YES:
1. Spend a lot of time calibrating your camera yourself. This is only cheap if your time is worthless
or
2. Buy a machine vision camera. A $600 machine vision camera will have the specs of a $50 consumer camera, but at least you will know the gamma curve.
or
3. Ignore the gamma issue, cross your fingers, hope it's not hurting your performance, and publish your results knowing that you're in good company and nobody will call you out.
After waiting patiently for the US Government to implement a carbon tax, the ever-altruistic Utah mafia has decided to take matters into their own hands.
It was the ~android version of the app won an award. For these tiny applications, the GUI practically ~is the application. Claiming that the iPhone version of the app won an award is simply false advertising, so Apple tactfully asked them to fix the language.
Unfortunately, you're wrong about the triple-architecture (by which I assume you really mean triple platform) support.
I recently exchanged a couple e-mails with Zachary Schneirov, the author, about what form a Linux version could take, but no port currently exists. Have a look at the (Cocoa) source code in the git repository and see for yourself.
I use Notational Velocity. It's open source, mac. Make sure you turn on encryption. I'm using version 1.1.1. It's a minimalist application that was written for a user interface class at Northwestern University. The design is as elegant as it could possibly be.
Most of the posters seem to be under the false impression that this will be some huge wind tunnel facility. One of the difficult problems in designing a wind turbine is that the shaft turns very slowly, but electrical generators operate much more efficiently at higher shaft velocities. With the sort of dynamometer they are talking about, you use a very large motor to spin the generator (and possibly the attached drivetrain) and measure how its efficiency throughout its speed range.
If you read the PEP you link to more carefully, you'll note that the context is that the octave developers were recommending adding an operator for multiplication to python, but ~against symbols for matrix inversion / linear system solving. Also, you can get away with doing inv(A)*b if A is well enough conditioned. There are better ways, but if you're just manipulating, say, a bunch of affine transformation matrices, an inversion or two won't hurt you.
Also, Python as a language has many advantages over MATLAB in addition to being free software. Basically, Python is a great general purpose language with number-crunching tacked on, and MATLAB is a great number-crunching language with everything else (i.e. GUI Programming, Object Oriented Programming) tacked on.
In know, what's next, porn mashups from videos of people writhing around naked and alone in front of their webcams? Rave mashups from loners waving around glowsticks in their basements?
Slashdot Mirror
It's because all of the open hardware/software geeks have been naughty this year...
http://xkcd.com/838/
... and superior space heating capacity!
Yes it is compatible in the sense that with some temporal filtering you can probably convert the event-based representation to a difference image representation (and this is probably what I'd do if someone forced me to use this sensor for my work), but then you're stuck with the disadvantages of both representations.
I have seen this demo in person and chatted at length with its creator. It uses a custom sensor chip that does some analog temporal filtering and thresholding of light intensity at each pixel, sending events when the threshold is crossed. The intent of the authors seems to be to mimic the human visual system in silicon, even if it makes no engineering sense whatsoever. The demo was extremely sensitive to fluorescent lighting; the author had to run out and buy an incandescent desk lamp to get it to work at all. The event-based image representation makes it incompatible with everything that has been learned in computer vision over the last decade.
Are you a programmer? Intelligently choosing the layout of your data is a significant part of writing high performance code. It is not some exotic hack. It is supported in all of the languages one uses for writing high performance code (C, C++, Fortran, CUDA, OpenCL, etc.).
None of those languages have a ~standard strided array type, and library writers have produced a huge mess of incompatible matrix types as a result. Golang is headed down the same path.
Here's another example... They currently have an image reading library that has its own image type.
It doesn't support slicing out a sub-array to get a sub-image, i.e. im[10:20, 10:20, :]. It doesn't support slicing out the channel you want, i.e. im[:,:,0] for Red channel. It doesn't support even basic math operations, i.e. adding together two images. All of this is stuff that should get implemented in a very general, standardized way. The same will go for multi-channel audio data. If someone core to the project doesn't act quickly, it will be increasingly difficult to even achieve uniformity within the Go standard library.
This is all about having standardized container class for data stored in multi-dimensional arrays. Most users, most of the time, will use whatever the default storage is. However, users writing high performance numerical algorithms have a legitimate need to be able to manually manage the layout of their data in memory so that they can optimize their data access pattern. There is no avoiding this, and if golang follows it's current trajectory, array formats will be just as much of a fragmented mess as they are in the C/C++ world.
You can't. That's the problem. Because there is no good language-level support for multi-dimensional arrays, most languages are forced to deal with something as basic as storing an array of numbers in libraries. Since it's more difficult to write a library that supports multiple storage formats (even ignoring efficiency), most libraries don't, and the user is forced to write code to translate between them.
Compilers cannot be expected to decide what storage is appropriate for each of the arrays in your never-been-seen-before algorithm, and when it is appropriate to switch between storage types, when to duplicate the same array with different storage, etc...
Last I checked, Go has no language-level support for scientific computing whatsoever. At MINIMUM they should provide a standardized, fully-strided, ndarray data container, so that the libraries that developers add later will at least be able to easily share data. And if this is all they provide, I hope at least the language definition is flexible enough to extend the syntax to support things like slicing and broadcasting.
The scientific and engineering world really needs a language that combines the ease-of-use of python/numpy with language-level support for expressing concurrency. I hope Go will eventually become this language, but this is clearly not a priority for the Go developers at this time.
Unless you are using a high-end camera built for machine vision and scientific purposes that you are certain has a linear gamma curve, the numerical values in the image files are ~not proportional to photon counts. Likewise, if you display a linear ramp of data as an image (say using something like MATLAB's imshow(repmat(linspace(...),...)), your monitor will not emit a linear ramp of photon intensity. Until MATLAB, PIL, opencv, et al provide build-in conversion functions, you're going to have to use a home-rolled gamma conversion functions whenever you display data, and whenever you load data from an image file (unless you used a camera that you're sure is linear).
Unfortunately, RAW files are not even a guarantee of linearity; I've heard of cameras that do gamma compression in the analog domain, i.e. before digitization.
"the assumption one makes is that these integer values are not photons ^( 1/gamma) but simple photon counts (scaled to the 0-255 range)."
That is a very reasonable assumption to make, and one that most people who don't know anything about gamma make. Unfortunately, it's flat out false. Both MATLAB and PIL return the gamma compressed data, which, unless you used a linear machine vision camera (and you should if you're serious about this stuff), which of course had no gamma compression to begin with. If you need proof, load and save an image. The image data will be bit for bit identical to the original, indicating that no conversions were performed. (note that the header might have slightly different metadata, and JPEG re-compression is usually always lossy)
Gamma is so rarely handled properly, even by scientists and engineers, that OpenCV (the most popular library for computer vision) does not even contain a function for doing gamma (de)compression.
It comes from the nonlinear response of the phosphors in CRT's to the number of photons that hit them. Of course, monitors all differ slightly. IIRC magic 2.2 came from microsoft. Apple used (and probably still uses) a different magic number.
> Thus we should fix the real problem, and make the hardware (or at the very least, the OS abtraction layer) conform.
It seems you are advocating option 2 from my post.
I was talking about scientific and engineering uses, which often depend on the gamma curve even if most authors ignore it.
Most photographic software is oriented towards deliberately messing with the gamma curves arbitrarily to achieve aesthetic goals. Consumer cameras are even starting to do this onboard the camera, in, as far as I know, completely un-documented ways (indeed, they probably consider them trade secrets). See features like iContrast in canon cameras.
Gamma is often poorly understood even by people doing scientific and engineering work using images.
Does your algorithm depend (explicitly or implicitly) on the light intensity -> pixel data mapping?
If NO: You're probably wrong. Go read about gamma. Just because the picture looks right to you, doesn't mean it looks right to your code.
If YES:
Do you have the luxury of taking the pictures yourself?
If NO: You're stuffed. Pretty much all images on the internet and most public research databases have unknown/unreliable gamma curves.
If YES:
1. Spend a lot of time calibrating your camera yourself. This is only cheap if your time is worthless
or
2. Buy a machine vision camera. A $600 machine vision camera will have the specs of a $50 consumer camera, but at least you will know the gamma curve.
or
3. Ignore the gamma issue, cross your fingers, hope it's not hurting your performance, and publish your results knowing that you're in good company and nobody will call you out.
After waiting patiently for the US Government to implement a carbon tax, the ever-altruistic Utah mafia has decided to take matters into their own hands.
It was the ~android version of the app won an award. For these tiny applications, the GUI practically ~is the application. Claiming that the iPhone version of the app won an award is simply false advertising, so Apple tactfully asked them to fix the language.
Unfortunately, you're wrong about the triple-architecture (by which I assume you really mean triple platform) support.
I recently exchanged a couple e-mails with Zachary Schneirov, the author, about what form a Linux version could take, but no port currently exists. Have a look at the (Cocoa) source code in the git repository and see for yourself.
I use Notational Velocity. It's open source, mac. Make sure you turn on encryption. I'm using version 1.1.1. It's a minimalist application that was written for a user interface class at Northwestern University. The design is as elegant as it could possibly be.
http://notational.net/
You forgot:
Subsidizes a lifestyle that results in obesity, driving up the cost of health care for everyone.
Most of the posters seem to be under the false impression that this will be some huge wind tunnel facility. One of the difficult problems in designing a wind turbine is that the shaft turns very slowly, but electrical generators operate much more efficiently at higher shaft velocities. With the sort of dynamometer they are talking about, you use a very large motor to spin the generator (and possibly the attached drivetrain) and measure how its efficiency throughout its speed range.
If you read the PEP you link to more carefully, you'll note that the context is that the octave developers were recommending adding an operator for multiplication to python, but ~against symbols for matrix inversion / linear system solving. Also, you can get away with doing inv(A)*b if A is well enough conditioned. There are better ways, but if you're just manipulating, say, a bunch of affine transformation matrices, an inversion or two won't hurt you.
Also, Python as a language has many advantages over MATLAB in addition to being free software. Basically, Python is a great general purpose language with number-crunching tacked on, and MATLAB is a great number-crunching language with everything else (i.e. GUI Programming, Object Oriented Programming) tacked on.
http://www.scipy.org/NumPy_for_Matlab_Users
In know, what's next, porn mashups from videos of people writhing around naked and alone in front of their webcams? Rave mashups from loners waving around glowsticks in their basements?