Export graph to DOT (or TikZ)?

[carlthome]

Under "Download PNG" on the Graphs tab it would be nice to have a "Download DOT" option (or TikZ) for when writing academic papers with LaTeX.

I imagine all currently open scopes under "Main Graph" would be included, and the user would manually open those of interest before downloading (much like how Download PNG works today, although I imagine that just saves a HTML5 canvas or something because it also includes the red border highlight which I believe is a bug?).

[carlthome]

Some of the job is already done: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/tools/quantization/graph_to_dot.py

[wchargin]

See also (not a duplicate): #32.

Yes, "Download PNG" currently just exports a canvas.

Being able to output to gv or TikZ sounds quite useful. The major advantage of exporting to gv over TikZ is that with TikZ we would have to lay out the graph ourselves—essentially reimplementing dot(1) but with a TikZ backend. (Alternatively, we could explore using the relatively recent \graph module of TikZ.)

We would want to improve that graph_to_dot script before using it, as it loses a bunch of information (e.g., isomorphism classes of node groups). But that's definitely feasible.

@chihuahua how do you feel about this? I'm happy to consult on any TikZ-related questions (I'm quite familiar with it).

(Anecdatum: A friend of mine recently suggested the same thing, specifically exporting to TikZ. He reasoned that it could improve diagram consistency among deep learning papers.)

[chihuahua]

Lets do it. I'll probably not get to this immediately, but it seems worth it, especially to those writing papers.

How about we export to gv (DOT) then?

[wchargin]

Okay. I tried my hand at manually creating a gv digraph from the images_demo/gaussian_blur sample graph, and produced the following result (scroll down for screenshots): https://gist.github.com/wchargin/b01873ec552a7d0f0a1882e10ed5cdd9

I think it looks promising. I've used graphviz before, but not extensively, so I'm not entirely sure how best to fix issues like the overlapping node labels on stack_* or the fact that those nodes aren't contained in the cluster. But it's worth noting that, aside from some syntactic shorthands, the above is an entirely mechanical translation of the original graph into gv. So it seems like even a zeroth-order optimization would be useful. Also, we'd let the user download gv code, not just a rendered image, so they can always tweak it themselves as long as we make the output code reasonably clear (which I also think is feasible).

[wchargin]

@chihuahua One more thought—I mentioned earlier that "The major advantage of exporting to gv over TikZ is that with TikZ we would have to lay out the graph ourselves." But in retrospect I realize that this was a silly comment—the graph explorer already computes the layout of the graph; we have the layout right in the positioning! So I will revise my estimation:

• If we export to gv, then we'll define the structure of the graph and let dot(1) lay it out as it sees fit. This could be quite different from the layout shown in the dashboard.
• If we export to TikZ, then we'll hard-code the current layout of the graph as computed by the dashboard. The relative positions of all nodes will be identical to the view in the dashboard (though their sizes may differ a bit).

Each of these sounds valuable; I'm happy to try gv first, or not, as you prefer, but the implementations will likely be quite different (hooking into different places of the graph dashboard code).

[chihuahua]

That is true ... the graph already performs dagre-based positioning. The graph explorer also exhibits a bunch of complexity. Similar ops are grouped into series nodes. Some nodes are extracted. We have annotation nodes and edges. Details: https://www.tensorflow.org/get_started/graph_viz#name_scoping_and_nodes

We should probably aim for some v0 that supports some core functionality such as metanodes and nodes. And then, fill in the details.

If you have the bandwidth, go for it. :)

[wchargin]

@chihuahua I don't have the bandwidth to implement the full pipeline, integrating with the existing graph explorer code. This is mostly because I'm not familiar with the graph plugin internals at all, but you are: the transformation itself is easy (see gist in previous post), so I'm sure that you could implement it without too much trouble if you wanted to, and I'd be happy to review.

[chihuahua]

Actually yeah - supporting the feature set in https://gist.github.com/wchargin/b01873ec552a7d0f0a1882e10ed5cdd9 seems doable and would make for a meaningful v0. :)

[wchargin]

@chihuahua Just FYI: I've just learned of http://www.webgraphviz.com/, which may be useful while you're developing this feature, in case you happen to be on a machine without graphviz installed. (Or maybe that's a bit of a stretch…but it's still a cool tool to know of! :-) )

[jart]

I just want to chime in and say I support doing something like this.

[Bidski]

Did this feature make it anywhere?

[bileschi]

@Bidski I think it has been abandoned. Can you speak more about your use case?

[Bidski]

@bileschi My use revolves around using tensorboard to layout the graph and then exporting that graph into a format that I can use in a latex document. Essentially I am just trying to avoid the work of either manually laying out the graph in latex and transcoding my tensorflow code into dot/tikz.