utwente / parlevision Goto Github PK

We need a better logger. qDebug() is used for everything now but this does not yield output in release mode.

We need a logger which can have different levels such as WARNING, ERROR, NOTIFY etc and which works in release mode. It would also be nice if it writes to a file because of lack of stdin stdout in windows.

A deadlock happens when:

• create new pipeline or open a pipeline file
• change it but do not save
• close application and choose to discard and not to save

Nothing in the framework is exported, so it only works on old gcc and Mac OS X now.

Limit not just by type (OpenCVImage<->OpenCVImage) but also by properties (depth etc.).
Challenge: come up with solution that does not just work for OpenCV datatypes, but also for those added in the future.

One solution might be a mime-like compatibility list like Qt's drag&drop framework uses: http://doc.qt.nokia.com/4.6/qmimedata.html

The following should not lead to a crash, but to the erroneous second pin name being sufixed with _ with the lowest int that avoids duplcate pin names...

At least, that's my opinion ;-)

#define INPUT_PIN_NAME1 "input 1"
#define INPUT_PIN_NAME2 "input 1"
#define OUTPUT_PIN_NAME "output"

AddSub::AddSub() :
        m_method(1),
        m_normalize ( false )
{
    m_inputPin1 = createInputPin<OpenCVImage>( INPUT_PIN_NAME1, this );
    m_inputPin2 = createInputPin<OpenCVImage>( INPUT_PIN_NAME2, this );
    m_outputPin = createOutputPin<OpenCVImage>( OUTPUT_PIN_NAME, this );
}

It should stop processing on an unhandled exception, rather than keep going as is now the case.

PlvEnum properties need to be able to be saved and read from file again.

On the one hand, it is very good that the viewers get low priority when the CPU is not strong enough.
On the other hand, on my machine, it seems the viewers still insist on showing all frames, which means they start lagging because they do not get to update as often as the processors do process().

So. A viewer should, when it updates the display, should take the most recent value of the pin, and not the next not-viewed value. A kind of lossy 1-frame buffer, no?

When declaring pins in a certain order(e.g. A, B, C) they need to retain that order in the GUI. Since Pins are internally stored in a map, they lose their order and can get displayed out of order. (e.g. B, A, C).

It sometimes doesn't paint or repaint properly.

boolean properties get their inverse value when loading from file :)

When I use docked pin-views to see the output of my pipeline, the docked view will try to occupy the same screen estate as the library-info-view

At this time, connections between processors are guaranteed to be of the same type. However, the parameters of these types are not checked. Many processors are now implementing a sort of type checking themselves, which leads to code duplication and generates exceptions when processors which are incompatible are connected to each other. For instance, one should be able to guarantee that the input size of image A and B are always the same, and if they are not the same the possibility of conversion should be checked. If conversion is not possible the pipeline should be stopped and there should be an error reported to the GUI.

It now shows in Library, but it is also desirable to be able to view the details of a processor that has already been added to the pipeline without having to look it up.

Processor function process() is called in one or several work threads which are managed by a scheduler. This scheduler is responsible for workload management and cache locality management, meaning that threads "walk" with a frame(number) through the pipeline.

Generate a dependency graph using a topological sort algorithm for true dependency based scheduling. This can increase efficiency and would create true fair scheduling which solves the problem of skewing and queueing which is present now when one processor is much heavier to process than a parallel one in the graph.

When using the string property field of a processor to edit a string value in the Inspector, the cursor always skips to the end of the string after each character entry.

Add shortkeys for things that don't have them yet and make them work in Windows as well.

Sometimes scrolls when drawing lines. This is annoying.

When I create a simple pipeline, consisting of only a CameraProducer and consequently I press "play", the application crashes.

If I have only one piepline element, I can drag it to the right, outside of the render view area (actually, onto the inspector, as I have all views docked), and the element will disappear! Also, I do not get the scrollbar that normally helps me find it back :)
IF however at a later time I cause the render area to grow, and I have the scrollbar, I can see that this original element indeed still existed outside of the originally viewable render area

It should show exceptions as they occur.

start -> new pipeline -> add camera, violajones -> connect them -> start -> CANNOT LOAD HAAR FILE alert message -> press OK -> start again -> FREEZE

pipeline: camera + flip

start pipeline

error:
Error: Flip Image: Depth unsupported by one or multiple connected input pins

It has a fixed size now, but on small screens this makes the library unusably small. Investigate if it's feasible to make it resizable or just make a button that toggles visibility.

