Gradient HDR compression

[Carlos Milovic]

I'm using DCT of one dimension, to the rows. Then, I'm making a matrix diagonalization process (not the whole matrix... it is tridiagonal, so I only need to store 2 rows). It is faster than a DCT2D solver, but still if got O(width^2) operations due that DCT.

[Carlos Milovic]

Here it is the module and solver (code only, I'll compile them for windows and linux x64 tomorrow).
I ended putting an extra parameter to the module, to use Neumann padding (extending the boundary values) or Dirichlet padding (zero values). The second one yields better results for low amounts, and the first is better for large amounts.
Take into consideration that the result may also be dependent of the orientation of the image. Don't ask me exactly why So, if you want to try different results, rotating is a good way to try new things.

I tested it with one astronomical image, and the results were awfull. I think that we'll need another way to build the mapping function (I have some ideas that I'll try tomorrow). For daylight images works like a charm.

Also, please note that in general best results are obtained with linear data.

[Carlos Milovic]

Forget about the previous module... this one is almost the final one. I fixed the color correction, and now works like a charm. It is so nice, that I even propose to include the procedure inside HDRWT Juan, take a look a it.

[georg.viehoever]

Wow, never expected to trigger so much activity with my humbe module....

Regarding FFTW: Yes, your price information is similar to what I heard. A good alternative is Intel MKL http://software.intel.com/en-us/articles/intel-mkl/ (comes at $399), which is usally even faster while supporting the same FFT interface, has much more useful stuff, and is available for all PI platforms.

Georg

[georg.viehoever]

Regarding FFT options:
- http://www.fftw.org/speed/ contains a quite impressive list of FFT implementations and related benchmarks
- http://www.ehu.es/sgi/ARCHIVOS/fft_benchmark.pdf some more
- http://www.uniclust.it/index.php/en/fft-benchmark-opteron-speed-results.html
- ...
Some are open source/free.

Georg

[Juan Conejero]

Yes, I know and have explored all of those links. After a lot of prospecting I finally chosen Kiss FFT to integrate it in PCL because it:

- Is released under a BSD license
- Is very efficient (not as fast as FFTW/MKL but sufficiently close; PI is not a pure signal processing system so FFTs are not so critical)
- Allows for FFTs of arbitrary (even) length
- Has a very small footprint
- Is very easy to integrate with larger projects.

Its only 'defect' is that it lacks a DCT implementation. I'm looking for a good DCT C/C++ implementation that allows us to integrate it with PCL and/or PI modules without having to mortgage my house or feeling guilty of something.

[Carlos Milovic]

DCTs can be computed from FFTs. I'll look for some clever ways to do that, modifying the current code. It can be done with a full FFT of the double size of the DCT, but there must be more efficient ways.

[Carlos Milovic]

Just to let you know that I uploaded a new module with my implementation, compiled for linux and windows, 64bits. See my thread on development modules.

[georg.viehoever]

More recent messages on this topic in http://pixinsight.com/forum/index.php?topic=3173.0
Older messages on this topic in http://pixinsight.com/forum/index.php?topic=2124.0