OK, Mr. "Ramanujan", let's play a game: I give you a binary string, and you tell me what image corresponds to it. Are you game?
I won't tell you how the bitstring was computed from the image. I don't tell you how many pixels the image has. I don't tell you anything. I only give you the bits. Wanna play for money?
Given that definition, you can't encode anything as a number. I think someone pointed out above it's the number + the decoding method that is needed for it to be useful and that applies to images or even the gzip and ELF examples in the article. If I give you the number, but don't tell you it's a gzip of a C program, you probably won't be able to decode it easily.
Not quite. One can encode anything into a number. Decoding is what it's hard, especially so if one does not know what the encoding scheme was. I suppose this is one of the reasons why NSA needs astronomical amounts of computational power.
Geees, is this HN??? Am I the one who's too stupid to explain things properly, or is everyone under the weather because it's Monday morning?
An image is a 2-dimensional array. Say it's a M x N array. Suppose we use RGB so that each pixel is represented by 3 bytes. Then you have an M x N x 3 array of bytes. There are infinitely many mappings from the space of all M x N x 3 arrays of bytes into the reals. Of course you can transform the array into a number. But you can do it in many, many ways. If you know what mapping was used, and if the mapping is invertible, then you can obtain the M x N x 3 array of bytes from the number. If you don't know what mapping was used, or if the mapping is non-invertible, then you can't obtain the M x N x 3 array from the number.
So, I claim that an image is NOT a number. I claim that an image is a pair (y,f), where y is a number, and f is an invertible mapping from the space of M x N x 3 arrays into the reals. You guys are looking at y, and forgetting f. That's why an image is not a number, the image is x = f^{-1} (y). In short, one must know f, and f^{-1} must exist.
You're merely arguing there that a number is not necessarily an image, because it cannot be converted into one without knowing how. And you'd be right. But the image is still a number, because it's stored as a series of bits, and any series of bits is interpretable as a number.
I asked: "How can an image be a number?", when I should have asked instead: "How can a number be an image?"
To use the verb to be in this scenario, I demand a one-to-one correspondence between numbers and images. If a number y can represent two distinct images x1 and x2, then we can't use "is", we can only use "can be".
To quote a former President, it depends on what your definition of "is" is.
I think everyone here understands that we require information beyond the number itself to get the image. I agree that a more accurate (pedantic) verb is that a number can store or represent an image. That implies that the number alone is not sufficient to get the image.
The thing is that while f can be in theory anything, it will be one of few things in practice. We can say what f is very simply. While knowing f is important, it's also easy to the point of trivial, so some people here are comfortable being less accurate and just saying "a number can be an image."
This reminds me of philosophy of identity discussion me and a friend used to go through. He thought he could fit a Miata in his old-school Suburban - but maybe he'd have to take off the side mirrors. But if he's allowing the side mirrors to be taken off, then how much is too much before it's no longer a Miata?
Indeed. It seems that for most people here is means can be, while I demand a bit more. Yes, in practice, f will be one of a few mappings, but that does not change the fact that knowledge of f is required. In practice, one merely tries all possible mappings f until one works.
Such lack of precision is only tolerated because computation is fast and cheap. I would love to see people trying all f mappings with the help of an abacus! Let's be thankful that we live in this golden age.
We can go further, actually. We could argue even that (y, f) is not, actually, an image and that's it's just a number and a function. Rather, the image is what's on the screen and only exists when it's displayed.
I'm not trying to continue an argument, but rather just point out that the philosophy of identity can be an elusive thing.
Take an image x, decimate it, and obtain a lower-resolution version of it, which we call z. Are x and z the same image?
Mathematically, no. But when displayed on the screen, then most people would say they are the same. Of course, it depends on the definition of is, but such discussion would be utterly pointless. If we use the same definition, then there's no ambiguity.
But, f is fairly standardized (or rather, there's a short list of standard f's), and bitmaps aren't even hard to understand. Since the isomorphism is both natural and conventional, I would say that in practice it is not accurate to hold f to the same standards as y.
I won't tell you how the bitstring was computed from the image. I don't tell you how many pixels the image has. I don't tell you anything. I only give you the bits. Wanna play for money?