Hi Craig,
what I want is to transform, set a threshold what to keep and transform
back. That works. But the results differ depending on the levels
parameter to wavelet_transform. It seems to transform itself 'levels'
time, does that make any sense?
Ingo
about levels, it's in the transformation code itself, I'm at a loss with
the explanation, to be honest. Here's what is in the file:
/** Computes the discrete wavelet decomposition of a 2D image.
* This implementation uses a lifting implementation of the CDF(2,2)
wavelet,
* which is lossless for integer data. The transform is seperable in x
and y,
* but for performance reasons (cache), both are applied at essentially
the same
* time. The 2D transform splits the data into average and horizontal (HD),
* vertical (VD) and diagonal (DD) detail coefficients, and can then be
applied
* again to the resulting average coefficients.
* (as it is computed in place).
* @param[in] width Width of data in dst, has to be divisble by
2^(levels+1).
* @param[in] height Height of data in dst, has to be divisble by
2^(levels+1).
* @param[in] levels How often the transform is applied to the resulting
average
* coefficients. Largest valid value is wv_log2i(MIN(width, height)) - 2.
**/
void wavelet_transform(wv_pel *dst, const int width, const int height,
const int levels)
{
On 11/02/2015 02:23 PM, Craig DeForest wrote:
> That is terrific, Ingo!
>
> I’m afraid I’m just too busy to take responsibility for another module
> at the moment, but I’d be glad to help test if you want to check this
> into github and/or register it with PAUSE/CPAN.
>
> The bpp parameter controls lossy compression. The wavelet transform
> is only the first step in Vollmer’s code, which is a wavelet-based
> lossy compressor. The idea is to wavelet transform an image, then
> throw away both precision and also entire coefficients in the wavelet
> space, to achieve an approximate representation of the original image
> with much less storage space. The library does that by sorting the
> coefficients in a heuristic “importance” order, and keeping
> coefficients and precision until it reaches a certain number of bits
> per pixel of the original image. Everything else gets tossed from
> the compressed image.
>
> But I think you’re primarily interested in wavelet-transforming data,
> which involves writing a new binding to just the wavelet transform
> call in that library.
>
> Best,
> Craig
>
>
>
>
>
>> On Nov 2, 2015, at 12:41 PM, Ingo Schmid <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>
>> Hi Craig,
>>
>> I've added bindings to wavelet_transform and
>> inverse_wavelet_transform and thrown it into a rudimentary module. It
>> was a fairly straight forward task. I don't understand the bpp
>> parameter, what does it mean? 0 or 1 seems to work fine, most of the
>> time.
>>
>> I think some of the variables in the c code need to be changed to the
>> PDL index type, to be safe, although a cast of int should always
>> work, I guess. Looking at the compiler output, there are a lot of
>> warnings about that. I haven't tried threading at all, yet. Just for
>> testing purposes, there is a wv_identity, that can be safely removed,
>> if you like.
>>
>> make test ensures that the module loads, nothing more.
>>
>> Feel free to throw me off the authors list if you want to upload
>> eventually, I don't know if the Author field supports multiple names,
>> but then it's just a string.
>>
>> Thanks for the .pm file.
>>
>> Ingo
>>
>> On 10/27/2015 07:07 PM, Craig DeForest wrote:
>>> Here you go. It’s only 125k or so. I was mainly interested in
>>> wavelet compression, so those are the routines that are explicitly
>>> bound.
>>> But it’s a pretty short task to add the lines to get at the wavelet
>>> transform itself. Vollmer’s C code is included in the .pm file.
>>>
>>> Enjoy!
>>>
>>>
>>>
>>>
>>>
>>>> On Oct 27, 2015, at 11:40 AM, Craig DeForest
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> The FFTW3 library has DCTs in it, but the current PDL module
>>>> PDL::FFTW3 does not bind to them. You could add the bindings
>>>> yourself (with either my or Dima’s help if you want), or just use
>>>> the FFT itself. The latter is simple since you can just Fourier
>>>> transform a padded version of your data with the correct boundary
>>>> conditions.
>>>>
>>>> If you want wavelet stuff, I have a binding to Daniel Vollmer’s
>>>> wavelet compression library that I could send you. That has a
>>>> wavelet transform in it, and you can choose
>>>> your mother wavelet (I think it implements Haar andgentoo connect
>>>> android phone Morlet mother wavelets). I used the library for some
>>>> stuff, but never got around to making it publication quality.
>>>>
>>>> Cheers,
>>>> Craig
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> http://www.fftw.org/doc/1d-Real_002deven-DFTs-_0028DCTs_0029.html
>>>>
>>>>
>>>>> On Oct 27, 2015, at 10:37 AM, Ingo Schmid <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'd like to experiment with either discrete cosine transforms or
>>>>> wavelet transforms. Are there any implementations in PDL?
>>>>>
>>>>> Ingo
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> pdl-general mailing list
>>>>> [email protected]
>>>>> <mailto:[email protected]>
>>>>> https://lists.sourceforge.net/lists/listinfo/pdl-general
>>>>
>>>
>>
>> <PDL-Wavelet-0.001.tar.gz>
>
------------------------------------------------------------------------------
_______________________________________________
pdl-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pdl-general
