
Python implementation of wavelet rasterization - specular
https://github.com/ufoym/wavelet-rasterization
======
kastnerkyle
If anyone is interested in a beginner introduction to what wavelets are
generally, and how they are used - I did a blog post a while back using numpy:
[http://kastnerkyle.github.io/posts/wavelets/](http://kastnerkyle.github.io/posts/wavelets/)

~~~
ska
I see the "how [some of them] can be used [in numpy]" part there, it looks
pretty good for that purpose.

However, it really isn't much of an introduction to what wavelets are, or what
they might be good for in general and why.

~~~
chestervonwinch
I agree. Write a prequel GP! :)

------
onion2k
Wavelets were a big thing when I was at university (circa 1997). They were
touted to be a giant leap in image compression along with fractals.
Interesting to see people are still exploring that area of maths; much of the
predicted technology never took off.

~~~
kragen
Well, and in fact the wavelet-based JPEG-2000 standard does produce better
visual quality at smaller file size than the DFT-based JPEG standard.
JPEG-2000 compressors haven't been as broadly adopted, probably because
they're slower. I'm not sure if that's because of wavelets, because of
unoptimized implementations of JPEG-2000, or because some other aspect of the
JPEG-2000 standard makes it more computationally intensive. There's further
discussion at
[https://lobste.rs/s/oxuu1k/jpeg_2000_the_better_alternative_...](https://lobste.rs/s/oxuu1k/jpeg_2000_the_better_alternative_to_jpeg_that_never_made_it_big).

~~~
mistercow
It's probably slower because of the wavelets.

You'll often hear that wavelets are faster than Fourier based methods, because
the DWT is O(n) while FFT is O(n log(n)), but that doesn't hold up when the
FFT window is a fixed size (as in the case of JPEG). Since JPEG uses a window
size of 8px, the "log n" is 3, whereas JPEG 2000 uses a wavelet with 8
coefficients. So it's basically O(n) in both cases, with a much larger
constant factor on JPEG 2000's DWT.

~~~
kragen
Doesn't JPEG use a window size of 8×8 = 64px, with a sort of boustrophedon
diagonal path through those 64 pixels?

~~~
mistercow
Yes to the first part, but both the DWT and DCT are linearly separable, so you
can compare their performance by just looking at one dimension.

As for the zigzag path, it doesn't run through the 64 pixels, but rather
through the 64 coefficients that come out of the DCT. That's part of the
coding stage, which is a separate animal. That said, JPEG's coding scheme is
way simpler, and probably way faster than JPEG 2000's, so that might also have
something to do with the perf difference.

My overall impression of JPEG 2000 is that it seems like they started with
"wavelets can surely be used to achieve superior image compression to JPEG",
and then made whatever sacrifices were necessary, in terms of implementation
complexity and computational resources, to bear out that premise. You could
make similar sacrifices and beat the hell out of JPEG with a DCT-based codec
too (e.g. with larger windows, overlapping transforms, better psychovisual
models etc.)

~~~
kragen
I see! That makes more sense. Thank you for explaining?

A linearly-separated 2D 8×8 DFT should involve 6 butterflies per pixel, no?
And I guess a 2D DWT with 8 coefficients results in 16 multiply-accumulates
per pixel? Does it depend on the order of the DWT?

~~~
mistercow
> Does it depend on the order of the DWT?

Not sure what you mean by the order of the DWT. Do you mean how deep you
transform (how many levels of the transform you apply), or the number of taps
on the filter?

It definitely depends on the number of taps on the filter.

IIRC, as for the depth DWT down to one scale coefficient is still O(N)
(although there's another constant factor multiplied on beyond the number of
filter coefficients). Even if you only do two levels, I believe you only cut
the time in half, and you lose a lot of opportunity for compression if you do.
I'm not sure what depth JPEG 2000 goes to, but it's probably more than three,
so I think you can largely discount any perf gains there.

~~~
kragen
I meant the depth. Thank you!

------
jacobolus
Here’s the paper, which I haven’t read yet.
[http://faculty.cse.tamu.edu/schaefer/research/wavelet_raster...](http://faculty.cse.tamu.edu/schaefer/research/wavelet_rasterization.pdf)

There’s a large literature of rasterization techniques. Does anyone have
insight into when this one would be useful?

Here are some other recent papers:

[http://research.microsoft.com/en-
us/um/people/cloop/LoopBlin...](http://research.microsoft.com/en-
us/um/people/cloop/LoopBlinn05.pdf)
[http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html](http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html)

[http://w3.impa.br/~diego/projects/GanEtAl14/](http://w3.impa.br/~diego/projects/GanEtAl14/)

[https://developer.nvidia.com/gpu-accelerated-path-
rendering](https://developer.nvidia.com/gpu-accelerated-path-rendering)

------
leni536
Apparently this technique calculates the _exact_ pixel values from box
filtering the "infinite" resolution polygons. I wonder if the same technique
can be applied for circular or elliptical arcs.

What are the most common rasterizer algorithms currently in use by
vectorgraphics software? I mean pdf readers, postscript renderers, font
renderers, etc...

~~~
muizelaar
Most rasterizers typically use some kind of super-sampling scanline
conversion:
[http://lists.cairographics.org/archives/cairo/2007-July/0110...](http://lists.cairographics.org/archives/cairo/2007-July/011092.html)

------
astazangasta
Why does Python code always look like assembly code? Is this just laziness on
the coder's part or is Python inherently unreadable?

~~~
sp332
I've always found Python to be pretty readable. Are you just talking about the
matrix math, or the rest?

~~~
astazangasta
All of it. The 40 line methods with no self documenting variables, order or
sense.

~~~
sp332
It's probably transliterated right out of a math textbook into Python.

------
stuaxo
This looks like a perfect thing to try various python optimisations/optimisers
on - numba, pypy, cython and shedskin to name 4.

~~~
jacobolus
This is the kind of massively parallelizable problem you want to put on the
GPU. Python is mostly a good choice for a readable-code demonstration version.

~~~
e12e
So, pyopencl makes five?

[https://github.com/pyopencl/pyopencl](https://github.com/pyopencl/pyopencl)

