Dynamic Kernel/Anti Aliasing, a difficult trade-off

[Wim.Koornneef]

Hello Forum,

Some time ago I compared all interpolators of Pano2VR 3 with the option "Dynamic Kernel/Anti Aliasing" enabled to find the best interpolator for small tiles.
I found a huge difference in both sharpness and file size between the interpolators, on top of the list with a large file size and sharpness are Lanczos3 and Blackman-Sinc (output is identical) and on the other end of the list is Cubic with a small file size and a fuzzy image.

On another thread on this forum (*) we discussed a bit about the reason for the difference in sharpness in the output of iPad panos and it turned out that the setting for "Dynamic Kernel/Anti Aliasing" was causing the difference.
(*) http://gardengnomesoftware.com/forum/vi ... 0&start=15

To get a better understanding I did a quick test and I compared the 2 interpolators at both ends of my list (Lanczos3 and Cubic) with the option "Dynamic Kernel/Anti Aliasing" enabled and disabled.
To my surprise the huge difference in filesize and sharpness as noticed in my first test is reduced a lot and the differences in image quality are much less visible.

http://www.dmmdh.nl/forum_images/compar ... e960px.png

The difference in sharpness between enabled and disabled "Dynamic Kernel/Anti Aliasing" option is easy to see but it is also clear that when the option is disabled jagged lines are introduced in the output, on the other hand, fine details are also much better.
Sharpening the tiles with enabled "Dynamic Kernel/Anti Aliasing" in a post process to get sharper images without jagged lines isn't a good workaround because the qualty really fast will be bad.

As it turns out it the choice for enabling or disabling the "Dynamic Kernel/Anti Aliasing" option is a trade-off between sharpness and jagged lines and it could be very well that a choice must be made based on the content, the scene, of the panorama.
I don't like such choices because it makes it very hard if not impossible to batch output panos, especially when the output is a mix of Flash and HtmlCss3 output.

IMO it would be best to have an "in between" option with less "Anti Aliasing" for small tiles to keep the images sharper, I don't know if this is possible but when it is I like to see it on the wish list.

Wim

[360Texas]

Ok Wim, I did look at your sharpening test page and saw that the Lancos 3 far right seemed to be the sharpest. What combination was your best selection ?

[Wim.Koornneef]

Hello Dave,

I wish I had a "best" selection but I have not

The differences between Cubic and Lanczos3 when the option Dynamic Kernel/Anti Aliasing is unchecked(disabled) is very small and for a nature pano both will do fine but when using the same setting for a pano shot in a scene with lots of buildings and details with repeating patterns (roof tiles, street stones, etc) then the output is often bad due to jagged lines, moire effects and shimmering.

When I have to make a choice for one setting then I go for Lanczos3 with Dynamic Kernal/Anti Aliasing enabled, apart from that it is not as sharp as I want it has no other issues.

Best,
Wim

[360Texas]

I can fully understand about Lanczos3 because it take time to process. Lanczos Lanczos2 Lanczos3 use increasingly complex algorithms to complete the sharpening.

Our Canon dSLR's jpegs use sharpening IN CAMERA. Photoshop Camera Raw Converter also uses sharpening algorithms. PTgui lets you choose a sharpening algorithm. Pano2VR also uses a sharpening selection type.

If you use Sharpening in all your workflow steps... LOLLLL your final image could possibly be over-sharpened.

[hum@no.id]

I do not see any Sharp, I see the horrible Aliasing ...
In pursuit of sharpness you can remove your AA filter from the sensor through the photo service... at your own risk and without a 100% guarantee for the successful tuning

It would be nice if Pano2VR is supported Lanczos5

[Wim.Koornneef]

......In pursuit of sharpness you can remove your AA filter from the sensor through the photo service.......

Hi Hum,

Don't you think your suggestion is a little drastic to tackle an issue that can be solved with software ?

Best Wim

[hum@no.id]

I think this are different principles. Source from the camera or software with "intensive care"... we eventually find stillborn B&W pixels, after the inter-pixel interpolation.

*about remodeling a sensor in the form of removing the AA filter: (again) rather it is a solution for fans in pursuit of sharpness ...

[Wim.Koornneef]

As discussed above when I output 960px tiles for HtmlCss3 pano with a normal sharped equirectangular then I get, depending the setting of the Dynamic Kernal/Anti Alias (DKAA) option, a good but unsharp image, or I get an image which "looks" sharp but has lots of artifacts.

After trying out several workarounds I found one that tackles the issue;

I use the same equirectangular I use for creating Flash panos with the same interpolator and DKAA option (=enabled),
Here it comes, instead of tiles of 960px I output tiles of 2880 px (my equis are large so large tiles are no issue).
In Photoshop I resize(*) the tiles from 2880 to 960px and save them (with a simple droplet I automate the job).
(*) For resizing I use the default Bicubic interpolator of Photoshop, apart from the resizing no sharpening or other postprocessing is done !

Here is a 100% crop of a tile that is output at 960px and one that output as 2880 px and then resized to 960px.
http://www.dmmdh.nl/forum_images/compar ... lesize.png

I circled just one detail but you can see the improved image quality all over in the resized tile.
I think you agree with me that the resized image is showing much more details without the nasty issues we get when the DKAA option is disabled.

Although this workaround at this moment "works" for me, and perhaps also for you, I hope for a better interpolator to come to avoid this workaround.

BTW, I have no doubt that (again) some aliasing is involved in the resized image but I don't care as long as the resized image shows more details. Keep in mind that any artifact is prone to see on large monitors but much less visible when viewed on a small iPad screen.

Best,
Wim

-------------
RECTIFICATION
-------------
I should have known better because I know that all tiles, regardless their size, are having a fixed overlap of 10 px to make an invisible blending of the tiles possible. A simple resize (*) of the tiles will give errors because the overlap of a resized tile is not 10 px anymore, I know this but in the process of trying to get a better quality it simply slipped my mind.
I therefore can not recommend the workaround, my apology to everyone that tried it.

(*) Without a much more complex workflow it is not possible to resize the tiles and keep a 10px overlap.

Despite that the simple workflow doesn't work the comparison is showing very well that details are better visible by using a different workflow so in this aspect my efforts were not totally useless.

Wim