Heat map with lots of events

[DrEvil]

http://imgur.com/golFzMo,8DIHKBf#0
http://imgur.com/golFzMo,8DIHKBf#1

In the first picture there are 2 identical events. In the second picture one of the events has been copy and pasted so that there are stacked events. You can see an effect on the stacked event, but the other event is static, which means I'm not getting the effect I'm looking for. The behavior suggests that the overlaid events are not being accumulated, more like just an overwrite, because if they were it should result in a reduction in intensity of the standalone event because the auto-level would normalize based on the max pixel value of the stacked values.

[fmw42]

The second image shows the accumulation effect, because the yellow center is wider. The other does not reduce in effect, because in one channel you have saturated colors so that among the 3 channels the min and max are unchanged, so -auto-level makes no further change.

[DrEvil]

The whole point of using the floating point texture is so the accumulation can't saturate and can increase to arbitrary values. Then the auto level normalizes the image of arbitrary values down and then the colorization step gives it a color.

The stacked values should accumulate to a double the value of the standalone which should effectively cause the standalone event to reduce down the color map range by like half intensity. I expect the stacked events to be at the saturation points after the remapping because they are the max values in the image. I'm just trying to figure out why the other event doesn't get reduced.

[DrEvil]

I think I haven't been clear enough on my intent for the floating point color use.

When I draw an event in a Grey scale radial falloff it is getting presumably a 0.0-1.0 color values across the channels. When I draw an additive event on top of that, I'm looking for the values to then additively be 1.0-2.0 range. I could have thousands of events that accumulate pixel values to arbitrarily high floating point values.

As I understand it, in the 2 event picture, the auto level would be colorizing based on a min and max value of 0.0 and 1.0. Seems to be fine. In the 2nd picture the leveling should be in the 0.0-2.0 range which should cause the lone event to move down the color scale in terms of its normalization against the larger max color value.

Which part of this isn't working how I am expecting? Does it not allow > 1.0 color values in the float texture? Is there some unexpected clamping going on here somewhere?

[fmw42]

I have not followed this that closely. But, are you running in HDRI mode? If not, then the gradient will already have values in the range of 0 to quantumrange (not zero to 1). The function -auto-level does not colorize. It just stretches the values between min and max to the range 0 to quantumrange. If the gradients you keep adding are already in the range 0 to quantumrange, then they will already be at full dynamic range, unless you are using HDRI compile of IM.

From the code below, if not using HDRI mode, your radial gradients are already at full dynamic range, since you left off any color values for them to use as min and max ranges. So it appears that you are adding two full dynamic range radial-gradients on top of each other. In non-hdri mode, IM will clamp at full dynamic range. Thus only the mid gray levels of the gradient add. The max values are at full white and won't add further.

I think for you to add radial-gradients you will need to use HDRI compile of IM. Also I think your -auto-level should be on the final heat map and not the clut image.

Code: Select all

@echo off

echo Blending Events into Accumulation Image
convert -depth 32 -define quantum:format=floating-point -size 1000x1000 xc:black @heatmap.inc heatmap.tif

echo Applying Colorization
convert heatmap.tif -auto-level ( ^
	-size 1x250 ^
	gradient:#004-#804 ^
	gradient:#804-#f00 ^
	gradient:#f00-#f80 ^
	gradient:#f80-#ff0 ^
	gradient:#ff0-#ffa ^
	-append ) -clut heatmap_coloured.png

pause

And here's my inc file

Code: Select all

( -size 100x100 radial-gradient:  ) -gravity center -geometry +300+300 -compose Plus -composite

( -size 100x100 radial-gradient:  ) -gravity center -geometry +180+80 -compose Plus -composite
( -size 100x100 radial-gradient:  ) -gravity center -geometry +180+80 -compose Plus -composite

The 2nd event is doubled to test the accumulation and leveling. The end result should be that the more you stack an event, you should see the intensity of other events diminish.

[snibgo]

As fmw says, your results are consistent with non-HDRI. What does "convert -version" show? Please paste the results here.

If it doesn't show HDRI, that's the problem. Without HDRI, IM pixels are integer only, and clamped in the range 0 to 65535 (assuming Q16). If you use non-HDRI you will have to reduce the values of each event so the sum doesn't exceed 65535.

With HDRI, the maximum pixel values are about 1e38. So if each event has a maximum of 65535, you can can have many billions of events without overflow, and "-auto-level" will reduce the range to 0-65535.