Make sure you can choose between lossless/lossy types and set buffer sizes.

It is currently not possible to simply restart the pipeline after a processor throws an exception. It is possible to restart the pipeline after manually removing and re-adding the offending processor. This should be handled by the framework.

Right now, XML loading is done by using QMetaType to instance the class using a string identifier such as "plvopencv::ImageConvert". This seemed nice, but unfortunately this enforces all processors to have a copy constructor and prevents them from using signals and slots because they cannot inherit from QObject which does not allow a copy constructor.

We will have to build a factory of some sorts for processors.

PipelineElement interface is to abstract since we need to cast between PipelineProducer and PipelineProcessor to call the produce() and process() functions. See Pipeline.cpp run() method.

We need global configuration settings such as the default OpenCV directory and a way to access these variables by the components and processors.

For some cases, such as OpenCV Image types or algorithms, it might be useful to have the framework automatically generate a drop-down list of predefined values in the Inspector instead of an input field.

Buffermanager has to be able to construct and destruct types which may or may not be available at the time of compilation. Therefore, custom types need to be registered in the buffermanager/typeregistry to allow for a factory design pattern on custom types.

-camera
-A add B processor

• camera out naar beide inputs van AaddB
• start pipeline

error:
Error: A add B: Processor A add B did not call mandatory get() on input Pin input 2

(als je regel 65 en 66 omdraait zegt hij het zelfde over input 1)

Either load previous pipeline, empty pipeline or something else.

As Dennis commented in the code:

// FIXME: [DR] can we, instead of using the 2nd name arguments,
// get this information within plvRegisterPipelineElement from Q_CLASSINFO("name")?
// And use actual classname if this Q_CLASSINFO was not set?

"Als ik een processor maak met 2 variabelen genaamd "threshold1"
en "threshold2" krijg ik een segmentation fault wanneer ik die processor in
de pipeline sleep. Als ik ze "thresholdLow" en "thresholdHigh" noem is er
niets aan de hand.. :S Zal wel iets zijn van Qt Creator ofzo maar toch raar,
iig goed voor in een handleiding"

canny: no check on aperturesize or valid threshold values
sobel: no properties used at all!
laplace: not enough check on aperture size? see laplace documentation for possible values

If I have only one piepline element, I can drag it to the right, outside of the render view area (actually, onto the inspector, as I have all views docked), and the element will disappear! Also, I do not get the scrollbar that normally helps me find it back :)
IF however at a later time I cause the render area to grow, and I have the scrollbar, I can see that this original element indeed still existed outside of the originally viewable render area

.. instead of QPixmap ugliness. In highgui:

Image conversion

Convert to a grayscale or color byte-image:

cvConvertImage(src, dst, flags=0);

src = float/byte grayscale/color image
dst = byte grayscale/color image
flags = CV_CVTIMG_FLIP (flip vertically)
CV_CVTIMG_SWAP_RB (swap the R and B ch

source: http://www.cs.iit.edu/~agam/cs512/lect-notes/opencv-intro/opencv-intro.html#SECTION00041000000000000000

Maybe ScheduleInfo::updateAndGetState should also have a try{} catch (Everything) around the call to m_element->isReadyForProcessing

to avoid faulty processors from crashing the framework

D

Recreate:
Open or make a pipeline.
Start it, so it is running.
Drag a processor into the pipeline.
Crash.
This should give a warning that you are not allowed to edit the pipeline while it is running, but instead in Qt 4.7.0 on Windows XP it results in a crash in an SSE2 blend operation.

Show information about pins, datatypes and a description or PipelineElements in the library.

If you press stop and then start, you would expect the pipeline to start from scratch. Now, stuff remains on the connections that was there before.

Sort by type etc.

Right now, a processor is allowed to make a connection between one of its output pins and an input pins. This would create a cycle and is incorrect. Needs to be checked and error reported to screen.

This will cause bugs.

Deserialisation needs to be able to instantiate custom processor which are not known at compile time. Processors need to register themselves on DLL load. QMetatype can be used for this. qRegisterMetatype at DLL load.

Viewers/Renderers are docked and minimized in windows. Default size does not seem to work while it works on OSX.

I added a test pipeline to the repository that shows the issue:

A camera and an addsub processor.
The camera out is connected to both addsub inputs.
The output of the addsub shows that apparently, the addsub gets one input pin with a severe delay, and the other not! (At least, on mu Vista machine). Suggestions for where I should look to debug this?