Live data from Hacker News

Python implementation of wavelet rasterization

github.com

11–20 of 24 posts

Re: Python implementation of wavelet rasterization

#11

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/

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.

Re: Python implementation of wavelet rasterization

#12
post #6

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.

They actually have made pretty big inroads into signal processing and functional analysis more generally, they just aren't a shiny new thing anymore.

They are quite interesting mathematical objects. I think their study was hindered somewhat for a while by functional analysts thinking they were too applied and engineers thinking they were too abstract.

Re: Python implementation of wavelet rasterization

#13
post #11

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/

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.

I agree. Write a prequel GP! :)

Re: Python implementation of wavelet rasterization

#15
post #14

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

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

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

Re: Python implementation of wavelet rasterization

#16
post #6

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.

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_....

Re: Python implementation of wavelet rasterization

#17

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

My experience is the opposite: Python code generally looks like executable pseudocode, the opposite extreme from assembly code. If you're finding this wavelet code unreadable, like I do, most likely it's because you don't understand the math it's implementing, like I don't.

Re: Python implementation of wavelet rasterization

#18
post #14

Earlier quoted context omitted.

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

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

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

Re: Python implementation of wavelet rasterization

#19
post #16
post #6

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.

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 inten…

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.

Re: Python implementation of wavelet rasterization

#20
post #16

Earlier quoted context omitted.

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 inten…

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…

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