[DrEvil]

Thanks I'll look into that next. I was hoping the floating point mode would be enough to get me to an unclamped range, and also because it makes things easier later bc I hope to have variable weighting of events in their floating point value(implemented as variable value of inner radius of the gradient)

[snibgo]

The floating point build is known as "HDRI" (High Dynamic Range Images, or something). It's a different build, not a mode. A build is either HDRI with floating point, or integer and clamped to between zero and quantum.

[DrEvil]

Code: Select all

convert -version
Version: ImageMagick 6.8.8-2 Q16 x64 2014-01-09 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC Modules OpenMP
Delegates: bzlib cairo freetype jbig jng jp2 jpeg lcms lqr pangocairo png ps rsvg tiff webp xml zlib

I grabbed an hrdi version from an external link in another thread. I don't know why this isn't a version in the official downloads.

I thought I had it already, from this old post that showed up on google.

It's an old post but I guess 64 bit versions don't have hdri enabled anymore.
http://www.multipole.org/discourse-serv ... f=1&t=9647

[snibgo]

Sadly, the developers don't build a v6 HDRI Windows version.

If you don't mind bleeding edge, IM v7 alpha has HDRI. http://imagemagick.org/download/beta/ . It has no convert.exe. Use magick.exe instead.

The directory name is misleading; v7 is in alpha testing, not beta, and some parts don't work properly. But it works well enough for this application.

[DrEvil]

Thanks. I forgot to mention that upon using the hdri version I'm getting the results I need. I'm working on setting up a much larger test with real event data.

[DrEvil]

Grr. My next hurdle appears to be that it is choking on the size of my input file with the following error

convert.exe: UnableToConvertStringToARGV `Not enough space' @ fatal/string.c/StringToArgv/2046.

Some weird observations from testing the number of events.

My events file for this test is a little over 100,000 lines long. This particular example is dumping out position for a few thousand entities. Positional heat mapping is probably the worst case scenario as far as computation and number of events are concerned because it has so many events needed to track where people have been.

Despite the number of events, the file that contains them that I'm using as the @heatmap.inc is only about 10MB however there are some gigantic memory usage numbers going up with the count of events, so I'm guessing feeding the data in this way is doing more than just streaming in commands 1 by 1.

10,000 events - 500-572 MB of memory
20,000 events - 1,062 MB of memory
30,000 events - 1,552 MB of memory
35,000 events - 1,796 MB of memory
40,000+ events - convert.exe: UnableToConvertStringToARGV `Not enough space' @ fatal/string.c/StringToArgv/2046.

Any idea why the memory is ballooning up in this way? This probably isn't a 64 bit build, and presumably it would go further by using one, but I hope to run this on a web server in the future as well, and this type of memory usage is not going to be tolerable in that environment.

[snibgo]

I don't know what is eating memory. What version of the HDRI build are you using? "-debug" may offer clues. I suggest you try the same operation on a modern version to see if that also eats memory. (If the build isn't HDRI, the resulting image will be wrong, of course.)

[DrEvil]

It's a build I linked to above

Code: Select all

Version: ImageMagick 6.7.6-1 2012-03-17 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
Features:   HDRI

I'm not building the code, and have little interest in doing so. Maybe I'll try the alpha.

[DrEvil]

Is there some updated docs on the beta/alpha of version 7 ? I changed it from convert to magick and it's choking on the same commands that worked before.

Code: Select all

Blending Events into Accumulation Image
magick: unable to open image 'black': No such file or directory @ error/blob.c/O
penBlob/2635.
magick: unable to open module file 'C:\Users\DrEvil\.magick\IM_MOD_RL_XC_.dll':
No such file or directory @ warning/module.c/GetMagickModulePath/816.
magick: no decode delegate for this image format `black' @ error/constitute.c/Re
adImage/558.
Applying Colorization
magick: unable to open module file 'C:\Users\DrEvil\.magick\IM_MOD_RL_TIFF_.dll'
: No such file or directory @ warning/module.c/GetMagickModulePath/816.
magick: no decode delegate for this image format `heatmap.tif' @ error/constitut
e.c/ReadImage/558.

These dlls are in the C:\Program Files\ImageMagick-7.0.0-Q16\modules\coders where it installed to, so I'm not sure why it's not finding it(other than looking in the wrong place).