|
32760^2 = 1073217600 'pixels',cells, whathaveyou. Each of these are multiplied by the storage size of the cell datatype, say a single float of 32bits, or a 32-bit integer. The result, Just To Store The Surface, is 34.343 Gigabytes.... huge.
Overstated by roughly an order of magnitude. 32760^2 = 1,073,217,600. 1,073,217,600 * 32 bits = 34,342,963,200 bits. 34,342,963,200 bits / 8 bits per byte = 4,292,870,400 bytes. 4,292,870,400 bytes / 1024^3 = 3.998 GB. Manifold can happily cope with that. 60000 x 70000 pixels (of type single) -> 15.64 GB. That's quite big (for now). There are some hard limits in Manifold (for now). The main one is the limit on the size of a virtual table for an image or a surface, which is currently 4 GB. That means we can address a surface of 32760 x 32760 pixels in Manifold SQL if it uses single-precision values, but not if it uses double-precision. And for a 60000 x 70000 pixel surface, SQL will be available only if the surface uses 8-bit integer values. (Manifold has allowed table components to exceed 4 GB since version 8.0.19, but if I'm not mistaken the relaxation did not extend to virtual tables. There are apparently some similar limits on the size of query tables per se, which danb and I looked at last year, without getting to the bottom of the matter.) If you need to manipulate really large surfaces, use a Surface Transform rather than SQL. Surface Transforms can cope with very large sizes (I don't know if there is an effective limit). Is there a link between the 4 GB limit on virtual tables, and the hard 32760 x 32760 pixel limit Chris has discovered for surface enlargement via the clipboard? Maybe Manifold uses the same data structures for abstracting a surface in both cases?
|