buddhi1980 / mandelbulber2

Official repository for Mandelbulber v2
GNU General Public License v3.0
893 stars 116 forks source link

Anti Aliasing problem #920

Closed Michas0206 closed 2 years ago

Michas0206 commented 2 years ago

Hi, yesterday I rendered an animation in higher quality, and after it finshed I found many images where it looks as if AA has not worked properly in some "blocks": Bildschirmfoto vom 2022-06-15 18-54-57 Bildschirmfoto vom 2022-06-15 18-56-15

I did some tests after I found this issue, but still have not found out what exactly could causing this, its the first time I recognized it in the last weeks. I found this with a dev-build of 2.27, some weeks old, but I did a fresh build yesterday and the issue is still visible.

OpenCL is on, and the position of these 'unhandled blocks' change if I change the 'job size multiplier'-value. InfoDock showed nothing useful to me related to this.

If you need my .fract-settings where this happens I can post them. If necessary I to more tests later today with other scenes/formulas.

AA was set to 5 samples and resolution 2560x1440 on a RTX 3080.

System information (version)
Detailed description

See images above, AA has not been applied in every block of images

Steps to reproduce

Not sure, I'll have to do more tests

buddhi1980 commented 2 years ago

I would need to have fract file to reproduce and diagnose this problem.

Michas0206 commented 2 years ago

I would need to have fract file to reproduce and diagnose this problem.

Sure, Job size multiplier was set to 32 and 16 when I am not wrong: Remake - P3-4.fract.zip

Michas0206 commented 2 years ago

I`ve found out that changing AA-samples to 9 makes no difference, also produces 'unhandled blocks' in the result here. Lowering the resolution by 1/2 also makes no difference, lowering the Job-size-multiplier to 1 made it good visible to me.

At least in this scene.

I have not seen this issue until now in other formulas / scenes, I am trying to check this now by creating a different scene with some contrast. Possibly its just not visible enough in other scenes? I am not sure, but I am trying to find out.

buddhi1980 commented 2 years ago

Hi, Your bug report is very precious and detailed. I just found the problem. The criteria to decide which tiles should be anti-aliased were not enough good. In the commit which will be published in a minutes there is used simple edge detection algorithm to determine initial conditions. Before change there was just used max contrast criteria.

buddhi1980 commented 2 years ago

Problem fixed in commit https://github.com/buddhi1980/mandelbulber2/commit/6effaa704ce1ba90ebbf5f25832f9ac8973cb1af

Michas0206 commented 2 years ago

Many thanks for fixing this so quickly, and yes, it really seems to be solved, it is currently running in the background and the first images look promising.

I was not aware that there are 'criteria to decide which tiles should be anti-aliased', I thought it is used on all 'blocks' all the time normally when activated. However, seems fine here now, many thanks!

buddhi1980 commented 2 years ago

Just to explain. On some of the blocks at certain size od anti-aliasing matrix there is not reasonable to apply anti-aliasing. The effect is not visible on the areas with no details and very low contrast, and it is very time consuming calculation. In this way works adaptive mode. It is a compromise between quality and computing time.