Does Image Magick have Tonemapping operators?

[fmw42]

I particularly like and am interested in the Gradient and Laplacian approaches. I have worked with pyramids before and will have to review those papers in more detail. As you can see I already have a number of scripts that attempt to bring detail out of very dark portions of images, such as shadows, in particular the scripts: redist, retinex, duotonemap (all global processing) and space (local processing). At some point I hope that these script can be made into IM functions, though I suspect that will have to wait until IM 7. The (laplacian) pyramid approach is similar to the wavelet concept and perhaps there already are some wavelet-based tonemapping approaches (though the laplacian is easier to generate right now in IM as there are no wavelet functions, yet in IM).

Anthony -- I have many more such examples in my scripts example pages for those scripts listed above. And you are welcome to use any of those.

Anthony -- The sun highlights are not really in the original image if you display it without setting the colorspace to sRGB or by setting it to simple RGB. So my original image that I started with using sRGB was brightened from the original. It may actually be better to keep the bright areas as they were and try to bring out details in the dark areas as in Larson 97 Histogram Adjustment method. I suspect, one should really be doing this processing in HDRI mode, if the .hdr file really supports a very large dynamic range; otherwise, HDRI is not needed and would be overkill.


Anthony/Magick -- Perhaps this whole discussion would be more appropriately moved at this point to the Digital Image Processing section.

[anthony]

Moveign to Digital Image processing... DONE... leaving a pointer..

[fmw42]

A new script I am working on:

Duotonemap2:
duotonemap2 -m both -s 0,18 -h 18,100 -r 3 IMG_3133And8more_640x480_setsrgb.png IMG_3133And8more_640x480_setsrgb_duotonemap2_both_s0x18_h18x100_r3.jpg


duotonemap2 -m both -s 0,18 -h 40,100 -r 3 IMG_3133And8more_640x480_setsrgb.png IMG_3133And8more_640x480_setsrgb_duotonemap2_both_s0x18_h40x100_r3.jpg

[ssilk]

Fred, just some quick feedback on your latest results, they're really cool looking.

You'll notice though that you're starting to get halos around sharp edges, most noticeable around the Ahmad tea tin on the left. From a tonemapping standpoint, these are considered a defect and a common pitfall of tonemapping and lot of existing tonemappers aim to remove them. If you look at the results I posted earlier from various tonemappers, you'll notice the Fattal02 result has a much milder version of the same defect. Also, overall the latest results would definitely fall into the "surreal" category of tonemappers as opposed to photorealistic. That's not necessarily a bad thing, these are just common classifications and I thought you'd be interested.

If you want to know more about halos, check out Reinhard's Color Imaging book I mentioned ealier.

In case you're continuing your tonemapping experiments, I've uploaded a high res version of the image you've been working with, along with two more I took at the same time. I've put hdr and exr formats up for all three, the exr files are about 1/2 the size with PIZ compression but not sure how easily IM reads them. Also, heads up, the dynamic range of the full-res versions is a fair bit higher. The small sample we've been looking at so far in this thread is about 5,000:1. This may affect your results. I've listed the dynamic ranges with the file links below.

High-res images:

Image 1 (from earlier posts in this thread), DR - 23,000:1
http://www.site.uottawa.ca/~ssilk083/to ... d8more.hdr (21MB)
http://www.site.uottawa.ca/~ssilk083/to ... d8more.exr (12MB)

Image 2 (same scene as image 1, different exposure setting, bigger DR), DR - 97,000:1
http://www.site.uottawa.ca/~ssilk083/to ... d8more.hdr (21MB)
http://www.site.uottawa.ca/~ssilk083/to ... d8more.exr (14MB)

Image 3 (similar scene, but directly backlit by sunset), DR - 105,000:1
http://www.site.uottawa.ca/~ssilk083/to ... d8more.hdr (21MB)
http://www.site.uottawa.ca/~ssilk083/to ... d8more.exr (13MB)

[fmw42]

You'll notice though that you're starting to get halos around sharp edges, most noticeable around the Ahmad tea tin on the left. From a tonemapping standpoint, these are considered a defect and a common pitfall of tonemapping and lot of existing tonemappers aim to remove them.

Simon,

Yes, I was aware of the haloing. Unfortunately, it is an issue with the method I used and I tried to minimize it. It can be made a bit less, but then other artifacts start to appear. However, I found that this method had the best dynamic range restoration than any of the others I had used. The haloing is due to the masking to separate the shadows from the highlights and the use of some feathering to minimize sharp cutoffs of the mask. My experience has been that any method that is spatially adaptive or separates highlights from shadows is prone to this kind of artifact; whereas the more global techniques may not suffer that issue, but then do not work quite as well with the large dynamic range.

IM can only handle the EXR 16-bit floating-point format, called "half", which is why I used the .hdr file you provided earlier.

