Discuss digital image processing techniques and algorithms. We encourage its application to ImageMagick but you can discuss any software solutions here.
It gives quite a nice clut from dark blue to light yellow. It isn't quite perfect in the sense that #804 and the other transitions are repeated. If each segment was 51 pixels wide the clut image would look like this:
We can see the small kinks. When each segment is 250 pixels wide, I don't think the kinks matter.
DrEvil wrote:Again thanks a lot. Is there a way to specify the geometry of the images based on their center or is it always upper left?
If you use -gravity center -geometry ..., then if you are placing different gradients at different locations, it will position the centers of the gradients relative to the center of the background image.
Otherwise, the default is top left corner of the gradient relative to the top left corner of the background.
Is there a way to create gradients off of line strips in a way that doesn't over saturate the overlapping pixels of neighboring lines(such as if you did each line segments separately)?
I don't understand the question. Do you mean the colours in the clut? My chart above shows the actual colours in the bottom strip. They can be any colours you want. My script has 5 gradients, but you can have any number you like, from one upwards. Each transition can be any colour you want.
Suppose you have a series of line segments that make up a line strip of arbitrary length. The desire is to draw this line strip from point to point representing heat map events such as a persons locational history(where they moved around the environment, etc). Like the radial gradients, I would ideally be able to render these paths with a width and radial gradient falloff.
I would think that the way to accomplish this is to render the line sequence itself into an image with a gradient falloff 'away' from the line, as if rendering the line with a width but the width having a gradient falloff perpendicular to the line. It's that line gradient in particular that I'm asking about. Perhaps that would just be a polygon of the width of the event with a gradient along the polygon direction so that it falls off to the sides?
Drawing the lines appears pretty easy, the part I'm not sure of is the gradient falloff away from the lines based on a configurable width
How wide are the lines. If only one pixel, then the best you can do is just anti-alias or linear blur the line, but the blurring would thicken the line. There is no way to make a one-pixel thick line have a gradient in the direction perpendicular to the line direction and keep it one pixel wide.
For blurring perpendicular to the line direction, see -morphology convolve blur:...
But that only works if your lines are horizontal or vertical. You have to choose the angle for -blur as 0 or 90 as appropriate to the direction of your line.
You can convert the gaussian shape to linear by replacing 0xsigma with radiusx65535
It seems that I'll need to generate a batch file and such with individual commands for each event to be accumulated into the heatmap prior to colorization? That's fine, but if they are individual commands, does that mean convert.exe has to open, parse, draw, save and close the file for each event? I'm concerned with the performance of that for event counts up in the tens of thousands. Is there a way to feed those commands into an instance of convert.exe that can avoid tends of thousands of basic I/O operations and batch all the event drawing into 1 opening of the file ? I may ultimately be processing large files with which the file IO of opening and closing it tens of thousands of times could become a significant performance bottleneck.
You can create a gradient from a line by blurring it. For example, draw a white line on a black background and "-blur 0x15", perhaps followed by "-auto-level". This will blur in all directions, creating rounded ends. To blur just in the direction perpendicular to the line, you can rotate the line so it is horizontal, blur vertically, and rotate back.
What is your platform? Unix, Windows or what? As I said upthread, you can have one long command that processes all the events, or perhaps a hundred at a time. Unix (or possibly Cygwin on Windows) might give you other piping options.
On Windows, Powershell or Cygwin might be the geekiest options. I would just take the easy way: put the IM options for the thousands of events in an "at-file". This method is portable (as far as I know) across all environments.
For this method, create a file I will call heatmap.inc containing:
Ok I'm trying to get the floating point part to work properly and I'm not sure what I'm doing wrong. Specifically, the accumulation isn't working how I expect it to. In the inc file, the 2nd event is double in order to test the accumulation and normalization. The expectation is that overlapping events will accumulate their values and then the auto level will then level based on the new min/max values. The documentation for auto_level sounds correct. Perhaps I am not accumulating the values correctly? I'm trying to set it to use a 32 bit floating point format so that there really isn't a ceiling to the accumulation.
( -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.
