In article <1180225345.3182.12.camel@localhost.localdomain>, Edwin <edwin@bathysphere.org> writes:
On Sat, 2007-05-26 at 15:06 -0600, Richard wrote:
Edwin <edwin@bathysphere.org> writes:
Well this format looks like it would serve perfectly for some ideas that I have, so thanks for pointing it out to me.
For instance, this is a perfect format for storing the last_z orbit value for every pixel along with the iteration count and the color for pixels that are "done". It would support a more general resume operation than what we currently have, but would take extensive reworking to support.
If you want to store extra info like that, the PNG format also allows you to define arbitrary extra 'chunks' which other programs will ignore. Since that's much more widely supported, it might also be a good choice.
The thing is, I would just be re-implementing everything the OpenEXR format is doing inside the PNG chunk. For instance the store-on-disk scheme that I was discussing here recently would be ideally stored as OpenEXR images since it supports directly the browsing of super-large mipmapped images with floating-point pixels, which is exactly what you want for a scheme like that. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>