Resolution&Rendering-I understand the approach to render in a second step. This is definitely an option to keep for extreme sizes and with the nice settings like correct aspect ratio and using cpu+gpu combined!
But:
I want to work with the current view! When I go for beautiful single orbits, I want to use exactly the ones that I see building up.
At some point I press "pause" and THIS is exactly the image to export without having to take a screenshot.
So how to get huge images on a limited monitor?
I like woronois approach with
BuddhabrotCL: You set the rendersize at the beginning and then let it run, you see the result in realtime..
if image size is larger than your screen resolution, you get horizontal and vertical scrollbars. then you just export that full view. I was able to render 10800*10800 sized images in realtime and just stop when I like the result. Downside is that I'm not able to get an overview of the whole image.
Depending on the resolution I sometimes have 5-6 instances open in parallel and let some of them calculate 2-3 days. Then I choose the ones that are nice and rotate/crop the interesting area. If I have enough 'resolution' left I scale things down for aa. (Just to give you an idea how a workflow can look like.)
the best from both worlds would be adding image zoom. (not to confuse with fractal depth zoom)
-full view (shrinks the image to fit your program window.
-original size (original resolution with scrollbars if image size is larger than window size)
-optional1: your own zoom by fader
-optional2: real full view of the whole image without any program interface, like f11 in browser
Rendering in the preview window should not really be necessary?
I really don't want two ways of doing the same thing, because that makes the code unmaintainable.
The preview window also currently uses dynamic resolution and because of the way I implemented it, it would not allow for high resolutions without requiring insane amounts of memory.
Usually, the preview should be clear enough after a few seconds for you to decide whether you want to do a full render of it.
And the offline render should not differ too much from the preview, unless you have chosen too few iterations so the render has not converged yet.
Also the renderer is currently not really meant to support very long orbits, but I could try to find a way to speed up rendering of long orbits (because you are talking about rendering for multiple days!?)
-for the regular rendering you already implemented: why not update the view in realtime while rendering?
I assume by "regular rendering" you mean offline rendering.
It has no preview, because that makes it faster (the data of each tile is only transferred once it's done) and because you don't need a preview because it's too late to change something.
Also, because the image can be computed on multiple OpenCL devices at once, the preview could be inconsistent.
But what I can do is add a "Show Preview" button to the offline renderer and a "Stop" function, which will allow you to save the render as it currently is without aborting.
Colors
1. I wish I could change colors after (realtime) rendering. (and not only for the points calculated after I pressed "apply settings".
You will see completely different details in the current render.
Of course I could do this in photoshop, but it's much nicer to have this in the "idea-finding-stage" within your renderer.
It works for the RGB-Method in BuddhabrotCL, so there is a way to achieve this.
2. If you are able to implement 1, please also give us the "Color transform" options from the render/save image dialog in the realtime color settings
The Gain Fader should also wwork when the rendering is paused.
What BuddhabrotCL does is swizzling the RGB channels, that's all.
And I don't really want to build a full color correction pipeline into Buddhabrot Mag.
And I can fix the gain fader, yes.
(And the preview currently always uses exponential color transform, but I guess I can make it selectable as well.)
Please tell me if I should stop or slow down bombarding you with wishes and ideas.. I don't want you to loose the fun in this project through what could be perceived as nagging.
I'm just excited about this great new tool!
I don't mind suggestions.
Could you elaborate what exactly "warmup" is doing?
Sometimes when you are zoomed in and apply new options, it can seemingly stop rendering or be very slow, because it lost it's list of orbits it previously had.
So warmup basically zooms out and back in to help it find good orbits again.