I have a dot graphviz file that geneates the following output:
http://www.qlands.com/other_files/test.png
However the output is organized vertically. If I setup the size to be for example 8.27 inches; How can I distribute the elements around a box of 8.27 x 8.27 inches?
Your graph is a directed graph layed out with dot from left to right, and the first rank contains many nodes which results in a very high image.
The main tool to break up graphs with this problem is unflatten:
unflatten is a preprocessor to dot that is used to improve the aspect
ratio of graphs having many leaves or disconnected nodes. The usual
layout for such a graph is generally very wide or tall. unflatten
inserts invisible edges or adjusts the minlen on edges to improve
layout compaction.
You may combine this with other tools and techniques to get the result you want:
Use the unflatten utility - please see this answer for a detailed example using unflatten.
Use invisible edges to introduce new ranks (basically what unflatten does automatically, but with human inspiration... example also here)
If you need the output to be of this exact size, be sure to understand graphviz's various attributes which have an impact on it, such as size, margin, ratio... (see also this and yet another answer providing details)
Finally, you could simply use a different layout (neato for example)
Related
I have a rather large graph in DOT, which I render using neato
and I'm more or less able to distinguish its main clusters using a lot of len=... attributes.
I wanted to experiment with twopi, because I like a lot the way it renders, but I see that it doesnt support len.
There are alternatives? My need is to manually keep some portions of the graph rather isolated from others, to enhance readability. I tried with clusters but apparently the results are not so good.
With twopi, you specify a root then the number of edges away from root will dictate which ring of the circle it belongs on. Another alternative you might also consider is circo which is yet another graphing tool from graphviz.
I'm writing a voronoi-based world generator in which I distinguish between geographic features like mountains, lakes, forests, and oceans.
Each feature is given an id so it can be identified and referenced. I use a flood fill algorithm to determine what features cells belong to.
I've realized a couple similar cases where I'd like to split a feature into multiple smaller ones. The most straightforward example is that of two big forests connected by a narrow strip of forest. Realistically, it should be treated as two forests, separated from each other around the narrow strip but my fill algorithm just plows right through and labels everything as part of one large forest.
I'd like to eventually label them "West 100 Acre Wood" and "East 100 Acre Wood", giving them the knowledge that they're deriving from the same continuous body of forest. I've looked up partial flood fill logic but my search has gotten stuck due to my lack of subject terminology.
If you'd like to see the code I'm working with:
https://github.com/olinkirkland/map
You would typically use a "morphological opening" see Wikipedia definition which is a morphological erosion followed by a dilation. If you imagine a white foreground object of interest on a black background, the erosion will erode (nibble away at the edges of) the object and the dilation will expand/fatten the edges back out - thereby removing small strips and narrow connections.
You can do it with the Scikit-Image module in Python, or with OpenCV in Python or C++. I choose to just do it at the command-line in Terminal here using ImageMagick which is installed on most Linux distros and is available for macOS and Windows.
So, using this map image:
I load it, invert/negate it to make the forest white, then apply the morphological opening I mentioned and then invert it back and save:
magick convert map.png -negate -morphology open disk:5 -negate result.png
After you find a connected region, you can trace around the interior using the right-hand rule (https://en.wikipedia.org/wiki/Maze_solving_algorithm#Wall_follower).
To find single-pixel paths that would make good splitting points, then, you can look for pixels in this interior path that are visited twice (once in each direction). If the path length is long enough on both sides of the split, then you can split the region into two at that pixel and maybe try again with the smaller regions.
If you want to find split points that are more than one pixel wide, or ensure that the forests on either side are "beefy" enough, I would suggest a pixel-based approach that combines this with the other methods:
BFS to remove pixels that are less than w away from the boundary.
Find each remaining connected region. Each will be the "center" of a forest.
Check each center to make sure it has pixels far enough from the edge to be the center of a forest.
Add the removed pixels back, connecting them to the closest center.
You could use a technique from image processing which uses blurring and applying a threshold of 50%. This way, thin connections and sharp spikes are reduced and features generally get rounder while the overall size of objects shouldn't change in one specific direction. Here's an image of what the process looks like when applied repetitively:
Separation of forests by blurring and applying a threshold
The top image represents your original situation with two forests which are connected by a thin corridor. The process step by step removes the corridor.
You can adjust some parameters in this process, e. g. the blurring radius and the number of steps, so you can tweak it to your needs.
The number of nodes in my d3 graph is too large. So I built a zoom mechanism in that graph. Now the problem is, I just cannot display text for each nodes since they will overlap each other. However when I zoom in to the nodes, the space is enough to display texts.
So how do I show texts when the space is enough to show all of them without overlapping?
I have had this same problem in the past. Unfortunately optimal label placement is not an easy problem. To mitigate overlap effects one option is to use a restricted force layout for label placement. You can also try using callouts to allow the labels to move farther away from the nodes.
In the past I have implemented a sort of greedy collision detection based algorithm that goes something like:
sort the labels in decreasing priority
for each label in the list // so most important first
if the label does not overlap any placed labels
place the label and add it to my collision data structure (e.g. quad tree)
else
hide the label
Obviously this will have some non-optimal cases and it can be slow if you have a lot of animations going on. But when you have the option to zoom in to see more label and if your absolute number of labels is not too high then it works quite well. There are also a number of obvious ways to speed it up like restricting testing to only labels within the view (but then you need to update on pan).
You may find some helpful suggestions here including an implementation of collision detection.
I have some map files consisting of 'polylines' (each line is just a list of vertices) representing tunnels, and I want to try and find the tunnel 'center line' (shown, roughly, in red below).
I've had some success in the past using Delaunay triangulation but I'd like to avoid that method as it does not (in general) allow for easy/frequent modification of my map data.
Any ideas on how I might be able to do this?
An "algorithm" that works well with localized data changes.
The critic's view
The Good
The nice part is that it uses a mixture of image processing and graph operations available in most libraries, may be parallelized easily, is reasonable fast, may be tuned to use a relatively small memory footprint and doesn't have to be recalculated outside the modified area if you store the intermediate results.
The Bad
I wrote "algorithm", in quotes, just because I developed it and surely is not robust enough to cope with pathological cases. If your graph has a lot of cycles you may end up with some phantom lines. More on this and examples later.
And The Ugly
The ugly part is that you need to be able to flood fill the map, which is not always possible. I posted a comment a few days ago asking if your graphs can be flood filled, but didn't receive an answer. So I decided to post it anyway.
The Sketch
The idea is:
Use image processing to get a fine line of pixels representing the center path
Partition the image in chunks commensurated to the tunnel thinnest passages
At each partition, represent a point at the "center of mass" of the contained pixels
Use those pixels to represent the Vertices of a Graph
Add Edges to the Graph based on a "near neighbour" policy
Remove spurious small cycles in the induced Graph
End- The remaining Edges represent your desired path
The parallelization opportunity arises from the fact that the partitions may be computed in standalone processes, and the resulting graph may be partitioned to find the small cycles that need to be removed. These factors also allow to reduce the memory needed by serializing instead of doing calcs in parallel, but I didn't go trough this.
The Plot
I'll no provide pseudocode, as the difficult part is just that not covered by your libraries. Instead of pseudocode I'll post the images resulting from the successive steps.
I wrote the program in Mathematica, and I can post it if is of some service to you.
A- Start with a nice flood filled tunnel image
B- Apply a Distance Transformation
The Distance Transformation gives the distance transform of image, where the value of each pixel is replaced by its distance to the nearest background pixel.
You can see that our desired path is the Local Maxima within the tunnel
C- Convolve the image with an appropriate kernel
The selected kernel is a Laplacian-of-Gaussian kernel of pixel radius 2. It has the magic property of enhancing the gray level edges, as you can see below.
D- Cutoff gray levels and Binarize the image
To get a nice view of the center line!
Comment
Perhaps that is enough for you, as you ay know how to transform a thin line to an approximate piecewise segments sequence. As that is not the case for me, I continued this path to get the desired segments.
E- Image Partition
Here is when some advantages of the algorithm show up: you may start using parallel processing or decide to process each segment at a time. You may also compare the resulting segments with the previous run and re-use the previous results
F- Center of Mass detection
All the white points in each sub-image are replaced by only one point at the center of mass
XCM = (Σ i∈Points Xi)/NumPoints
YCM = (Σ i∈Points Yi)/NumPoints
The white pixels are difficult to see (asymptotically difficult with param "a" age), but there they are.
G- Graph setup from Vertices
Form a Graph using the selected points as Vertex. Still no Edges.
H- select Candidate Edges
Using the Euclidean Distance between points, select candidate edges. A cutoff is used to select an appropriate set of Edges. Here we are using 1.5 the subimagesize.
As you can see the resulting Graph have a few small cycles that we are going to remove in the next step.
H- Remove Small Cycles
Using a Cycle detection routine we remove the small cycles up to a certain length. The cutoff length depends on a few parms and you should figure it empirically for your graphs family
I- That's it!
You can see that the resulting center line is shifted a little bit upwards. The reason is that I'm superimposing images of different type in Mathematica ... and I gave up trying to convince the program to do what I want :)
A Few Shots
As I did the testing, I collected a few images. They are probably the most un-tunnelish things in the world, but my Tunnels-101 went astray.
Anyway, here they are. Remember that I have a displacement of a few pixels upwards ...
HTH !
.
Update
Just in case you have access to Mathematica 8 (I got it today) there is a new function Thinning. Just look:
This is a pretty classic skeletonization problem; there are lots of algorithms available. Some algorithms work in principle on outline contours, but since almost everyone uses them on images, I'm not sure how available such things will be. Anyway, if you can just plot and fill the sewer outlines and then use a skeletonization algorithm, you could get something close to the midline (within pixel resolution).
Then you could walk along those lines and do a binary search with circles until you hit at least two separate line segments (three if you're at a branch point). The midpoint of the two spots you first hit, or the center of a circle touching the three points you first hit, is a good estimate of the center.
Well in Python using package skimage it is an easy task as follows.
import pylab as pl
from skimage import morphology as mp
tun = 1-pl.imread('tunnel.png')[...,0] #your tunnel image
skl = mp.medial_axis(tun) #skeleton
pl.subplot(121)
pl.imshow(tun,cmap=pl.cm.gray)
pl.subplot(122)
pl.imshow(skl,cmap=pl.cm.gray)
pl.show()
I am building a dot file to represent computer hardware and the physical connections to a network switch and displays. I have it looking ok when processed by the dot program but I think I really want it processed by neato to create a more "free form" picture as it starts to grom. Right now when I run my large file with neato, everything is overlapping.
I am trying to figure out the syntax on where to define the overlap attribute. Below is a subset of my dot file.
graph g {
node [shape=record,height=.1];
PC8[label="{{<GigE1>GigE1|<GigE2>GigE2}|{<name>PC8}|{<dvi1>dvi1|<dvi2>dvi2|<dvi3>dvi3|<dvi4>dvi4}}"];
PC9[label="{{<GigE1>GigE1|<GigE2>GigE2}|{<name>PC9}|{<dvi1>dvi1|<dvi2>dvi2|<dvi3>dvi3|<dvi4>dvi4}}"];
C1[label = "{{<dvi1>dvi1}|{<name>C1}}"];
C2[label = "{{<dvi1>dvi1}|{<name>C2}}"];
C3[label = "{{<dvi1>dvi1}|{<name>C3}}"];
C4[label = "{{<dvi1>dvi1}|{<name>C4}}"];
D1[label = "{{<dvi1>dvi1}|{<name>D1}}"];
D2[label = "{{<dvi1>dvi1}|{<name>D2}}"];
"PC8":dvi1 -- "C1":dvi1;
"PC8":dvi2 -- "C2":dvi1;
"PC8":dvi3 -- "C3":dvi1;
"PC8":dvi4 -- "C4":dvi1;
"PC9":dvi1 -- "D1":dvi1;
"PC9":dvi2 -- "D2":dvi1;
}
Well, as with most questions...soon after I posted the I figured out the answer. I needed to add graph [overlap=false]; at the top of the file.
Do it like this:
graph g {
overlap = false;
node [shape=record,height=.1];
/* ... */
}
Setting overlap to false will work for neato as the community wiki answer says; however, if the graph exhibits any kind of regularity or symmetry, [overlap=false] will often mess it up by jiggling the nodes around to make them not overlap.
Use [overlap=false] as a last resort.
All node overlaps that are outputted from neato can be viewed as occurring because the nodes are too big relative to the edges. You can make any overlaps go away by making the nodes smaller and preserve symmetry in the graph drawing by setting [overlap=scale]. Quoting the Neato user manual:
To improve clarity, it is sometimes helpful to eliminate overlapping
nodes or edges. One way to eliminate node overlaps is just to scale up
the layout (in terms of the center points of the nodes) as much as
needed. This is enabled by setting the graph attribute overlap=scale.
This transformation preserves the overall geometric relationships in
the layout, but in bad cases can require high scale factors
As the documentation says [overlap=scale] can result in graph drawings that are unacceptably large, but if it does not its output is generally going to be better looking than [overlap=false].