In article <1180206185.3182.1.camel@localhost.localdomain>, Edwin <edwin@bathysphere.org> writes:
On Tue, 2007-05-22 at 22:44 -0600, Richard wrote:
In article <000f01c79cf1$65f0cdc0$1402a8c0@eyx2>, "Edwin Young" <edwin@bathysphere.org> writes:
While you're at it, why not just go straight to 16-bit or floating-point?
Because that's a far more invasive change to the code.
I can imagine. Like I said, it's just a thought. Maybe you could create a color_t typedef or something to make it easier down the line.
Its worse than that; if a typedef was all that was needed, I'd gladly do that. However, all the code that manipulates colors directly assumes they are BYTEs.
Do you have a URL for the specification of OpenEXR? I've never heard of it before.
http://www.openexr.com/documentation.html
To be honest, actually outputting fractals to that is almost certainly overkill and useful only for bragging rights. The only fractal-related program I know which supports it is Fyre (http://fyre.navi.cx/).
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. -- "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/>