I have been trying to tackle a problem where I need to track multiple people through multiple camera viewpoints on a real-time basis.
I found a solution DeepCC (https://github.com/daiwc/DeepCC) on DukeMTMC dataset but unfortunately, this solution has been taken down because of data confidentiality issues. They were using Fast R-CNN for object detection, triplet loss for Re-identification and DeepSort for real-time multiple object tracking.
Questions:
1. Can someone share some other resources regarding the same problem?
2. Is there a way to download and still use the DukeMTMC database for multiple tracking problem?
3. Is anyone aware when the official website (http://vision.cs.duke.edu/DukeMTMC/) will be available again?
Please feel free to provide different variations of the question :)
Intel OpenVINO framewors has all part of this task:
Objects detection with pretrained Faster RCNN, SSD or YOLO.
Reidentification models.
And complete demo application.
And you can use another models. Or if you want to use detection on GPU then take opencv_dnn_cuda for detection and OpenVINO for reidentification.
A good deep learning library that I have used in the past for my work is called Mask R-CNN, or Mask Regions-Convolutional Neural-Network. Although I have only used this algorithm on images and not on videos, the same principles apply, and it's very easy to make the transition to detection objects in a video. The algorithm uses Tensorflow and Keras, where you can split your input data, i.e images of people, into two sets, training, and validation.
For training, use a third party software like via, to annotate the people in the images. After the annotations have been drawn, you will export a JSON file with all annotations drawn, which will be used for the training process. Do the same thing for the validation phase, BUT make sure the images in the validation have not been seen before by the algorithm.
Once you have annotated both groups and generated JSON files, you then can start training the algorithm. Mask R-CNN makes it very easy to train, with all you need to do is pass one line full of commands to start it. If you want to train data on your GPU instead of your CPU, then install Nvidia's CUDA, which works very well with supported GPUs, and requires no coding after the installation.
During the training stage, you will be generating weights files, which are stored in the .h5 format. Depending on the number of epochs you choose, there will be a weights file generated per epoch. Once the training has finished, you then will just have to reference that weights file anytime you want to detect relevant objects, i.e. in your video feed.
Some important info:
Mask R-CNN is somewhat of an older algorithm, but it still works flawlessly today. Although some people have updated the algorithm to Tenserflow 2.0+, to get the best use out of it, use the following.
Tensorflow-gpu 1.13.2+
Keras 2.0.0+
CUDA 9.0 to 10.0
Honestly, the hardest part for me in the past was not using the algorithm, but finding the right versions of Tensorflow, Keras, and CUDA, that all play well with each other, and don't error out. Although the above-mentioned versions will work, try and see if you can upgrade or downgrade certain libraries to see if you can get better results.
Article about Mask R-CNN with video, I find it to be very useful and resourceful.
https://www.pyimagesearch.com/2018/11/19/mask-r-cnn-with-opencv/
The GitHub repo can be found below.
https://github.com/matterport/Mask_RCNN
EDIT
You can use this method across multiple cameras, just set up multiple video captures within a computer vision library like OpenCV. I assume this would be done with Python, which both Mask R-CNN and OpenCV are primarly based in.
I need to query AutoCAD models to extract structures and connections (e.g., power, data) between them, for storage in a database. I know from experience and research that handling native AutoCAD .dwg is problematic due to the proprietary nature of the format. I see that AutoCAD features a .NET API, but still the problem looks daunting since I have essentially no knowledge a priori of the content of the models. The problem seems like a PhD thesis, as my initial googling hasn't yielded much in the way of tools support or examples.
Are there tools / libraries / examples available to help make AutoCAD extraction feasible in a compressed schedule on a small budget?
I have essentially no knowledge a
priori of the content of the models.
The library is not your problem. Your problem is how the data is modelled, or isn't modelled. You may need to cater for a range of things from attributed blocks to seemingly-unrelated, random bits of text scattered in the proximity of the items in question. If there is no standard for the way this information is stored in the drawing then there is no standard way of machine-reading it. It will probably take longer than a PHD thesis to extract it. You cannot guarantee any sort of comprehensive accuracy either.
AutoCAD (full version, not LT) has Data Extraction routine to extract blocks and attributes from a drawing. If that is how the data is presented then you might be in luck.
It might be cheaper and quicker to hire a team of Muppets to go through the drawings and type the data into something like Excel. You'd be (un)surprised how widespread this sort of practise is, even these days.
As for an inexpensive library, try the Open Design alliance, as mentioned in other AutoCAD questions on this site.
UML Round-Trip Engineering tools with seamless synchronization?
The Rational suite purports to do it. But it's so pricey and clunky at drawing (worse than the Rose days) that it's not in the reach of most departments.
What’s amazing is that the free Bouml seems to do a fantastic job. It’s just feels too clunky to use. It has a great deal of functionality, is free (!), very fast, and reverse-engineers complex C++ very well. It also has some nice diagram support, including a very nice sequence diagram. Although the interface is unpolished (and constantly opens dialogs on the rightmost monitor), it does have the beginnings of a very capable product. It's a shame that the interface is so bare-bones and requires the expenditure of a lot of effort. Maybe it's because the author puts most of his time into the actual functionality. Does anyone have experience using Bouml throughout the product lifecycle?
That leaves the pricey MagicDraw, the very-capable yet reasonably-priced Enterprise Architect, and the slick-looking Visual Paradigm. Of these, only Visual Paradigm had an issue reverse-engineering my project's C++ headers.
MagicDraw has a strange, old feel. It does a good job at reverse-engineering on its own, although it remains to be seen whether round-trip engineering of complex C++ projects is seamless. They want over $1800 for the multi-language version, so it's priced similarly to Rational tools.
Enterprise Architect, although far less expensive than most, seems like it may be the most feature complete. It parses and generates C++ flawlessly. Even the comments and formatting are left intact. There are great training materials. But it doesn't handle Objective-C, so less useful for iOS and Mac OS X mixed code projects. The automatic Sequence Diagram generation sounds awesome, but sounds like it only works on Windows .NET projects.
Visual Architect (>$800 for multi-language 2-way) is bar far the best-looking software modeling tool I've come across. Although it may have some round-trip issues remaining, it is a pleasure to use for building the models by hand. It's even nicer than Rose was in some ways. It has an intuitive way of bringing up the tools you need right at the cursor. Yet as I mentioned, it currently falls short of the goal to keep the model in sync with the source. And it often doesn't even give notification that the import didn't fully work, or that duplicate classes have been created (with the same names). It also makes entry of message parameters difficult, using dialogs, whereas others allow the parameters to be changed right on the diagram. (The free Bouml excels at this, as does MagicDraw and others.)
Has anyone found a multi-language (Java, C++, C#, ObjC++, Python, Ruby, SQL) round-trip engineering tool that will hold up to real world projects, where customizations are handled (like custom parameters on messages), yet are not wiped out by the next source code import?
And where all the formatting and comments are completely preserved on generation. Close is not really good enough. If the tools mess up the source code formatting, no developer is going to want the tool run on his source.
Peter Coad's Together-J used to have diagrams and an editor together in one IDE (hence the name). Change a diagram and the code changes; same for the other way as well.
The UML tool and editor were both a bit slow. I think machines of the day were underpowered and didn't show it off to best advantage.
I believe Peter Coad sold it to Borland. Looks like Borland is out of the IDE business. You can still get it here.
I think IntelliJ is the best Java IDE there is. You can generate some nice UML diagrams using it.
The real question is: Why is UML so important? I'd rather have code. I usually do enough UML to get the idea across, write the code with unit tests, and then reverse engineer it for documentation. You can't debug or unit test UML diagrams. Better to have working code.
Bouml ... constantly opens dialogs on the rightmost monitor
in a multiple monitor configuration the best is to indicate to Bouml which monitor must be used by default, else for Bouml you have just a very large monitor including all your monitors. Of course to indicate a default monitor doesn't means you can't use the other one(s), and it is possible to move the dialogs/main window where you want. The definition of the default monitor to use is done through the environment dialog.
Enterprise Architect seems to do a good job at this. As you point out, it's reasonably-priced. And it will also generate diagrams and documentation, as well as import/export source code.
I have been doing a little reading on Flow Based Programming over the last few days. There is a wiki which provides further detail. And wikipedia has a good overview on it too. My first thought was, "Great another proponent of lego-land pretend programming" - a concept harking back to the late 80's. But, as I read more, I must admit I have become intrigued.
Have you used FBP for a real project?
What is your opinion of FBP?
Does FBP have a future?
In some senses, it seems like the holy grail of reuse that our industry has pursued since the advent of procedural languages.
1. Have you used FBP for a real project?
We've designed and implemented a DF server for our automation project (dispatcher, component iterface, a bunch of components, DF language, DF compiler, UI). It is written in bare C++, and runs on several Unix-like systems (Linux x86, MIPS, avr32 etc., Mac OSX). It lacks several features, e.g. sophisticated flow control, complex thread control (there is only a not too advanced component for it), so it is just a prototype, even it works. We're now working on a full-featured server. We've learnt lot during implementing and using the prototype.
Also, we'll make a visual editor some day.
2. What is your opinion of FBP?
2.1. First of all, dataflow programming is ultimate fun
When I met dataflow programming, I was feel like 20 years ago, when I met programming first. Altough, DF programming differs from procedural/OOP programming, it's just a kind of programming. There are lot of things to discover, even sooo simple ones! It's very funny, when, as an experienced programmer, you met a DF problem, which is a very-very basic thing, but it was completely unknown for you before. So, if you jump into DF programming, you will feel like a rookie programmer, who first met the "cycle" or "condition".
2.2. It can be used only for specific architectures
It's just a hammer, which are for hammering nails. DF is not suitable for UIs, web server and so on.
2.3. Dataflow architecture is optimal for some problems
A dataflow framework can make magic things. It can paralellize procedures, which are not originally designed for paralellization. Components are single-threaded, but when they're organized into a DF graph, they became multi-threaded.
Example: did you know, that make is a DF system? Try make -j (see man, what -j is used for). If you have multi-core machine, compile your project with and without -j, and compare times.
2.4. Optimal split of the problem
If you're writing a program, you often split up the problem for smaller sub-problems. There are usual split points for well-known sub-problems, which you don't need to implement, just use the existing solutions, like SQL for DB, or OpenGL for graphics/animation, etc.
DF architecture splits your problem a very interesting way:
the dataflow framework, which provides the architecture (just use an existing one),
the components: the programmer creates components; the components are simple, well-separated units - it's easy to make components;
the configuration: a.k.a. dataflow programming: the configurator puts the dataflow graph (program) together using components provided by the programmer.
If your component set is well-designed, the configurator can build such system, which the programmer has never even dreamed about. Configurator can implement new features without disturbing the programmer. Customers are happy, because they have personalised solution. Software manufacturer is also happy, because he/she don't need to maintain several customer-specific branches of the software, just customer-specific configurations.
2.5. Speed
If the system is built on native components, the DF program is fast. The only time loss is the message dispatching between components compared to a simple OOP program, it's also minimal.
3. Does FBP have a future?
Yes, sure.
The main reason is that it can solve massive multiprocessing issues without introducing brand new strange software architectures, weird languages. Dataflow programming is easy, and I mean both: component programming and dataflow configuration building. (Even dataflow framework writing is not a rocket science.)
Also, it's very economic. If you have a good set of components, you need only put the lego bricks together. A DF program is easy to maintain. The DF config building requires no experienced programmer, just a system integrator.
I would be happy, if native systems spread, with doors open for custom component creating. Also there should be a standard DF language, which means that it can be used with platform-independent visual editors and several DF servers.
Interesting discussion! It occurred to me yesterday that part of the confusion may be due to the fact that many different notations use directed arcs, but use them to mean different things. In FBP, the lines represent bounded buffers, across which travel streams of data packets. Since the components are typically long-running processes, streams may comprise huge numbers of packets, and FBP applications can run for very long periods - perhaps even "perpetually" (see a 2007 paper on a project called Eon, mostly by folks at UMass Amherst). Since a send to a bounded buffer suspends when the buffer is (temporarily) full (or temporarily empty), indefinite amounts of data can be processed using finite resources.
By comparison, the E in Grafcet comes from Etapes, meaning "steps", which is a rather different concept. In this kind of model (and there are a number of these out there), the data flowing between steps is either limited to what can be held in high-speed memory at one time, or has to be held on disk. FBP also supports loops in the network, which is hard to do in step-based systems - see for example http://www.jpaulmorrison.com/cgi-bin/wiki.pl?BrokerageApplication - notice that this application used both MQSeries and CORBA in a natural way. Furthermore, FBP is natively parallel, so it lends itself to programming of grid networks, multicore machines, and a number of the directions of modern computing. One last comment: in the literature I have found many related projects, but few of them have all the characteristics of FBP. A list that I have amassed over the years (a number of them closer than Grafcet) can be found in http://www.jpaulmorrison.com/cgi-bin/wiki.pl?FlowLikeProjects .
I do have to disagree with the comment about FBP being just a means of implementing FSMs: I think FSMs are neat, and I believe they have a definite role in building applications, but the core concept of FBP is of multiple component processes running asynchronously, communicating by means of streams of data chunks which run across what are now called bounded buffers. Yes, definitely FSMs are one way of building component processes, and in fact there is a whole chapter in my book on FBP devoted to this idea, and the related one of PDAs (1) - http://www.jpaulmorrison.com/fbp/compil.htm - but in my opinion an FSM implementing a non-trivial FBP network would be impossibly complex. As an example the diagram shown in
is about 1/3 of a single batch job running on a mainframe. Every one of those blocks is running asynchronously with all the others. By the way, I would be very interested to hearing more answers to the questions in the first post!
1: http://en.wikipedia.org/wiki/Pushdown_automaton Push-down automata
Whenever I hear the term flow based programming I think of LabView, conceptually. Ie component processes who's scheduling is driven primarily by a change to its input data. This really IS lego programming in the sense that the labview platform was used for the latest crop of mindstorm products. However I disagree that this makes it a less useful programming model.
For industrial systems which typically involve data collection, control, and automation, it fits very well. What is any control system if not data in transformed to data out? Ie what component in your control scheme would you not prefer to represent as a black box in a bigger picture, if you could do so. To achieve that level of architectural clarity using other methodologies you might have to draw a data domain class diagram, then a problem domain run time class relationship, then on top of that a use case diagram, and flip back and forth between them. With flow driven systems you have the luxury of being able to collapse a lot of this information together accurately enough that you can realistically design a system visually once the components are build and defined.
One question I never had to ask when looking at an application written in labview is "What piece of code set this value?", as it was inherent and easy to trace backwards from the data, and also mistakes like multiple untintended writers were impossible to create by mistake.
If only that was true of code written in a more typically procedural fashion!
1) I build a small FBP framework for an anomaly detection project, and it turns out to have been a great idea.
You can also have a look at some of the KNIME videos, that give a good idea of what a flow based framework feels like when the framework is put together by a great team. Admittedly, it is batch based and not created for continuous operation.
By far the best example of flow based programming, however, is UNIX pipes which is one of the oldest, most overlooked FBP framework. I don't think I have to elaborate on the power of nix pipes...
2) FBP is a very powerful tool for a large set of problems. The intrinsic parallelism is a great advantage, and any FBP framework can be made completely network transparent by using adapter modules. Smart frameworks are also absurdly fault tolerant, and able to dynamically reload crashed modules when necessary. The conceptual simplicity also allows cleaner communication with everybody involved in a project, and much cleaner code.
3) Absolutely! Pipes are here to stay, and are one of the most powerful feature of unix. The power inherent in a FBP framework compared to a static program are many, and trivialise change, to the point where some frameworks can be reconfigured while running with no special measures.
FBP FTW! ;-)
In automotive development, they have a language agnostic messaging protocol which is part of the MOST specification (Media Oriented Systems Transport), this was designed to communicate between components over a network or within the same device. Systems usually have both a real and visualized message bus - therefore you effectively have a form of flow based programming.
That was what made the light bulb go on for me several years ago and brought me here. It really is a fantastic way to work and so much more fun than conventional programming. The message catalog form the central specification and point of reference. It works well for both developers and management. i.e. Management are able to browse the message catalog instead of looking at source.
With integrated logging also referencing the catalog to produce intelligible analysis things can get really productive. I have real world experience of developing commercial products in this way. I am interested in taking things further, particularly with regards to tools and IDEs. Unfortunately I think many people within the automotive sector have missed the point about how great this is and have failed to build on it. They are now distracted by other fads and failed to realize that there was far more to most development than the physical bus.
I've used Spring Web Flow extensively in Java Web applications to model (typically) application processes, which tend to be complex wizard-like affairs with lots of conditional logic as to which pages to display. Its incredibly powerful. A new product was added and I managed to recut the existing pieces into a completely new application process in an hour or two (with adding a couple of new views/states).
I also looked into using OS Workflow to model business processes but that project got canned for various reasons.
In the Microsoft world you have Windows Workflow Foundation ("WWF"), which is becoming more popular, particularly in conjunction with Sharepoint.
FBP is just a means of implementing a finite state machine. It's nothing new.
I realize that it is not exactly the same thing, but this model has been used for years in PLC programming. ISO calls it Sequential Flow Chart, but many people call it Grafcet after a popular implementation. It offers parallel processing and defines transitions between states.
It's being used in the Business Intelligence world these days to mashup and process data. Data processing steps like ETL, querying, joining , and producing reports can be done by the end-user. I'm a developer on an open system - ComposableAnalytics.com In CA, the flow-based apps can be shared and executed via the browser.
This is what MQ Series, MSMQ and JMS are for.
This is cornerstone of Web Services and Enterprise Service Bus implementations.
Products like TIBCO and Sun's JCAPS are basically flow-based without using this particular buzz-word.
Most of the work of the application is done with small modules that pass messages through a processing network.
I am designing software that needs to draw several different kinds of charts--bar charts, pie charts, flow charts/graphs, charts over time. I am looking for resources related to both the programming side of the issue as well as the UI/display side. Books, online resources would all be helpful. Thanks.
It does depend on the language a bit: here may be some pointers for you. Hope they help:
code.google.com/apis/chart/
home.gna.org/pychart
Practical C# Charts and Graphics
The Excel library can be imported by the Office API, but it does require you to have Excel installed.
Gnuplot
The grammar of graphics: book from the guy that wrote the plotting lib of spss. Somewhat theoretical, but nice xml treatment... gives you the graph xml schema for spss.
But I'm sure there are quite a few others that other people will know.
Do you have to draw it your self. If you want to save time (and probably money) then you can try embedding one of these into your apps http://code.google.com/apis/chart/
Ditto with Chris; If you are developing a new way of building charts, that's great!
Assumption: I have no idea of your needs but it would initially strike me (and thus form my assumption) that you are trying to develop a better charting software and that's usually interface.
Consider checking out the libraries in other programming languages that already do charting.
Adobe Flex/Air have one, PHP does, Java Does, .NET does.. etc.
Checking out the existing charing libraries for your language of choice helps a lot. In my case, it helped so much I decided not to write my own. ;)
For .net apps we settled on .netCharting, which can be pretty amazing.
The real lesson I took from it though, is this: there are way, way more kinds of charts than I thought there were, and I work with a lot of charts. Make sure you end up with something modular enough to handle clicking in new chart types / configurations with minimal effort.
You want to take a look at EyeSee.
http://moose.unibe.ch/tools/eyesee