I may try to use your newer images for some tests, but I suspect I will have to recompile to HDRI mode and I don't know if IM supports 32-but .hdr files. I know IM will handle PFM and TIFF in 32-bit formats. I also have not really tested any of my scripts of this kind in HDRI mode and don't know what pitfalls I might run into. For example the Histogram-based scripts are limited to 256 bins and I have not tried to expand that to 16-bit (65535 bin) histograms even in Q8. So that may be limiting my redist quality.

Anyway, thanks for the uploads of the higher resolution versions.

Fred

[fmw42]

Can you provide 640x480 versions of these files without changing the dynamic range? Your images are several thousand pixels on a side and very large for testing. I am not sure if I reduce them in non-hdri IM, whether they will then lose the high dynamic range.

[ssilk]

Here they are. In some cases, resizing them can reduce the dynamic range somewhat if the high range is due to just a few isolated extreme high-value or low-value pixels that get lost/ averaged out in downsampling. I've listed the dynamic range of each below, and re-posted the original image you were working with (Image 1).

And to answer your question about EXR images, I believe EXR only support half-float (16-bit floating point), that's part of the reason it's more compact. I'm able to read/write EXR files fine with IM, I actually had more trouble with .hdr.

640x480 versions:

Image 1
DR: 3,500:1
http://www.site.uottawa.ca/~ssilk083/to ... 40x480.hdr

Image 2
DR: 40,000:1
http://www.site.uottawa.ca/~ssilk083/to ... 40x480.hdr

Image 3
DR: 98,000:1
http://www.site.uottawa.ca/~ssilk083/to ... 40x480.hdr

[fmw42]

thanks

Are you running in IM HDRI mode -- what do you get from

convert -version

Are the .hdr images 32-bit resolution? What do you get from the verbose info for those images in terms of min,max values? My question still has to do with how you get that kind of dynamic range if not using HDRI. If you are running Q32, that is 32-bit integer. If Q16, then 16-bit integer. Thus 98000:1 would not be supported by Q16 without compression of dynamic range. I am really a novice with regard to HDR image formats. I have only run HDRI in Q16 mode and not used Q32 (non-hdri) much at all.

My understanding is that IM was only able to deal with EXR "half" format 16-bit floats and not 32-bit floats. Perhaps things have changed?

[ssilk]

When I run convert -version I get "Features: HDRI" so I guess HDRI mode is on. It's probably a good idea and necessary to get the full range of the data initially. If you think about what you're doing in tonemapping, you're trying to take a floating-point valued image that can easily have 6+ orders of magnitude (1,000,000:1 or more), and compress it into an 8-bit so it can be displayed on a monitor. If you have IM in a mode that can't handle those large floats to start with, you're probably clipping a lot of the range of the image before you even start trying to process it.

As far as what format the images are in once they're loaded in IM, I don't know. All I've done with IM is actual programming with Magick++, and very limited at that. I haven't done any scripting. I believe once they're loaded, they're 32-bit floats for me, or maybe 64-bit.

As far as how the images are stored, the EXRs use a 16-bit float. Radiance (.hdr) achieves a large compression over PFMs by using the same 8-bit exponent for all three color channels for a given pixel, and three 8-bit mantissas, for a total of 32bpp.

What do you get from the verbose info for those images in terms of min,max values?

If you can clarify how to check this on a Windows system, I'll check.

Hope this helps.

[fmw42]

what do you get from

convert -version

is it Q8 HDRI, Q16 HDRI or Q32 HDRI

To check the min,max

convert image.hdr -verbose info:


In my Q16 (non-hdri), the hdri images show min max of 0, 65535. But I don't know if that is real or converted down from 32-bit by using IM Q16 non-hdri.

Anyway, I used Q16 (non-hdri) and processed your first two high res images.

duotonemap2 -m both -s 0,18 -h 18,100 -r 3 -c IMG_3133And8more.hdr IMG_3133And8more_both_s0x18_h18x100_r3_c.jpg
http://www.fmwconcepts.com/misc_tests/t ... 0_r3_c.jpg


duotonemap2 -m both -s 0,7 -h 0,100 -r 3 -c IMG_3124And8more.hdr IMG_3124And8more_duotonemap_both_s0x7_h0x100_r3_c.jpg
http://www.fmwconcepts.com/misc_tests/t ... 0_r3_c.jpg


duotonemap2 -m both -s 0,7 -h 0,80 -r 3 -c IMG_3124And8more.hdr IMG_3124And8more_duotonemap_both_s0x7_h0x80_r3_c.jpg
http://www.fmwconcepts.com/misc_tests/t ... 0_r3_c.jpg

Once I know what Qlevel you are using, I can recompile IM and try again in HDRI.

[ssilk]

When I run "convert -version", I just get "HDRI", there's no specific bit-depth. When I try "convert IMG_3133And8more_640x480.hdr -verbose" I just get an error; can you clarify what other arguments that command needs.

