I'm looking for an algorithm (or algebra) for 2d box alignment. The alignment of (recursive) boxes is implemented in type setting systems like TeX and Lout but also in web browsers. For example, boxes can be aligned horizontally or vertically, spread over available space and recursively composed. Are there papers or implementations out there that implement such systems outside of type setting? Is there a consensus how such systems are best described?
Edit: The Haskell Diagrams package looks like a pretty thorough approach for composing graphical objects. It can deal with any shape, not just boxes. It's weak spot seems to be dealing with text which is very important for type setting, web browsers, and GUIs.
Edit: Coffins in LaTeX3 look relevant.
Related
I do not have a background in image recognition/feature extraction, but I am in need of a way to extract trees from an image without the background vegetation.
Seen above is a small example of the kind of imagery I'm working with. I have access to multi-spectral imagery as well (though I haven't seen it yet) including NDVI, NIR, Red-edge.
From researching the problem at hand, I am aware that feature extraction is an active area of research and it seems that often supervised and unsupervised machine learning is employed in combination with statistical voodoo such as "PCA". Being able to differentiate between trees and background vegetation has been noted as an area of difficulty in some papers I skimmed over in my research.
There are notable features about the imagery I am working with. First of all, the palm trees have a very distinctive shape. Not only this, but there are obvious differences in the texture of the trees vs the texture of the background vegetation.
I am not an academic, and as such I only have access to publicly available papers for my research. I am looking for relevant algorithms that could help me extract the features of interest to me (trees) that either have an implementation (ideally in C or bindings to C, though I'm aware that it is not a commonly used language in this field) or with publicly available papers/tutorials/sites/etc. detailing the algorithm so that I could implement it myself.
Thanks in advance for any help!
Look into OpenCV, It has a lot of options for supervised/semi supervised Learning methods. As you have mentioned there is a visible texture difference between the tress and background vegetation, a good place for you would be to start would be color based segmentation and evolving it to use textures as well. OpenCV ML tutorial is a good starting point. Moreover you can also combine the NDVI data to create a stronger feature set.
I just read Scott Hansleman's post on Guided View Technology in comics
and I though that this would be awesome if implemented in other avenues (specifically in manga )
I mean reading right to left in itself can be a little weird to start with and this would lower the barrier to entry for new readers.
I was wondering if there was possibly an open source project out there in the wild or if not then possibly a means to get started with something like this as I am not an image processing guru. In particular I just really would need to figure out which lines are panels and where to slice into smaller pictures. Because comics all have their own prefs as far as line thickness I'm not sure if there is a simple way to do this that works across many different border thicknesses and styles. Language doesn't matter so much here, I'm really about dealing with concepts and patterns of attack.
You can start by looking at the Duda-Hart implementation of the Hough transform for lines.
http://en.wikipedia.org/wiki/Hough_transform
The Hough algorithm will yield equations for straight lines. From that you can find intersections, identify rectangles, etc.
You can also use a kernel-based corner detection to find T-, L-, and X-intersections.
http://en.wikipedia.org/wiki/Corner_detection
One difficulty is that some panels in comics won't have "hard" edges, or may have edges that are squiggly, circular/elliptical, French curvy, etc. You can find particular algorithms for particular problems, but it would be hard to generalize these algorithms in a set of rules and programmatic logic that will work for all (or even most) samples. It seems that a hallmark of a good comic could be considered to be the elegant and sometimes surprising panelization, "surprising" being a synonym for unpredictable. Although there are many methods to "segment" an image into different regions, this is still an active area of research.
But if you start with Hough lines you'll have a good start and learn a lot about image processing.
I have a lot of polygons. Ideally, all the polygons must not overlap one other, but they can be located adjacent to one another.
But practically, I would have to allow for slight polygon overlap ( defined by a certain tolerance) because all these polygons are obtained from user hand drawing input, which is not as machine-precised as I want them to be.
My question is, is there any software library components that:
Allows one to input a range of polygons
Check if the polygons are overlapped more than a prespecified tolerance
If yes, then stop, or else, continue
Create mesh in terms of coordinates and elements for the polygons by grouping common vertex and edges together?
More importantly, link back the mesh edges to the original polygon(s)'s edge?
Or is there anyone tackle this issue before?
This issue is a daily "bread" of GIS applications - this is what is exactly done there. We also learned that at a GIS course. Look into GIS systems how they address this issue. E.g. ArcGIS define so called topology rules and has some functions to check if the edited features are topologically correct. See http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=Topology_rules
This is pretty long, only because the question is so big. I've tried to group my comments based on your bullet points.
Components to draw polygons
My guess is that you'll have limited success without providing more information - a component to draw polygons will be very much coupled to the language and UI paradigm you are using for the rest of your project, ie. code for a web component will look very different to a native component.
Perhaps an alternative is to separate this element of the process out from the rest of what you're trying to do. There are some absolutely fantastic pre-existing editors that you can use to create 2d and 3d polygons.
Inkscape is an example of a vector graphics editor that makes it easy to enter 2d polygons, and has the advantage of producing output SVG, which is reasonably easy to parse.
In three dimensions Blender is an open source editor that can be used to produce arbitrary geometries that can be exported to a number of formats.
If you can use a google-maps API (possibly in an native HTML rendering control), and you are interested in adding spatial points on a map overlay, you may be interested in related click-to-draw polygon question on stackoverflow. From past experience, other map APIs like OpenLayers support similar approaches.
Check whether polygons are overlapped
Thomas T made the point in his answer, that there are families of related predicates that can be used to address this and related queries. If you are literally just looking for overlaps and other set theoretic operations (union, intersection, set difference) in two dimensions you can use the General Polygon Clipper
You may also need to consider the slightly more generic problem when two polygons that don't overlap or share a vertex when they should. You can use a Minkowski sum to dilate (enlarge) two and three dimensional polygons to avoid such problems. The Computational Geometry Algorithms Library has robust implementations of these algorithms.
I think that it's more likely that you are really looking for a piece of software that can perform vertex welding, Christer Ericson's book Real-time Collision Detection includes extensive and very readable description of the basics in this field, and also on related issues of edge snapping, crack detection, T-junctions and more. However, even though code snippets are included for that book, I know of no ready made library that addresses these problems, in particular, no complete implementation is given for anything beyond basic vertex welding.
Obviously all 3D packages (blender, maya, max, rhino) all include built in software and tools to solve this problem.
Group polygons based on vertices
From past experience, this turned out to be one of the most time consuming parts of developing software to solve problems in this area. It requires reasonable understanding of graph theory and algorithms to traverse boundaries. It is worth relying upon a solid geometry or graph library to do the heavy lifting for you. In the past I've had success with igraph.
Link the updated polygons back to the originals.
Again, from past experience, this is just a case of careful bookkeeping, and some very careful design of your mesh classes up-front. I'd like to give more advice, but even after spending a big chunk of the last six months on this, I'm still struggling to find a "nice" way to do this.
Other Comments
If you're interacting with users, I would strongly recommend avoiding this issue where possible by using an editor that "snaps", rounding all user entered points onto a grid. This will hopefully significantly reduce the amount of work that you have to do.
Yes, you can use OGR. It has python bindings. Specifically, the Geometry class has an Intersects method. I don't fully understand what you want in points 4 and 5.
I've been considering writing my own UI framework. This is mostly because I have some relatively specific requirements for it- namely, integrating with my own hardware-accelerated 3D graphical code. The question is, what are the minimal primitives I can expose from the rendering code and still be able to render a wide series of controls, like combo-boxes and drop-down lists and such, and in addition, is doing that even feasible?
I will only need relatively basic controls to begin with and could implement others on an as-needed basis. Right now, I only expose rendering text and rendering a texture.
Random things that come to mind :
Draw text (done)
Draw textures (done)
Access individual pixels (huge must for custom drawing)
Allow for transformation matrices
Different blending modes (add and alpha-add, mainly)
If your underlying 3D rasterizer allows it: drawing lines, curves, path.
With this I think you can do a pretty wide range of stuff already.
The MSDN documentation is (somewhat) clear about the following two facts about GDI Pens:
A Cosmetic pen (create via CreatePen or ExtCreatePen w/ PS_COSMETIC) must be 1 unit wide (well, <= 1, but let's not go there).
A Geometric (ExtCreatePen w/ PS_GEOMETRIC) pen must solid (PS_SOLID only, no PS_DASH, etc). They can, however, draw fatter lines. This is clearly documented in the link I put above as only a 9x restriction (I'm dumb). To my defense (bad) comments and (broken) logic in my code led me to believe otherwise. Some other googled articles must have been written concidering only Windows 9x.
Why can I voilate these rules and have GDI happily draw with these Pens?
I can create fat (width = 10, for example) cosmetic pens and dashed Geometric pens. Heck, I can create a fat, dashed geometric pen!
These Pens seem to work fine usually. The only problem I've seen is in Polyline when I pass very large arrays of points - it renders the lines very slowly. However, Polyline is acting strangely with large arrays in general - it justs acts differently with the bad pens. (my other polyline problems may be another question...)
Is it ever safe to use wide Cosmetic pens or wide Geometric with patterns?
In general you should adhere to the documented API, otherwise you risk relying on OS version specific behaviour.
The ExtCreatePen restrictions you describe (e.g, no PS_DASH with PS_GEOMETRIC) only apply to Win9x, not WinNT, so on NT/2000/XP your "fat, dashed geometric pen" shouldn't be a problem. Also note that Polyline has some limitations on Win9x.
If you want dashed lines, I'd suggest using PS_USERSTYLE so that you control the lengths of the dashes and gaps, rather than relying on whatever default PS_DASH gives you.