Decompress quadtree image

Started by
6 comments, last by JoeJ 8 years, 1 month ago
[attachment=30618:quadtree image.jpg]

How can i turn a quadtree compressed image (left) to smooth output (right).
I think this should be simple but all ideas i have for now are incomplete and complex.

The quadtree contains this data:
Single color per texel (also internal nodes, so 'mip map' data is available)
left / right / top / down neighbour pointers for current level
4 pointers to the parent level (to the 4 larger texels surrounding any smaller texel)

Any ideas welcome smile.png
Advertisement

checker board and floyd? steinberg? error diffusion tell me that you have to take more neighbors into account. Bilinear filtering for textures. When that works, apply on tree, top down.

From an image processing standpoint you should be able to use a gradient technique. https://en.wikipedia.org/wiki/Image_gradient I'd use a 3x3 kernel to start with and maybe combine a larger kernel to generate a gradient map. Post process the gradient to smooth it then apply the changes to the grayscale image. Using this you can even increase the resolution.

Thanks, i was looking at those things but now i realize what my real problem is:
If i add a second light spot to the image, one may end up in a coarse higher level and the other in a detailed low level.
Looking at the resulting image alone, there is no way seperate those and detect the different needs for smoothing as a postcrocess sad.png
There is no solution at all.

One nice thing about smoothing is that there is most often a solution. Even if it is not fully isotropic, most user will not notice. Do not let the tree confuse you. If you have time, play and train with the grid examples. Try to reuse this code for the tree.

Anyway I do not know why to quad-tree compress anyways. Is this for a sky with stars?

Oh, missed that one.

What i want is a compression for 16x16 or 8x8 enviroment maps per light map texel, so a lot of them.
But yes, quadtree compression seems a stupid idea now. Making it work is expensive and still requires too much space to beat alternatives.
(thought about texture space lighting so no need to decompress for every pixel.)
Will stick at 3 Band SH or 4x4 most probably.

Could just go with spherical guassians: http://blog.selfshadow.com/publications/s2015-shading-course/rad/s2015_pbs_rad_slides.pdf

Same exact purpose and idea as SH, but has better angular resolution and less artifacts.

Ah yes, i know that paper.

AFAI understand one can freely choose how much lobes to use, store them independently and they are not connected like the SH 'sum up basis functions' way.
But because the basis vector directions and lobe properties are hardcoded (they use 9), wouldn't this end up being similar to using a 3x3 enviroment map?

This topic is closed to new replies.

Advertisement