Logo by Dinkydau - Contribute your own Logo!


it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Support us via Flattr FLATTR Link
Welcome, Guest. Please login or register. September 28, 2022, 08:37:20 PM

Login with username, password and session length

The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!

Pages: [1]   Go Down
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: Dynamic bucket size  (Read 1454 times)
0 Members and 1 Guest are viewing this topic.
« on: October 28, 2011, 12:08:56 PM »

I had an idea to reduce the memory usage involved in accumulating a histogram for rendering most IFS fractals. I've only really used Apophysis, so I don't know much about how other implementations handle buckets, but instead of just allocating buckets each of the same size for the entire histogram, one can divide the buffer into a series of blocks that each contain, say, 16-bit buckets, and then once any bucket in that block overflows, grow the entire block to contain 32-bit (or larger) buckets. This has hopefully-not-too-much speed overhead, but should reduce memory usage by a very significant amount, particularly for spacious systems. The block division also lends itself to locks for concurrent access to the histogram. Hopefully, the output of the system will be dense enough that growing a block due to one bucket overflowing will occur just before any one of a number of other near-full buckets in the same block.

Some other ideas that go along with this:
  • Split the buckets for each color component into separate blocks so that buckets grow as needed down to the color-channel level. Useful for gradients with little variation in hue.
  • Instead of actually "growing" buckets, allocate new blocks that are applied over top the existing, overflowed ones. With this idea, blocks can be arbitrarily shaped; even individual buckets can grow, if desired.

This system would likely have noticeable sacrifices in speed, especially if the color-split idea is used and the separate blocks are stored in different pages; an advanced user should have the option to choose this over a single bucket size across the histogram. The program might also perform a test render to attempt to determine whether this model might be desirable (or simply analyze the gradient in the case of the color-split idea).

Just a thought I had; dunno whether it's already been dreamed up.
Pages: [1]   Go Down
Jump to:  

Related Topics
Subject Started by Replies Views Last post
The simplicity of the unity of Dynamic Directed magnitudes Complex Numbers « 1 2 » jehovajah 21 4194 Last post May 01, 2016, 11:34:33 AM
by jehovajah
Paint bucket Images Showcase (Rate My Fractal) Dinkydau 4 816 Last post April 30, 2013, 06:12:21 AM
by Dinkydau
Render size vs. Animation size? Mandelbulb 3d Weber 3 1977 Last post September 20, 2013, 12:21:11 AM
by Sockratease
Render bucket size control for OpenCL Feature Requests lukesleftleg 6 964 Last post August 01, 2017, 12:05:38 PM
by lukesleftleg
zoom/bucket fill on my 2017 fractal art competiton submission Images Showcase (Rate My Fractal) 0xbeefc0ffee 0 550 Last post July 29, 2017, 09:26:42 PM
by 0xbeefc0ffee

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.173 seconds with 22 queries. (Pretty URLs adds 0.009s, 2q)