|
|
|
|
|
|
||
|
Department of Applied Mathematics and Theoretical Physics |
|
|
|
|
|
|
| University of Cambridge > DAMTP > Waves Group > People > Ed Brambley |
|
These are some modifications I made to the HDR tonemapping operations in PfsTmo and the related Graphical User Interface QtPfsGui. The modifications are primarily to the Mantiuk tonemapping, and I am indebted to Rafal Mantiuk for coming up with this amazing tonemapping in the first place, and for the original code. These modifications have been incorporated into PfsTmo from version 1.2 onwards, and will probably be incorporated into QtPfsGui after its next release. I recommend you use these official and maintained versions, rather than the ones listed below. The details below are liable to go out of date! Here is an example of the output from the modified tonemapping:
About the modificationsThese modifications get round some problems with the Mantiuk operator not converging (it didn't tell you previously when this happened), and, when the original version did converged, the new version gets there significantly quicker. It also adds dual-core (and quad-core, etc) support to the Mantiuk operator, and gives added flexibility to the contrast equalization option within the Mantiuk operator. The Mantiuk operator also used to give diagonal lines across images. This was fixed in v1.9.0 of qtpfsgui, but (as of December 2007) hasn't been fixed in pfstmo v1.1. This new version includes the fix. It also fixes another major bug that hadn't previously been fixed that, at least for me, was giving a yellow cast to the final results. There are also small changes to the Fattal operator that may or may not speed things up. These changes are summarized below, below which are some technical details. Finally, there's another pfs tool, pfsequalize, that I've found useful. See details of that at the bottom. Modified contrast equalizationThe new Mantiuk operator requires a contrast scaling, even in contrast equalization mode. In qtpfsgui this is the same contrast scaling slider as in contrast scaling mode, just with the contrast equalization tick box checked. In pfstmo_mantiuk06, it's the -e <num> option. The original behaviour had a scaling of 1, but there's no special reason it should be this. I find larger values give more contrasty and fantasy-looking images, such as the image above. Sometimes, large values of this number need alterations to the convergence parameters, as noted below. ConvergenceThe Mantiuk central engine (for want of a better word) keeps going until it gets an answer close enough to the correct one that it doesn't make much difference, or until it's tried for long enough. The original version, in easy cases, kept going for too long, and in hard cases, gave up too easily. The new one (I think) does better, and there are several options in pfstmo_mantiuk06 to tell it what you want it to do. qtpfsgui just does something sensible. When using pfstmo_mantiuk06 with the -v option (which I'd recommend), or when looking at the command line when running qtpfsgui, there's a percentage complete reported. This starts at 0%, and when it gets to 100% it's converged as much as it wanted to. Sometimes it gets stuck for a while, and then keeps moving on. If it stops before it gets to 100% it'll tell you; in this case, have a look at the resulting image, as it may look ok. If it doesn't, try again with a higher itmax using the --itmax <num> option to pfstmo_mantiuk06. One change is that the new version of pfstmo_mantiuk06 uses a new engine, Conjugate Gradients, which is twice as fast as the old one, BiConjugate Gradients. CG is the default; you can get the old BCG method by using the --bcg command line option to pfstmo_mantiuk06. This is sometimes needed; if the percentage complete gets stuck for ages when using CG, try using BCG to see if that'll help. How close is good enough? By default, the new version uses a tolerance of 0.001, (10-3, or 1e-3 in computer speak). This is different to how it used to do it, which I think was unpredictable. Sometimes this tolerance isn't low enough, and if it were allowed to carry on it would get a significantly different image. In this case, try using a smaller tolerance (0.00001, or 1e-5) and keep using a smaller and smaller value until the final image doesn't visibly change any more. One final thing on convergence; the new pfstmo_mantiuk06 has three different upsampling and downsampling operations: -i1 is the original, -i2 is faster and seems to give the same quality, and -i3 is slower and experimental. -i3 may also need a significantly smaller tolerance than the others to converge. -i2 is the recommended option, and is what qtpfsgui uses. Detailed list of changesChanges to Fattal tone mapping
Changes to Mantiuk tone mapping
PFS Histogram EqualizationThis short program performs a histogram equalization on the image it's given (download the source code below). It's designed to be used on a PFS stream after tonemapping. A saturation of 1 (the default) equalizes the histogram completely, which usually looks far too harsh (try it). A saturation of 0 does nothing. Typically, I quite like something in the range of 0.4 to 0.6, although it varies with the image. The tonemapped image on the top of the page was equalized with a saturation of 0.5, something like: pfsin input.pfs | pfstmo_mantiuk06 -e2 | pfsequalize -s0.5 | pfsout output.ppm ... although, in reality, I think the options to pfstmo_mantiuk06 were -e2 --itmax 2000 -i2 --bcg. Downloads
|
|
|
|
|
|
|
|
|
|