Fractalforums

If you could, I think it might be worthwhile to restrict the recomputing of an image when the iteration count is increased to only that area which was previously above the count limit.

Basically, I can spend a couple of hours computing an image only to find that the small minibrot in the center is not well defined because the iteration count was too low.  If I increase the iteration count, the only area which should require updating would be the minibrot area, IE pixels which previously exceeded the max count.  This should be able to be accomplished in a matter of minutes, but I find that the entire image is recomputed although 99% of it will be unchanged from the previous computation.  If only the previous "above the count limit" area could be recomputed, this could save considerable of time.

Thanks for any consideration.

Marshall

Yes this is on the TODO list already, and has been for some time... bumping the priority a bit thanks to your request.

Technically, one obstacle is that the iterations dialog controls more than just iteration count, so it's hard to know whether the iteration count is the only thing that has changed when confirming the dialog.  But apart from that it shouldn't be too hard, just mark the iteration count pixels as glitched, increase the iteration count limit, and add a new reference in the center of the glitch (which will recalculate the mini).

One other thing on the TODO list relating to sharp minis is "boundary shrinking" - instead of say doubling iteration count and recalculate the whole mini, do a flood fill recalculating pixels next to escaped pixels.  This should make large-in-view minis faster to calculate, but the logic involved to organize computations is not so easy.

But apart from that it shouldn't be too hard, just mark the iteration count pixels as glitched, increase the iteration count limit, and add a new reference in the center of the glitch (which will recalculate the mini).

Of course this is not always just one.  Although the mini's in these black ellipses might be too small to see, the ellipses can be enlarged or shrunk with the count, to the point where there appears nothing but "noise" inside.  Having the count "too low" actually gives a much more pleasing picture.

Marshall

 

the answer to noise is not a black censorship box.  the answer to noise is moar supersample! 
actually the other half of the answer is to also adjust the coloring to better fit the range of values for a particular location (there is probably a more technical term for this)
heres a few example renders showing what i mean, with no supersampling vs 8x supersampling, and a noisier range of colors vs something that better(ish) fits the location..

I can try those, but the point is that I am trying to get something pleasing to the eye for posting on a fractal group, not necessarily something which is an accurate depiction of the math.  I think in this case the black ovals are more striking and pleasing to the eye then filling with anything else.  In fact I posted a similar image for this month's contest here, where I used a low max count to get the look I wanted.

BTW, I am having a bit of a problem finding where the supersampling is set.

Marshall

that is of course totally fine if you choose to under-iterate for your own personal artistic preference.  still, either way, properly sampling your images will always be more pleasing to the eye than not.

Here is the image with a high iteration count.  I am still unable to find how to do a moar oversample though.

Marshall

I am still unable to find how to do a moar oversample though

lol 

i havent used kalles in a while, i dont think there is oversampling functionality built in or if claude has/intends to implement it.  in that case you would render at a resolution some multiple of your target resolution, then downscale it in another program.  for example, if you rendered at 4000x4000 and downscaled to 1000x1000 that would give you an effective 4x oversampling

Here is the image with a high iteration count.  I am still unable to find how to do a moar oversample though.

Marshall

From the KF manual:
## Action
  - **Set image size**

    Set the size of the internal image size. If this is larger than the window
    size, an anti-alias effect is achieved


ah yeah i remember trying that in KF a few years ago, and it didnt seem to do anything, at least not in the render window.  it would take longer so it was internally doing more points but what was shown in the render window stayed of the same quality.  maybe it only does something good if you render to a file?  and/or maybe that functionality has been updated since?  either way downscaling in another program is still likely to give a better result than whatever cheesy thing KF might be doing internally 

i havent used kalles in a while, i dont think there is oversampling functionality built in or if claude has/intends to implement it.

Implementing supersampling would be a big change that would break some features:
* numeric distance estimation and slope colouring, which depend on neighbouring values
* being able to change the colouring after calculations have been performed

So it's not a high priority, for now the workaround of rendering bigger and downscaling later may be acceptable?  The advantage of built-in supersampling is mainly memory usage, afaict.

whatever cheesy thing KF might be doing internally

KF uses the StretchDIBits() Windows API call, iirc - I tried to find where it was implemented in WINE but got lost in a maze of redirecting interface function pointers..

that is of course totally fine if you choose to under-iterate for your own personal artistic preference

agreed, though it may be theoretically nicer if KF's colouring methods were better and you could choose to adjust the iteration count threshold for this colouring after the calculations have been performed.

KF's colouring is really a weak point, I think.  I might work on a small side-project that uses GLSL shaders to colourize KFB map files, at some point - but without it integrated into the navigation UI it wouldn't be much fun to use... maybe something for KF3, though for that version bump I'd want to get the OpenCL experiments working too...

From the KF manual:

Code: [Select]

## Action
  - **Set image size**

    Set the size of the internal image size. If this is larger than the window
    size, an anti-alias effect is achieved


Ok,, I did this, and although it is a little less grainy, with an 8X, it really is not much different.  The low iteration count ovals are much more aesthetic artistically.

Marshall

Ok,, I did this, and although it is a little less grainy, with an 8X, it really is not much different.  The low iteration count ovals are much more aesthetic artistically.

Marshall

A colormap of 1024 random colors is unlikely to produce a good result, so you have to go in the colormap editing dialogue.
For dense locations like this I start off rendering at say 4X oversampling and select a half-decent colormap. Then render off-line at 10X resolution, save TIFF and kfb. I then reduce to target resolution in photoshop. If aliasing occurs (as in your example) I apply a 5pixel Gaussian blur (1/2 the oversamping) before downsampling. There is free software to do the same. If that still gives artifacts you have to rerender with jitter turned on. If I don't like the result I open the saved kfb and try to find a better colormap and repeat.

Some examples of your location attached, just using the default KF13.9 colormap rendered at 8X and saved as jpg in KF at target, and saving full jpg and applying Gaussian blur 4 pixels wide and downsampling.

Wow, that is cool. I definitely need to dig some into this. 

BTW, how did you get the co-ordinates?

Marshall