I also tried the following code:

Code: Select all

#include<Magick++.h>
#include <iostream>
using namespace Magick;
using namespace std;

int main(){

	Image my_image, my_pfm;
	
	my_image.read("IMG_3256And8more_640x480.exr");
	my_image.write("copy_IMG_3256And8more_640x480.exr");
	
	cout << "Depth: " << my_image.depth() << endl;
	cout << "Type: " << my_image.type() << endl;
	cout << "Quality: " << my_image.quality() << endl;

	cin.get();
	return 0;
}

And the output is:

Depth: 16
Type: 7
Quality: 0

Not sure if any of that helps. The copy of the image created by the code is identical and still have over 100,000:1 dynamic range so obviously it's not being stored internally as a 16-bit int. There's a run-down on the HDR capabilities of at the link below that might clarify some of the stuff we've been discussing.

http://www.imagemagick.org/Usage/basics/#hdri

[fmw42]

When I run "convert -version", I just get "HDRI"

Something is wrong. Are you running it from the command line? When I run from the command line, I get:


convert -version
Version: ImageMagick 6.6.9-9 2011-05-15 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features:

or

identify -version
Version: ImageMagick 6.6.9-9 2011-05-15 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features:


If I had HDRI on, then under Features: it would say HDRI.

When I try "convert IMG_3133And8more_640x480.hdr -verbose" I just get an error; can you clarify what other arguments that command needs.

You are likely getting an error because you left off info:. So try

convert IMG_3133And8more_640x480.hdr -verbose info:

or

identify -verbose IMG_3133And8more_640x480.hdr

[ssilk]

OK, Sorry, I didn't notice that Q16 part. I was just looking at features.

C:\ImageMagick-6.6.7\VisualMagick\bin>convert -version
Version: ImageMagick 6.6.7-1 2011-01-07 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2011 ImageMagick Studio LLC
Features: HDRI


"convert IMG_3133And8more_640x480.hdr -verbose info:" and "identify -verbose IMG_3133And8more_640x480.hdr" both give me the following, which appears to be an error:

C:\ImageMagick-6.6.7\VisualMagick\bin>convert IMG_3133And8more_640x480.hdr -verb
ose
Magick: `%s' (%d) ra_ppm -g 1.0 "C:/Users/Simon/AppData/Local/Temp/magick-KP_3N7
LP" "C:/Users/Simon/AppData/Local/Temp/magick-omJu846j" @ error/utility.c/System
Command/2093.
Magick: Delegate failed `ra_ppm -g 1.0 "%i" "%o"' @ error/delegate.c/InvokeDeleg
ate/1061.
Magick: unable to open image `C:/Users/Simon/AppData/Local/Temp/magick-YuW7_h6a'
: No such file or directory @ error/blob.c/OpenBlob/2584.
Magick: unable to open module file `C:\Users\Simon\.magick\IM_MOD_RL_RAD_.dll':
No such file or directory @ warning/module.c/GetMagickModulePath/813.
Magick: unable to open file `C:/Users/Simon/AppData/Local/Temp/magick-YuW7_h6a':
No such file or directory @ error/constitute.c/ReadImage/571.
Magick: missing an image filename `-verbose' @ error/convert.c/ConvertImageComma
nd/2949.

[fmw42]

C:\ImageMagick-6.6.7\VisualMagick\bin>convert IMG_3133And8more_640x480.hdr -verb
ose
Magick: `%s' (%d) ra_ppm -g 1.0 "C:/Users/Simon/AppData/Local/Temp/magick-KP_3N7
...

It appears that you forgot the info: above.

C:\ImageMagick-6.6.7\VisualMagick\bin>convert IMG_3133And8more_640x480.hdr -verb
ose info:

Otherwise, possibly a bug in your version of IM or something with the images. I got reasonable results in Q16 non-hdri, but it just said 16 bits( min-max 0-65535). That may be correct for those images, but without the HDRI, it is constrained to integers rather than floats.

I will change over to Q16 HDRI mode and check out the verbose info for your images when I get some time, perhaps tomorrow or over the weekend.

[rnbc]

Answering the original post: as mentioned, there is already a set of tools, under the name PFSTools (pfstmo, etc...) to deal with HDR images.

It would be impossible to properly implement some of those tonemapping operators in ImageMagick because they rely on absolute luminance values. Either you would have to assume some kind of static mapping into luminance or otherwise. The infrastructure is not there...

Also, why reinvent the wheel? PFSTools interfaces quite nicely with ImageMagic. Just use the HDRI enabled version and openexr file format to interface between them, or something alike. It's even possible to build an entire pipeline to generate and process HDRs from raws and deliver nice looking finished images using dcraw + imagemagick + pfscalibration + pfstools + pfstmo.