OK, I've got everything linking now on X11 with the exception of one unresolved symbol which I'm tracking down... This is just stubs on some routines on the X11 side, but at least I've gotten the driver back in sync. -- "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/>
Hi Richard, This is another of my silly questions... What is X11? Thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Wednesday, 31 January 2007 1:01 PM To: fractdev@mailman.xmission.com Subject: [Fractdev] x11 update OK, I've got everything linking now on X11 with the exception of one unresolved symbol which I'm tracking down... This is just stubs on some routines on the X11 side, but at least I've gotten the driver back in sync. -- "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 <00c901c744db$d1edd5e0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
This is another of my silly questions... What is X11?
Its the windowing system for most unix machines. <http://en.wikipedia.org/wiki/X11> -- "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/>
Many thanks Richard, Does X11 have any connection with the Windows version or are you doing 2 parallel developments? Thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Wednesday, 31 January 2007 1:10 PM To: Fractint developer's list Subject: Re: [Fractdev] x11 update In article <00c901c744db$d1edd5e0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
This is another of my silly questions... What is X11?
Its the windowing system for most unix machines. <http://en.wikipedia.org/wiki/X11> -- "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 <00db01c74501$41df3720$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Does X11 have any connection with the Windows version or are you doing 2 parallel developments?
The existing DOS code base has #ifdefs for WINFRACT and XFRACT. These indicate code for the Windows 3.11 version of the code and the Xfractint version of the code. So you modify the DOS code, then hack the #ifdef branch for WINFRACT to incorporate it into the Windows 3.11 version and then hack the #ifdef branch for XFRACT to incorporate it into the X11 version of the code. The branch looks at things differently. There is no DOS anymore on the branch. The WINFRACT code is there for reference (and theft of useful code!), but isn't the code path used on Windows -- instead the Win32 disk or GDI driver handles that. The XFRACT code will go the same way -- it will be an X11 driver that can be compiled into FractInt. (You could even compile an X11 driver on Windows -- there is no reason you can't have X11 client programs running on a Windows machine and displaying their graphics on a local or remote X server.) Once I've done the X11 driver for unix, then I'll have a better idea of which parts of the driver are really OS/platform considerations and which are driver considerations. There will probably be a little bit of cleanup in separating out what is "os" and what is driver. For instance, anything to do with times and dates or anything to do with the file system is an OS/platform issue and not a driver issue. There aren't many routines of this nature and they don't need to be dynamically switched like an output driver, so you can just compile one set of routines for an OS and link it in to resolve the issue. So if you wanted to port this code to a new machine, like the Mac, you would need to supply one set of "os" routines and a driver. -- "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/>
Hi Richard, Now that I have declared my ignorance :) I can continue toinvestigate what the team is doing and what the outcomes are expected to be.... So as I understand it, there are 4 streams: 1. Generic fractal code (hopefully machine independent and can make up a linkable library) 2. GUI stuff that is platform dependent such as X11, Windows or MAC 3. OS stuff like file systems, timers etc. 4. Drivers for screen, printers etc This is good as it helps to compartmentalise FRACTINT. It always seemed like an amorphous mass of globals and intertwined code and it was hard to separate out modules to work with. I hope that one day some generous soul can make up some documentation of the globals and what function they all perform. This is getting real exciting :) Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Wednesday, 31 January 2007 5:46 PM To: Fractint developer's list Subject: Re: [Fractdev] x11 update Once I've done the X11 driver for unix, then I'll have a better idea of which parts of the driver are really OS/platform considerations and which are driver considerations. There will probably be a little bit of cleanup in separating out what is "os" and what is driver. For instance, anything to do with times and dates or anything to do with the file system is an OS/platform issue and not a driver issue. There aren't many routines of this nature and they don't need to be dynamically switched like an output driver, so you can just compile one set of routines for an OS and link it in to resolve the issue. So if you wanted to port this code to a new machine, like the Mac, you would need to supply one set of "os" routines and a driver.
In article <00e201c7450b$78caec70$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
So as I understand it, there are 4 streams:
1. Generic fractal code (hopefully machine independent and can make up a linkable library)
Yep.
2. GUI stuff that is platform dependent such as X11, Windows or MAC
Yep.
3. OS stuff like file systems, timers etc.
Yep. Currently this is just separated out by which files you compile. There is a win32 folder and a unix folder that have the OS related stuff in it.
4. Drivers for screen, printers etc
Yeah, printing ... that's another thing that has to be updated for Win32, I think. Has anyone tried it?
This is good as it helps to compartmentalise FRACTINT. It always seemed like an amorphous mass of globals and intertwined code and it was hard to separate out modules to work with. I hope that one day some generous soul can make up some documentation of the globals and what function they all perform.
As for globals... I want to package them into structures relating to the various components. So there would be one structure that holds all the "engine" variables and variables relating solely to graphics output would be in the driver structure, and so-on. They would still be globals, but at least you could have confidence when looking at the engine code that you're looking at all the relevant quantities. Currently, I'm getting most familiar with the UI code, since that's where all the changes are in what I'm doing. There is the occasional bumbling around in other code, mostly to eliminate far-isms and things like extraseg. -- "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/>
Wow Richard, I am very pleased with your approach. This sort of separation and grouping will simplify the understanding of the code greatly. I have wanted to do the same in ManpWin, but just got overwhelmed by the extent of the work. Thanks for your sterling efforts. Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Thursday, 1 February 2007 2:32 AM To: Fractint developer's list Subject: Re: [Fractdev] x11 update As for globals... I want to package them into structures relating to the various components. So there would be one structure that holds all the "engine" variables and variables relating solely to graphics output would be in the driver structure, and so-on. They would still be globals, but at least you could have confidence when looking at the engine code that you're looking at all the relevant quantities. Currently, I'm getting most familiar with the UI code, since that's where all the changes are in what I'm doing. There is the occasional bumbling around in other code, mostly to eliminate far-isms and things like extraseg. -- "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 <010a01c7455e$650afdd0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Wow Richard,
I am very pleased with your approach. [...]
Thanks. Its not hard, just tedious and nearly impossible to do without Edit / Find in files... :-) -- "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/>
Hi Richard, Well soon ManpWin will be redundant because of the "new" FRACTINT :) But I would like to have a number of goodies added first once the group is ready to let me loose on the code :) G'donya matie, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Thursday, 1 February 2007 4:48 AM To: Fractint developer's list Subject: Re: [Fractdev] x11 update In article <010a01c7455e$650afdd0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Wow Richard,
I am very pleased with your approach. [...]
Thanks. Its not hard, just tedious and nearly impossible to do without Edit / Find in files... :-) -- "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 <010b01c74561$af631900$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
But I would like to have a number of goodies added first once the group is ready to let me loose on the code :)
I was wondering if you might be able to add the animation part, but with the restructuring coming soon, it might be more trouble than its worth to add now just to have it all changed around again. -- "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/>
Hi Richard, Here is the list of goodies That I have added to ManpWin. Let me know which ones can be done now and which need to wait. 1. 24 bit colour 2. Colour modification (requires GUI) 3. PNG files for true colour 4. Animation script generation and running - Zooming in on most fractals - Julia animation - following linear, circle and cardioid (main bulk of mandelbrot set) paths 5. A couple of silly plotting modes - horizontal blinds - vertical blinds 6. Real time 3d generation (this is not as good as FRACTINT, but it saves a lot of tedious mucking about in hyperspace with files) 7. Clipboard support 8. Undo (revert back to previous image) 9. Use of WM_COPYDATA message to allow other programs to send FRACTINT fractal data and to allow FRACTINT to send back an image etc (This allows for fractal processing without needing to restart FRACTINT every time). I have a client that uses this for fractal evolution. He sends me the fractal parameters and screen size etc and I return the image. He can scan through large populations fairly quickly. These all currently work in ManpWin. Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=telstra.com@mailman.xmission.com] On Behalf Of Richard Sent: Thursday, 1 February 2007 5:05 AM To: Fractint developer's list Subject: Re: [Fractdev] x11 update In article <010b01c74561$af631900$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
But I would like to have a number of goodies added first once the group is ready to let me loose on the code :)
I was wondering if you might be able to add the animation part, but with the restructuring coming soon, it might be more trouble than its worth to add now just to have it all changed around again. -- "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
Paul, Here are my comments on what needs to happen to fractint before we introduce these: In article <011101c74570$a0ef27b0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
1. 24 bit colour
Oooh, big change here, I think. There is already some truecolor support in fractint, but I think its just supporting truecolor *modes* and doesn't get much deeper than that. I'm not 100% sure about that. What I always wanted to do for FractInt was extend the formula mechanism so that you write a formula that computes a color (RGB *plus* alpha) from the iteration count and other orbit information. The next natural thing is to have layers that blend together after you've got alpha flying around.
2. Colour modification (requires GUI)
Can you explain what this is a little more? Is it your truecolor ramps?
3. PNG files for true colour
This would be easy to add right now and wouldn't be affected by any of the big changes coming.
4. Animation script generation and running - Zooming in on most fractals - Julia animation - following linear, circle and cardioid (main bulk of mandelbrot set) paths
This would be good to add after the code is re-structured and separated.
5. A couple of silly plotting modes - horizontal blinds - vertical blinds
:-) These might also be easy to add into the existing plotting code -- where solid guessing, boundary trace, etc., are done.
6. Real time 3d generation (this is not as good as FRACTINT, but it saves a lot of tedious mucking about in hyperspace with files)
For 3D, fractint needs OpenGL or Direct3D IMO. This is also a fairly big change. The current 3D code is doing all the rendering in software, which is OK, but won't ever take advantage of that hardware just itching to be used.
7. Clipboard support
Can you elaborate on this? We could probably accommodate this now as its just processing the appropriate window messages, I think.
8. Undo (revert back to previous image)
FractInt has this now in its history mechanism. (Ctrl+H or Ctrl+\, I can't remember offhand right now.)
9. Use of WM_COPYDATA message to allow other programs to send FRACTINT fractal data and to allow FRACTINT to send back an image etc (This allows for fractal processing without needing to restart FRACTINT every time). I have a client that uses this for fractal evolution. He sends me the fractal parameters and screen size etc and I return the image. He can scan through large populations fairly quickly.
IMO, this would be better implemented by separating the engine into a library or a COM object. Using windows messages for IPC is a kinda Windows 3.1 style, although it is easy to implement. COM, or even web services, would be a better mechanism for implementing this now. Once the engine is separated out, wrapping a COM object or a web service around it should be fairly easy. -- "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/>
Hi Richard, I'm not sure that it is all that difficult. 1. True colour: Instead of 256 colours, I generate a palette which stretches from 0 to maxiter which has calculated RGB triplets and these are plotted to memory instead of the normal palette. The palette only requires 6 integers to creat as opposed to 256 in a normal 256 colour palette. This part is real easy. I have it woking for 16 bit iteration values. So the iteration count is used to index through the rgb palette table as before. The only consequence is that it is not reversable and a set of RGB triplets may be duplicated in the table so an array of integers is needed for getpixel() I'm not sure what these "layers" are. 2. Colour modification (requires GUI) My true colour algorithm creates 3 sinusoidal values for each of the red, green and blue colour streams and makes a true colour palette. All that is required is the starting point in each sine wave and the frequency. I.e., 6 integers specify the true colour palette. These are spread out according to the max iteration count. The GUI is required to modify these 6 integers. It can be done manually, but that would be a lot of rework when we go full GUI. 7. Clipboard support Edit -> copy or control C and the clipboard contains the image being displayed 9. Use of WM_COPYDATA message This is a piece of cake to implement. The message passes a pointer to a slab of RAM and the size of the data being sent. It can be in any format. I use it to send text, binary data or images. A structure is used to hold these pointers. I have even sent device contexts. The code for all these exist in ManpWin already so it only becomes a merge issue. Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com] On Behalf Of Richard Sent: Thursday, 1 February 2007 8:20 AM To: Fractint developer's list Subject: Re: [Fractdev] x11 update Paul, Here are my comments on what needs to happen to fractint before we introduce these: In article <011101c74570$a0ef27b0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
1. 24 bit colour
Oooh, big change here, I think. There is already some truecolor support in fractint, but I think its just supporting truecolor *modes* and doesn't get much deeper than that. I'm not 100% sure about that. What I always wanted to do for FractInt was extend the formula mechanism so that you write a formula that computes a color (RGB *plus* alpha) from the iteration count and other orbit information. The next natural thing is to have layers that blend together after you've got alpha flying around.
2. Colour modification (requires GUI)
Can you explain what this is a little more? Is it your truecolor ramps?
3. PNG files for true colour
This would be easy to add right now and wouldn't be affected by any of the big changes coming.
4. Animation script generation and running - Zooming in on most fractals - Julia animation - following linear, circle and cardioid (main bulk
of mandelbrot set) paths
This would be good to add after the code is re-structured and separated.
5. A couple of silly plotting modes - horizontal blinds - vertical blinds
:-) These might also be easy to add into the existing plotting code -- where solid guessing, boundary trace, etc., are done.
6. Real time 3d generation (this is not as good as FRACTINT, but it saves a lot of tedious mucking about in hyperspace with files)
For 3D, fractint needs OpenGL or Direct3D IMO. This is also a fairly big change. The current 3D code is doing all the rendering in software, which is OK, but won't ever take advantage of that hardware just itching to be used.
7. Clipboard support
Can you elaborate on this? We could probably accommodate this now as its just processing the appropriate window messages, I think.
8. Undo (revert back to previous image)
FractInt has this now in its history mechanism. (Ctrl+H or Ctrl+\, I can't remember offhand right now.)
9. Use of WM_COPYDATA message to allow other programs to send FRACTINT fractal data and to allow FRACTINT to send back an image etc (This allows for fractal processing without needing to restart FRACTINT every time). I have a client that uses this for fractal evolution. He sends me the fractal parameters and screen size etc and I return the image. He can scan through large populations fairly quickly.
IMO, this would be better implemented by separating the engine into a library or a COM object. Using windows messages for IPC is a kinda Windows 3.1 style, although it is easy to implement. COM, or even web services, would be a better mechanism for implementing this now. Once the engine is separated out, wrapping a COM object or a web service around it should be fairly easy. -- "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 <012501c745b2$5ae809c0$0301a8c0@Production>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
I'm not sure that it is all that difficult.
1. True colour: [...]
Yes, I know what you mean by your implementation, but fractint has a lot of stuff that wants to treat the computed image as a set of color indices. All uses of the read routines will have to be code reviewed.
I'm not sure what these "layers" are.
Have you used photoshop or gimp (a freeware/opensource photoshop clone)? They have the ability for you to create image layers and the order in the layer stack defines how they are composited to create a final image. Think of it as sheets of acetate all stacked on top of each other with partial transparency per pixel in the layers allowing you to see through the layers on top to see the layers underneath.
2. Colour modification (requires GUI)
This would also require a change to the parameter handling code, the image read/write code and the batch generation code. That is, assuming that you want to persist the 6 parameters for the colormap instead of just the 256 entry table.
7. Clipboard support
Edit -> copy or control C and the clipboard contains the image being displayed
Right now, we have no menu... introducing one (and other Win32-isms) is somewhat problematic because of the hacky message loop code that's there right now. This is why some things will be easier once the UI code is separated from the engine and a native Win32 UI is in place. Remember, right now its still a DOS app in architecture.
9. Use of WM_COPYDATA message
This is a piece of cake to implement. The message passes a pointer to a slab of RAM and the size of the data being sent.
Again, this is IPC Win16 style. You can't pass pointers between Win32 applications and expect them to work -- the two processes don't share the same address space. Instead, you use COM or some other IPC mechanism. That is, unless I'm missing something about what you're saying. -- "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/>
Paul wrote:
1. True colour:
Instead of 256 colours, I generate a palette which stretches from 0 to maxiter which has calculated RGB triplets and these are plotted to memory instead of the normal palette. The palette only requires 6 integers to creat as opposed to 256 in a normal 256 colour palette. This part is real easy. I have it working for 16 bit iteration values. So the iteration count is used to index through the rgb palette table as before. The only consequence is that it is //// not reversable //// and a set of RGB triplets may be duplicated in the table so an array of integers is needed for getpixel()
Could the original iteration values of pixels be recovered from a True Color Fractint fractal image file at a later time by appending the six values and maxiter that generated the color triplets in an extension block appended to the image file? This would allow a different coloring to be applied to a True Color Fractint fractal image file at a later time. Perhaps this could be done as a stand alone application, perhaps as a Fractint feature. If a True Color Fractint fractal image file contained the six values and maxiter along with the image could you: - use the six values and maxiter to re-generate the table of original RGB triplets; - step through the file's pixels and look up the pixel's RGB triplet (various look-up methods come to mind) and thus - find the original iteration count of that pixel from the triplet's location in the RGB triplet table. - then use a different six values and the original maxiter to generate a new set of RGB triplets; - then build a new output image of RGB triplet pixels in the same way that the original .png image was created; - write out the newly colored output image to a file. It appears that the six values and maxiter could to be added to a .png file: http://en.wikipedia.org/wiki/Png says 'ancillary chunks' can be stored in a .png image: "Other image attributes that can be stored in PNG files include gamma values, background color, and textual metadata information." "tEXt can store text that can be represented in ISO 8859-1, with one name=value pair for each chunk." Paul, How are the six values and maxiter used to create the RGB triplets? Do you happen to know how other true color fractal programs create/specify their RGB triplets? - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # ######################### -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.410 / Virus Database: 268.17.18/662 - Release Date: 1/31/07
In article <MDBBJLBFBICIIEIHFBMEKEKBCPAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
Could the original iteration values of pixels be recovered from a True Color Fractint fractal image file at a later time by appending the six values and maxiter that generated the color triplets in an extension block appended to the image file?
This would be ideal (storing the iterations as well as the colors). How I would implement it: encode the iterations as a grayscale PNG image and insert that image as an extension chunk. Presumably you wouldn't always want this (it probably doubles the size of the image), so there would be some sort of optoin to turn it on and off. -- "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/>
Paul, why do you do just "color = sin(c * n + d)", instead of a full "color = a + b * sin (c * n + d)"? Hal Lane asked about retrieving iteration counts of an image by reconstructing it's original hi-color palette, based on those six palette parameters.. Rich suggested encoding iterations as a grayscale PNG image.. left aside that both of these solutions do have a problem with possible rgb triplets duplicities (as Paul already pointed out), you also loose the real iteration counts anyway, as everything is just wrapped at 2^16.. and still it's not the true true-color.. i know, i know, computing sines on the fly would be insane.. but you don't need to if.. if instead of all iterations per pixel you do all pixels per iteration - and all those that bail out get the same color.. if none does, you don't even need to know the color for such iteration count.. to be honest, this doesn't solve neither duplicit triplets, nor wrapping (happens at 2^31..) but you get it true true-color, you get an improved boundary-tracing-like image evolution and you get possibly infinite iterations.. at a cost of just a few MB of memory.. and those real iteration counts? why not to simply save them in a separate "raw" binary file? (gzipped..?) P.S.: Rich, please, stick somewhere in the roadmap an SVG and an HPGL support for L-systems and that infinite looping for escapetime fractals -- tell me which of these are blocked by your current development.. Thanks. /charlie/
In article <1575.2167-28109-1183218194-1170718611@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
left aside that both of these solutions do have a problem with possible rgb triplets duplicities (as Paul already pointed out), you also loose the real iteration counts anyway, as everything is just wrapped at 2^16..
32-bit iteration counts can be stored in PNG easily, which is the max of what fractint can handle. (Do we need iteration counts larger than 2^32?) -- "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 <1575.2167-28109-1183218194-1170718611@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
and those real iteration counts? why not to simply save them in a separate "raw" binary file? (gzipped..?)
I think PNG would actually do better at compressing them than gzip. But yeah, it doesn't really matter *how* you store them since an extension chunk is just a blob of binary data.
P.S.: Rich, please, stick somewhere in the roadmap an SVG and an HPGL support for L-systems
Hrm. I just killed printer support, so HPGL doesn't really make sense. SVG would be a good 'save' option so you can convert to other vector formats from there.
and that infinite looping for escapetime fractals -- tell me which of these are blocked by your current development.. Thanks.
You lost me with "infinite looping for escapetime fractals". Can you elaborate? -- "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:
32-bit iteration counts can be stored in PNG easily, which is the max of what fractint can handle. (Do we need iteration counts larger than 2^32?)
I think PNG would actually do better at compressing them than gzip. But yeah, it doesn't really matter *how* you store them since an extension chunk is just a blob of binary data.
well, isn't a regular grayscale up to a 16 bit depth? i thought you were talking about something like "phantom image" with usual api constraints.. while now it seems you meant some custom data being appended.. of course it's better when it's packed together with the visual representation.. anyway, a raw output (a sort of a dump) would be also of a use for postprocessing.. with infinite iterations (more comes bellow) it's easy to get over 2^32..
P.S.: Rich, please, stick somewhere in the roadmap an SVG and an HPGL support for L-systems
Hrm. I just killed printer support, so HPGL doesn't really make sense. SVG would be a good 'save' option so you can convert to other vector formats from there.
SVG: or edit it in Inkscape SVG editor just or view it with a web browser.. HPGL: i consider it also a save option, it's a sort of non-XML-SVG, some vector editors are also able to load it, and you can send it to the printer manually..
and that infinite looping for escapetime fractals -- tell me which of these are blocked by your current development.. Thanks.
You lost me with "infinite looping for escapetime fractals". Can you elaborate?
infinite iterations approach just iterates the whole plane at once, at each step coloring those pixels that actually bailed out (it usualy forms continuous regions, somewhat like boundary tracing).. and it never stops iterating, unless it has colored the whole plane.. (attracted pixels and periodic cycles are considered to be colored with inside) ..thus after a while, just a few pixels near the comlpex borders remain active and undecided and you can wait to see if they finally turn inside or outside, or you can stop the calculation.. you just need to keep the actual state (i.e. Z_n) and an activity flag (can be bit-packed) of each pixel.. /charlie/
In article <1584.2176-29302-820979663-1170721827@seznam.cz>, =?us-ascii?Q?charlie=20chernohorsky?= <endlessoblivion@seznam.cz> writes:
I think PNG would actually do better at compressing them than gzip. But yeah, it doesn't really matter *how* you store them since an extension chunk is just a blob of binary data.
well, isn't a regular grayscale up to a 16 bit depth? i thought you were talk ing about something like "phantom image" with usual api constraints.. while now it seems you meant some custom data being appended.. of course it's better when it's packed together with the visual representation.. anyway, a raw outp ut (a sort of a dump) would be also of a use for postprocessing..
There are two things here. The image and the iteration counts. Both PNG and GIF image formats have extension chunks (there's one registered for fractint, but its not been specced out according to Tim). I'm saying the iteration counts would compress well as a PNG image because PNG recognizes the spatial locality of pixels while zip does not. So you can encode the iteration counts as a PNG image and stick that in an extension block designed to hold iteration counts.
with infinite iterations (more comes bellow) it's easy to get over 2^32..
OK, I see what you mean now about infinite iterations and I'd already considered that as something that's desirable before. And yeah, with deep zooms (especially arbitrary precision zooms) you could easily get over 2^32. The question is -- is it worth having a multiple precision 'int' to store the iteration counts then? I think yes for parfiles, but its less clear if we're talking about saving them with the image.
Hrm. I just killed printer support, so HPGL doesn't really make sense. SVG would be a good 'save' option so you can convert to other vector formats from there.
SVG: or edit it in Inkscape SVG editor just or view it with a web browser.. HPGL: i consider it also a save option, it's a sort of non-XML-SVG, some vector editors are also able to load it, and you can send it to the printer manually..
When things stabilize (i.e. plumbing changes are done), adding new save formats should be easy. It would be pretty easy to add them right now, but I'm reluctant to divert my plumbing activity into new features until the plumbing is done. -- "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)
-
charlie chernohorsky -
Hal Lane -
Paul -
Richard