Feature request R1X1 "wavelet transform"

[hmaarrfk]

I think this "transformation" would be a great way to use JPEG2000 to create downsampled versions of masks where "averaging" or any kind of "pixel errors" would be unacceptable.

The idea is that:

1. Have an image (say 1024x1024).
2. Compress it with some options.
3. You want to access every 4th pixel (creating a 256x256) image.
4. This may result in aliasing, but this is desirable in this application since "in between" values are actually illegal.

[aous72]

Hi Mark,

This requires you to define your own wavelet transform, where the LL band does not involve any filtering, just downsampling, while the HL, LH, and HH subbands can employ the prediction step.
That is, to borrow the 5/3 wavelet, we need to define and use a 1/3 wavelet.
In this wavelet, we employ prediction to generate the high-frequency band, but no update to the low-frequency band.
The compression efficiency would suffer a bit.

JPEG2000 Part 2 supports user-defined wavelets. I do not support it and do not intend to do so.

The downsampling phase can be controlled by controlling XOsiz, YOsiz -- I need to think more about this, but now I think this is correct. By that I mean, when you perform downsampling, do you want the LL band to have (even,even), (even,odd), (odd,even), or (odd,odd) sample?

Cheers,
Aous.

[hmaarrfk]

Hi Aous,

Thank you for your thoughtful replies as always.

The 1/3 wavelet sounds interesting. If it is reversible then it sounds like a good candidate to help make use of the spatial redundancy.

I do not support it

I'm glad my reading of your code got me to the same conclusion.

and do not intend to do so.

Sorry to ask for elaboration. Does this mean:

1. I won't write code myself for it. But I would review PRs to add it.
2. I won't review PRs for this. Fork this if you like
3. Other

I need to think more about this

This is definitely more than I can ask, especially if it isn't on your roadmap!

[aous72]

Sorry to ask for elaboration. Does this mean:

1. I won't write code myself for it. But I would review PRs to add it.

2. I won't review PRs for this. Fork this if you like

3. Other

Option 1, but I worry that the review would take considerable effort.

I need to think more about this

I meant that the last statement required more thinking -- I think it is correct.

[hmaarrfk]

I have to say that i've spent much longer than I wanted to spend trying to dive into this.

My understanding is that:

where the LL band does not involve any filtering, just downsampling, while the HL, LH, and HH subbands can employ the prediction step.

makes this "not so JPEG2000 compliant" is that correct?

[aous72]

AFAIK, it is fully compatible with JPEG2000, but you need to use features/tools from Part 2 of the standard.
In Kakadu, you can specify the lifting steps -- in this case, the transform has one step only, a predict step.
To be honest, I never tried it; I am assuming it should work.

Cheers,
Aous.