Gerald K. Dobiasovsky wrote:
Roger Alexander wrote:
On my Christmas wish list-a utility to convert Fractint's 16 bit .pot files to a high color depth format like say png or tga. While the continuous potential coloring method overcomes some of the limitations of the 256 color limit of the gif format the proprietary .POT file format is only recognized by Fractint. I can do a screen capture in DOSBox but I am limited to a resolution of 1024x768. Does anyone know of such a utility or workaround?
Roger, Fractint 16 bit .pot files are regular gif89a files. You can load them into any decent image viewer (if your favourite program balks, change the file extension from .pot to .gif).
They were invented by the Stone Soup Group guys to replace the 16 bit .tga format used before for rendering smoother-than-ordinary-gif height fields. (To check this out, calculate and save a continuous potential image of i.e. the whole Mandelbrot set , but with "16 bit values" disabled, then produce a 3d transformation with lighting using that gif file - you'll get ugly steps in the landscape, because there are only 256 height values in the source.)
As of the format: They are, as said above, gif89a files, but with double width lines. A continuous potential fractal (with 16 bit values enabled), calculated in, say, size MxN will end up as 2MxN gif file with the ".pot" extension. Each line's first M pixels will contain the same info as a continuous potential calculation with 16-bit disabled (a single byte representing the palette table number, with the same number also being used as a height value in a 3d transform), the second M pixels (bytes) do represent the refinement values for the heights of the first M pixels in a 3d transform (they won't have any influence on the color).
The raw height data of pixel X (1 <= X <= M) of any line (before being scaled, rotated, shifted according to user input on the 3d transform input screens) in Fractint will be: pixel(X) + pixel(X + M)/256.
So, there *is* 16 bit information contained in a .pot file, but not in the form of directly-to-use 16 bit color. One way is not to interpolate height values, but color values. After all, pixel(X) is an index into the palette table, too, and we can interpolate between the color it points to and the next color after it, like this:
f = pixel(X + M)/256 r = r(pixel(X))*(1.0 - f) + r(pixel(X)+1)*f g = g(pixel(X))*(1.0 - f) + g(pixel(X)+1)*f b = b(pixel(X))*(1.0 - f) + b(pixel(X)+1)*f
In fact, I have written a small command line utility ~10 years ago doing just that (reading a 16-bit .pot and outputting an uncrompressed 24-bit .tga with interpolated colors).
The problem is, it is written and compiled in DOS 16-bit QuickC 2.5, with no regards to portability and probably full of Microsoftisms. The gif decoder is by Steven A. Bennet, the same originally used (with modifications) by Fractint. Plus, my memory of it (simple as the program is in principle) is very hazy.
Should anyone be interested despite this, I'll gladly send it - exe and/or source (refusing any responsibilities, of course).
Release both - EXE and source. Then perhaps someone can migrate it from it's MS roots to something much more portable. -- David gnome@hawaii.rr.com authenticity, honesty, community