Also see Visual Studio -> View -> Task List (limited visibility of TODOs) or better one: https://visualstudiogallery.msdn.microsoft.com/c5d16a00-fe89-4a9e-8fba-a5c1a9f38841

Fixed by adding missing Q_OBJECT.

Missing Q_OBJECT was the cause. Nevertheless restructuring to the usage of event bus is on the list, this would minimize the dependency on Qt events, which are sometimes hard to debug in case of problems, and be more loose coupled.

Handlers in event map are stored as indices to list of handlers at the moment, possibly another map with hash key is required to be able to remove handlers again. Fragmentation has also to be taken into account to prevent memory leaks or other side-effects.

Checked also under Linux and GCC, seems to be fine again.

Reworked.

Committed

Another bus: https://github.com/skypjack/eventpp

Seems to be working again.

phabricator daemons restarted

Long running operations should be represented in the modal progress dialog, short running/parallel small operations should be represented by progress bar in the status bar at the bottom, see Krita or GIMP for example.

Renamed DriveInfo to more general PathInfo and adjusted a little bit. Further modifications will follow. Commit is not visible at the moment, as Lab has some problems with repository connection.

Mockup:

Is currently implemented in ProcessingTest, will be moved to OCui later.

Removed most obsolete parts or reworked them.

TODO notes:

Using https://github.com/cacay/MemoryPool at the moment. Needs some abstraction if tests with 4K raw frames are successful.

Still missing intelligent pattern processing and border interpolation, but image loading was adjusted to be able to load Axiom test data. Screenshot shows the ProcessingTest application. The lower image has some gamma correction in it and is also convert to 8-bit for Qt image control. Upper one ist still in 16-bit and witohut processing.

Mockup:

Current implementation in OCCore / CMakeLists.txt:

Current state:

Logger will be adjusted to use Singleton pattern for now, as the Windows build is failing with current inheritance approach (Linux one was fine). Later it can be rewritten to use more loose coupled approach through an injection framework, like https://sites.google.com/site/fruitlib/home. This would also have advantage in deriving the components from a common base, e.g. components as services with access interfaces like REST, RPC, shared memory and so on.

"What do you mean by "platforms which aren't OS"?"

What do you mean by "platforms which aren't OS"? I would be interested in developing things which are specific for apertus° cameras and post-processing, but still leaving it open-source of course.

It would be a shame to have to pass the community off onto platforms which aren't OS. Coding and post production are quite polarised disciplines unfortunately.

Partially that were people who are coders. I've talked to Sebastian about that some months ago and his opinion on that topic was: people need some leading and management. But i cannot accomplish that alone.

Well I'm going to give it a dedicated Twitter account. It's not quite ready yet but it'll start on just under a thousand followers. The problem with that from your perspective is that it's comprised of what you'd deem to be end-users - film makers. They aren't coders.

No, that was new to me. No sarcasm. Have rather limited feedback on OC, sometimes Sebastian forwards people to me, but that's it most of the time.

OpenCine gets a huge amount of interest in outbound promo you know, as in, unusually high interest.

Current state:

• Borders are not processed at the moment
• Used clip from BlackMagic, waiting for apertus° ones ;), source: http://nofilmschool.com/2012/08/blackmagic-john-brawley-release-raw-cinema-camera-files-for-download

• Private attrbutes should be prefixed with underscore ( _ ), e.g. float _posX;
• Interfaces should be prefixed with upper case I, e.g. IProcessor
• Variables/attributes should start with lower case letter and methods/classes/interfaces with upper case, e.g. int frameCount, void Process(), class FrameProcessor

Removed some leaks, also memcpy() will be moved out of OCImage, as it was only added for quick tests. OCImage will hold only pointers to red/green/blue data arrays, image loader will move the data to memory pool (static allocation).

Current RAM usage is too high when 2 CDNG frames are loaded, ~210MB. For 2432w * 1366h * 2 bytes * 3 channels should occupy around 20MB, but 40 are occupied at the moment. Image buffers will be reviewed to isolate the problem, also some parts will be stripped for test to determine minimal memory usage (Release/Debug).

TODO:

• Add pagination to speed up thumbnail view (QML), possible performance impact when image loading will be added
• Add pre-filter to recognize CDNG folders and present them as clips, otherwise show only supported image files
• Add LibRaw adapter as fallback, currently only TiffLoader is present for CDNG

TODO:

• Minimize conversion of QString to std::string and back, QString is sufficient for GUI parts, but should be avoided in core components

Fixed. Check changed CMakeLists.txt for future changes.

References (general):
http://flax.ie/flax-engine-gwt-event-bus-implementation/
https://code.google.com/p/acris/wiki/MVP_Acris
http://bastian.rieck.ru/blog/posts/2015/event_system_cxx11/