Mandel Machine

[Botond Kósa]

I'm finding a frustrating 'opportunity' with Mandel Machine (v1.1.3).
On large images 1680x1050 with high supersampling 4x4 the color offset slider seems set the previous slider position not the current.
If the slider is positioned in the middle and I make a big change sliding it all the way to the left it only shifts the palette on the rendered image slightly.
If I then slightly nudge the slider to the right, a big change to the images palette happens.
It seems the rendered image renders the previous position not the current.
This happens when nuding the offset slider, say I nudge the slider several times to the left.
I've overshot so now I nudge to the right, the image changes as if I had continued nudging to the left.
After another nudge right and the images changes as expected.
Always being one step behind makes it very hard to get the exact background colour, especially with my stripey palettes.
The workaround is to get the palette offset 'just so' with no supersampling before committing to a 8x8 supersample render.

Thanks Panzerboy, this will be fixed in the next release.

[youhn]

Maybe I found another glitch (which looks great, by the way!) :



I don't think those tree-like or river-like structures are supposed to be there. See attached file for location.

[ellarien]

Oddly enough, that looks fine with 2x2 or no supersampling.

[Botond Kósa]

These stripes are caused by the rounding errors in the stored iteration values. In the range of 50000 iterations, the granularity of the 32-bit float datatype is about 0.004, so neighboring pixels with a smaller difference can get the same value, and later they are identified as a flat blob. The only solution to this is to store the iteration values in double precision. This is one of the old technical debts in the code that I will have to correct in an upcoming release. It will also increase the RAM consumption of the program by 50%.

[Botond Kósa]

A new version (1.1.4) is available with the following changes:

• NEW: Palette can be saved into .mmf files
• FIXED: No history item created when dragging the color density/offset sliders
• FIXED: When adjusting the color density/offset sliders, the image may be rendered with the old values

[Dinkydau]

The program still has stability problems here. It crashes a lot when I try to change parameters while a render is going on. It also crashes often when I try to abort a render.

Something that would greatly enhance exploring: faster zooming with the mouse wheel. Currently the render has to finish first before more zooming with the mouse wheel is allowed. I would even suggest to make the smooth transition animation a little shorter. Speed is key for exploring.

More ideas: pause button, and ability for the program to remember the last location where a file was loaded and where a file was saved.

[SeryZone]

The program still has stability problems here. It crashes a lot when I try to change parameters while a render is going on. It also crashes often when I try to abort a render.

Something that would greatly enhance exploring: faster zooming with the mouse wheel. Currently the render has to finish first before more zooming with the mouse wheel is allowed. I would even suggest to make the smooth transition animation a little shorter. Speed is key for exploring.

More ideas: pause button, and ability for the program to remember the last location where a file was loaded and where a file was saved.

When you click on 'computing image' when rendering going - you pause rendering. For about crashing you all right!!!

[R-TEAM]

Hi,

Must say - YES - An Hell of an Nice Fractal prg
(especialy on my 2 x Xeon Hexa Core Workstation )

But - i have already Java 64bit Last version installed.
Why dont use the prg this install ?
Dont need an additional Jave ... better use the (IF ! ) already installed Jave - as if the user update his jave - the prg benefit from this upgrade too

Regards
R-TEAM

[Botond Kósa]

The program still has stability problems here. It crashes a lot when I try to change parameters while a render is going on. It also crashes often when I try to abort a render.

Something that would greatly enhance exploring: faster zooming with the mouse wheel. Currently the render has to finish first before more zooming with the mouse wheel is allowed. I would even suggest to make the smooth transition animation a little shorter. Speed is key for exploring.

More ideas: pause button, and ability for the program to remember the last location where a file was loaded and where a file was saved.

The changing of parameters during rendering is completely untested, my fault. I always aborted before adjusting parameters (with the exception of mouse wheel / double click zooming).

Faster transitions and saved location in the history will be included in the next release. Pausing the computation is possible by left-clicking on the status bar, as SeryZone has also discovered. I forgot to mention this.

As you can see, Mandel Machine is just in the process of turning from a garage project to a proper product, and this is harder than I initially thought!

[Botond Kósa]

But - i have already Java 64bit Last version installed.
Why dont use the prg this install ?
Dont need an additional Jave ... better use the (IF ! ) already installed Jave - as if the user update his jave - the prg benefit from this upgrade too

Mandel Machine was originally a pure Java application. Back in those days, computing deep zoom images with high-precision fixed-point arithmetic was the most compute-intensive task (perturbation method was not yet implemented). I tried several JVMs and found that BEA's JRockit JVM was fastest at performing fixed-point arithmetic (up to 60 percent faster than Sun's HotSpot JVM), so I stuck with it throughout the years. After implementing the core routines in assembly, the speed of the JVM became less of a concern.

