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/