I think I've identified all the portions of the code that assumed 6-bit color channels. Are there any gotchas I should look out for in order to change the code to support 8-bit color channels? -- "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/>
While you're at it, why not just go straight to 16-bit or floating-point? In my own program I use a float in the range [0..1] for pretty much all intermediate color calculations, and only truncate to 8-bit when writing the final color out to the image. That will hopefully make it easier to support super-high-quality formats like OpenEXR in the future. Just a thought. ----- Original Message ----- From: "Richard" <legalize@xmission.com> To: <fractdev@mailman.xmission.com> Sent: Tuesday, May 22, 2007 8:43 PM Subject: [Fractdev] 6-bit to 8-bit color channels
I think I've identified all the portions of the code that assumed 6-bit color channels. Are there any gotchas I should look out for in order to change the code to support 8-bit color channels? -- "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/>
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
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. Currently the DAC is always passed around as an array of 256 entries of 3 bytes each. However, there is fudging around with the actual values that restricts them to the range 0-63 instead of 0-255. I never quite realize that fractint cheaped out on the 256 color colormap in this way until I started digging in the code.
In my own program I use a float in the range [0..1] for pretty much all intermediate color calculations, and only truncate to 8-bit when writing the final color out to the image. That will hopefully make it easier to support super-high-quality formats like OpenEXR in the future. Just a thought.
Do you have a URL for the specification of OpenEXR? I've never heard of it before. At some point all you describe is in the works. However, the code base as it stands is still a far cry from being easily extensible to support such a change. Its going to get there, but its still farther than closer. -- "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/>
I never quite realize that fractint cheaped out on the 256 color colormap in this way until I started digging in the code.
<LOL> Ahhh ... The VGA video DAC *has* just 6 bits per color channel. However Stone Soup has always been cheap, right about that! <g!> Seriously, we just saw no reason to keep around more bits than the video DAC could utilize. I presume this is moot if you are past the point of programming the DAC directly to rotate colors, as I'm sure you are. Tim
In article <46547CA0.13938.16EFC3@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Seriously, we just saw no reason to keep around more bits than the video DAC could utilize.
There wasn't any extra space required; it would have been better to keep the full 8-bits around everywhere until you wrote the dac, but what's done is done.
I presume this is moot if you are past the point of programming the DAC directly to rotate colors, as I'm sure you are.
The X11 code certainly doesn't diddle the DAC directly and the Windows code doesn't either. -- "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/>
Rich wrote:
There wasn't any extra space required; it would have been better to keep the full 8-bits around everywhere until you wrote the dac
Why? By keeping the array in memory exactly as it was in the DAC, the code to update the DAC was greatly simplified and very fast - a few lines of assembler. This strategy worked extraordinarily well under DOS. Computers were so slow then that we saved unnecessary work whenever we could. Not that it matters now at all, I'm just curious, because you stated it was "better" to keep eight bits without giving a reason. (Of course it would be better NOW, if one was keeping a palette around at all.) It's hard to look back at legacy code with perspective and understanding - it was a different world then. The bible on this subject is "Programmer's Guide to PC & PS/@ Video Systems" by Richard WIlton. The copyright is - get this -1987. I am amused that Wilton is seven years younger than I am, and was 34 when he wrote the book. We used it within a couple of years from when he wrote it. Wilton is still on the scrolling credit screen with a credit for "Tweaked" video modes. Tim
In article <4654876D.12176.411FEF@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Why?
Because regardless of whatever the DAC was doing in old-skool VGA land, the GIF file would retain all 8-bits of precision. The WinFract and xfractint code would have retained all 8-bits of precision. The remaining code in fractint that does computation on color values would have retained all 8-bits of precision. The speed excuse just doesn't wash with me; we're talking right shifting the BYTE by 2 bits before you store it. This is not anything that's going to tax even an 80286. Never mind the fact that eventually VGA drivers caught up to the normal world of graphics and had 8-bit channels in their DACs. How long have VGA cards had 8-bit channels in DACs? I'm willing to bet its been at least 10 years. -- "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/>
Rich wrote:
Because regardless of whatever the DAC was doing in old-skool VGA land, the GIF file would retain all 8-bits of precision. The WinFract and xfractint code would have retained all 8-bits of precision. The remaining code in fractint that does computation on color values would have retained all 8-bits of precision.
It comes down to what the purpose of the program fractint is, and we, the authors, decided it was not first and formost a palette manipulation program. Since no more than 6 bits can be displayed, storing more than six bits was moot.
Never mind the fact that eventually VGA drivers caught up to the normal world of graphics and had 8-bit channels in their DACs. How long have VGA cards had 8-bit channels in DACs? I'm willing to bet its been at least 10 years.
The answer (as far as I know, just did a cursory check) is VGA cards still have 6 bit DACs. Since modern cards focus on true color, there has been little vendor motivation to change legacy 256-color modes. And weird as it sounds, features like palette rotation preceded fractint's adoption of GIF. None, of this, of course, has any bearing on your question about any current downside of expanding from six bits to 8 in the Windows program. I don't know of any. Tim
In article <4654A405.11904.19BBC4@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Never mind the fact that eventually VGA drivers caught up to the normal world of graphics and had 8-bit channels in their DACs. How long have VGA cards had 8-bit channels in DACs? I'm willing to bet its been at least 10 years.
The answer (as far as I know, just did a cursory check) is VGA cards still have 6 bit DACs.
You're probably hanging up on the word "VGA". OK, fine. Forget I said "VGA". To me, "VGA" is like Kleenex. Its not a specific word referring to a specific brand of facial tissue. How long have display adapters in PCs had DAC channels wider than 6 bits? VBE 3 spec from 1998 has the ability to set 8-bits per DAC channel. That's indicating that this capability was already widespread enough to incorporate it into a VESA standard, supporting my assertion that this has been around for at least 10 years. -- "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/>
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.
Currently the DAC is always passed around as an array of 256 entries of 3 bytes each. However, there is fudging around with the actual values that restricts them to the range 0-63 instead of 0-255. I never quite realize that fractint cheaped out on the 256 color colormap in this way until I started digging in the code.
I noticed this when parsing the color strings in .par files, which have the same issue.
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/).
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/>
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.
Edwin wrote:
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.
I was part of the original PNG team and reserved the fRAc chunk for exactly that purpose - but never did anything about it because the memory demands of the PNG library exceeded what we could manage with Fractint. I actually went to a lot of trouble to make sure that Zlib and the PNG libraries could compile with the medium memory model, but to no avail. WIth the DOS limitation gone, now we could resume looking at the fRAc chunk for fractal data. Tim
In article <4658960E.29091.E723E@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
WIth the DOS limitation gone, now we could resume looking at the fRAc chunk for fractal data.
This is achievable in the near-term. Probably the most expedient thing to do is store the existing GIF datablocks as one big chunk marked fRAc? Did you spec out anything beyong the chunk name? I did a spike to add more image format support using ImageMagick, but it currently processes GIF extension blocks wrong so that fractint wouldn't work with it as is. Adding libpng support would be a more workable solution near-term. -- "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/>
Rich wrote:
Probably the most expedient thing to do is store the existing GIF datablocks as one big chunk marked fRAc?
No, that would defeat the whole concept of a PNG chunk. (I'll expond more on this later). We could do that with other chunks. Now that I think about it (it's been a long time) we did expend a lot of effort devising a way to preserve GIF extension blocks in PNG. That could be the short term fix.
Did you spec out anything beyong the chunk name?
No. Tim
In article <4658A673.3761.4E7C97@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Rich wrote:
Probably the most expedient thing to do is store the existing GIF datablocks as one big chunk marked fRAc?
No, that would defeat the whole concept of a PNG chunk. (I'll expond more on this later). We could do that with other chunks.
By "existing GIF datablocks" what I mean is all the extension chunks defined by fractint: there are like 4-5 of them. I guess I'll have to wait until you expound upon this later, though.
Now that I think about it (it's been a long time) we did expend a lot of effort devising a way to preserve GIF extension blocks in PNG. That could be the short term fix.
This is what I was talking about above.
Did you spec out anything beyong the chunk name?
No.
Beyond what is stored in the GIFs, why would PNG be any different? -- "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/>
Rich wrote:
I guess I'll have to wait until you expound upon this later, though.
The simple answer is that PNG has a very disciplined philosophy about official chunks. A lot of effort goes into defining them, then they don't change, rather new ones with a new name get created. Contrast this with fractint's use of a version. There is a lot of complex logic in fractint needed to accomodate changes in the data that happened over time based on the current version. This is what the PNG team wanted to avoid.
Beyond what is stored in the GIFs, why would PNG be any different?
Using the GIF extension block feature of PNG should be easy. This was added because our biggest concern was making migration from GIF to PNG easy. However sticking to the original GIF extensions in PNG will really hold us back. Storing data in PNGs is a pretty complex topic, harder than one might think. Greg Roelf's book "PNG, The Definitive Guide" is a big help. The chunks in question are gIFg and gIFx. The fact that fRAc is officially registered may be a big help eventually. Here's an interesting quote from Greg's book (in the paragraph on fRAc). "But for technical reasons relating to Fractint's 16 bit origins, PNG support was not added as planned, so design of the fRAc chunk was deferred pending a rewrite of the program as a 32-bit application" :-) Tim
In article <46595512.15348.22B4A4@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
Storing data in PNGs is a pretty complex topic, harder than one might think. Greg Roelf's book "PNG, The Definitive Guide" is a big help. The chunks in question are gIFg and gIFx.
In case anyone else wants to read this, the entire book is online: <http://www.libpng.org/pub/png/book/> -- "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/>
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/>
participants (4)
-
Edwin -
Edwin Young
-
Richard -
Tim Wegner