In the meantime, both BEA and Sun were acquired by Oracle so I will refer to their JVMs as JRockit and HotSpot, respectively.

When I was planning to publish the program I tested it with both JVMs. I found that it crashed very often when run with HotSpot JVM, so I had to include JRockit in the install package. The crashes were fixed with version 1.0.5, so there is no need to stick with JRockit anymore. The next release will be available without an embedded JVM as well.

[panzerboy]

A few palette related things I've noticed.
When loading a palette from an image the palette isn't applied immediately.
Another zoom or change of the palette sliders activates the new palette.

Palettes loaded from an image (PNG, JPEG, BMP) don't get saved into the mmf file.
This gives a differently coloured image when you reload it.
I can guess why this happens, loading from an image there is no rendering.palette line to save later on so the previous one is used.
Creating this line at save time would have to be done from the internal array which is million items?
Better to create the rendering.palette line when loading from an image, might slow that process down slightly.

Loading a mmf file that just contains palette information forces a recalculation.
I would like to apply different palettes to the final image and composite the different layers using GIMP.
If a mmf file doesn't have information from the image or location sections a recalculation needn't be done?

[simon.snake]

A few palette related things I've noticed.
When loading a palette from an image the palette isn't applied immediately.
Another zoom or change of the palette sliders activates the new palette.

Palettes loaded from an image (PNG, JPEG, BMP) don't get saved into the mmf file.
This gives a differently coloured image when you reload it.
I can guess why this happens, loading from an image there is no rendering.palette line to save later on so the previous one is used.
Creating this line at save time would have to be done from the internal array which is million items?
Better to create the rendering.palette line when loading from an image, might slow that process down slightly.

Loading a mmf file that just contains palette information forces a recalculation.
I would like to apply different palettes to the final image and composite the different layers using GIMP.
If a mmf file doesn't have information from the image or location sections a recalculation needn't be done?

Panzerboy, I feel your frustration with the palette issues.

I have been creating some nice images to use as palettes, but due to the fact that the palette doesn't seem to get saved into the .mmf file I find myself frequently having to load the bitmap and re-select the palette.

Can I be sure to get the line in the exact same place I had it before?  It's very difficult.

I agree that at the loading of a palette from an image is the ideal time to create the line that would be written to the .mmf file, otherwise saving those 1 million items later would be ludicrous - how would the program know at that point which palette entries were the 'key' entries and which were the 'interpolated' entries?

Also one other question.  Is the limit of 1,900 zooms able to be lifted?  I have hit that a few times while deep zooming (it's so fast nowadays I don't always realise I'm near the limit) and thought it was a bug until I reread this post!

[Botond Kósa]

The palette is saved as a sequence of key colors. When it is extracted from an image, the number of key colors is the length of the selector line in pixels, and they are evenly distributed into the 1M long palette array. The intermediate colors are interpolated.

Loading only rendering data (palette, color density & offset, etc.) from an mmf file shouldn't trigger a recalculation, so this is a bug. It will be fixed in the next release.

[Botond Kósa]

Also one other question.  Is the limit of 1,900 zooms able to be lifted?  I have hit that a few times while deep zooming (it's so fast nowadays I don't always realise I'm near the limit) and thought it was a bug until I reread this post!

Yes, zooming beyond 1900 (using long doubles) is one major new feature of the upcoming release. I've been working on it for several weeks now, and I had to refactor large parts of the code, so I need some more time to finish.

[simon.snake]

The palette is saved as a sequence of key colors.

I agree it should be, but here's a screen shot:



In this I opened Mandel Machine, loaded a palette which I have created (in Paint Shop Pro 5) and saved as a .png, set the palette (you can see it in the top right - lots of key colours), adjusted the IT colour density (which forces the new palette to be shown) and saved the mmf file, which I have then opened in Notepad (high tech. here!).  You can see that these are the only few steps in the history window.

You will clearly see the mmf file has only 5 key colours instead of the many it should have saved.  When I then open the file it still has the old palette.

Hope this small bug can be fixed soon as having to re-set the palette every time I load a location is a bit annoying, especially if I saved it looking a certain way and can't recreate this look exactly when loading the palette a second time.

Great program though, and thoroughly enjoying browsing.

I agree with one point that the scrolling in or out using the mouse wheel (which sometimes seems to go the wrong way, especially on zooming back out where it likes to continue zooming in for a bit before zooming out) is a bit too slow.  If this could be speeded up it would make the whole experience a bit more enjoyable.