spectralcode / octproz Goto Github PK

On the Jetson Nano, CPU memory and GPU memory share the same physical SoC DRAM.
Instead of using cudaMemcpyAsync, utilizing zero copy might enhance performance.

See:

• CUDA C++ Best Practices Guide - Zero copy
• CUDA for Tegra
• ArrayFire - Zero Copy on Tegra K1

Describe the bug
The program closes after the acquisiton is started. This does not happen when I delete the "emit this->system->acquisitionStarted(this->system);" line from my OCT system acquisition thread.

Expected behavior
Not crash

Screenshots
Because there is no error message, I cannot provide a screenshot.

Used hardware

• OS: Win 10 64bit
• GPU: Nvidia GTX 670

Additional context
Did anyone encounter a similar issue?

System: Ubuntu 18.04
Cuda: 11.2
Qt: 5.10.1
GPU: RTX 3090

I am building the project in Qt for the first time and I am getting the following error: "/usr/bin/ld cannot find -lcuda" as seen in the picture below:

Additionally, in qtcreator terminal, I'm getting the following error message:

I can see that it's not able to locate cuda. But based on the messages it looks like it get can find cudart but not cuda. Any thoughts? Been struggling with this for a while... also I'm pretty certain cuda is properly installed as well.

A time-lapse feature that enables automatic recording of OCT data for user-defined time intervals could be usefull.

Also, it would be nice if the user could specify the time of day and the number of days when recording should happen.

The contributing guidelines should contain a style guide and/or some more infos about coding standards.

Some things to consider:

• every header file should have at least one brief comment to explain what the use of the file/class is
• create an overview document that explains the code structure of the software and add a link to it in the contributing guidelines
• use some ideas from the Mantid project coding standards: https://www.mantidproject.org/C++_Coding_Standards

It would be convenient if the last used OCT system would load automatically at startup.
If there is only one OCT system available than this should be loaded automatically at startup.

Add the possibility to use custom curves for sinusoidal scan correction. This way, scan shapes that are not 100% sinusoidal could also be corrected.

Is your feature request related to a problem? Please describe.
I'm always frustrated when starting an extension that requires a large GUI and uses SEPARATE_WINDOW as displayStyle. A very large GUI will block the view on to the main applaication and everything else because the extension window is always on top of everything.
Another relateted thing: I think for some OCT systems it may be annoying that the acquisition system plugin is displayed as QDialog (for example if you have settings like scanner offset which you would like to change during an OCT acquisition). It should be possible to dock acquisistion systems and extensions; this would highly increase usability.

Describe the solution you'd like
OCTproZ should use Advanced Docking System for Qt for all plugins (extensions as well as acquisition systems) and for all output windows such as the live B-scan window.

Describe alternatives you've considered
An alternative could be to use the regular QDockWidget system for everything. But this causes trouble on Ubuntu 16.04, because dock widgets cannot be moved properly. On Windows everything works fine.

Averaging and Maximum Intensity Projection (MIP) for the live B-Scan view and live En Face view can be optimized.

Have a look at the functions "updateDisplayedBscanFrame" and "updateDisplayedEnFaceViewFrame" in cuda_code.cu.
Maybe a parallel reduction approach could be used here to optimize the calculations.

I'm looking at the kernel execution order at the CUDA timeline, and it seems to me that data processing kernels started with the async memcpy kernel (inputCast), and ended before the images async copy is done (meanAlineSubtraction). Am I missing anything? If so, how do you ensure memcpy is not in race condition with these data processing kernels? Thanks in advanced for your answer.

OCTproZ makes use of the low-level API for extending Qt applications.
However, the Qt plugin API is not used correctly in OCTproZ:

• the different plugin interfaces/classes that are defined in the DevKit should only have pure virtual functions
• the plugin classes defined in the DevKit should not inherent from QObject
• it is not necessary to use an enum in the Plugin class to detect if the plugin is an AcquisitionSystem or an Extension. This should be done with qobject_cast but is currently not possible; probably due to the two bullet points mentioned above

Qt provides example code on how to use the plugin API correctly: https://doc.qt.io/qt-5/qtwidgets-tools-plugandpaint-app-example.html
and: https://doc.qt.io/qt-5/qtwidgets-tools-plugandpaint-plugins-extrafilters-example.html

These are major changes that will affect the compatibility of OCTproZ plugins created with the current version of the DevKit. Since OCTproZ uses semantic versioning, the version number must be changed to 2.

To avoid having to change the major version of OCTproZ again in the near future, please let me know what other changes or features you suggest for the DevKit. I think it's better to include all desired features at once and then not change the DevKit for as long as possible.

Other features to add:

• Plugins should be able to draw into B-scan and en face view outputs
• Fix linux bug where QFileDialog is not usable with plugins when a GL window is open in OCTproZ --> Add "dialogAboutToOpen" and "dialogClosed" signals to plugin class.
• Add startRecordingRequest() signal to plugin.h
• Fix typo in acquisitionsystem.h: "acqusitionRunning"

Maybe to add:

• A way to let one extension talk to another extension
• Maybe it would be useful if plugins could instruct OCTproZ to start recording (add startRecordingRequest() signal to plugins.h)
• Consider using componentsystem

Hi, I notice the A-scans rate (4x10^6 Hz/ sec)is surprisingly high in Table 1. And the hardware info was not mentioned in the paper. What kind of Camera and image acquisition card the "Lab Computer" is acquired with?

Thanks in advance for your answer.

Describe the bug
For some reason I am unable to view the sample dataset. I am getting an entirely black screen, frequently with a message like this: 16:15:32 ERROR: No system opened!.

To Reproduce
Followed all steps in the user guide. Settings exactly as given in the images and descriptions at: https://figshare.com/articles/SSOCT_test_dataset_for_OCTproZ/12356705

Expected behavior
Expected to see the image included in the aforementioned link.

Screenshots
Expected:

My Output:

Used hardware

• OS: Win 10 64bit
• GPU: Intel(R) UHD Graphics 620

Describe the bug
Code won't build due to missing support of:

• Turing – GTX 1660 Ti, RTX 2060, RTX 2070, RTX 2080, Titan RTX, Quadro RTX 4000, Quadro RTX 5000, Quadro RTX 6000, Quadro RTX 8000, Quadro T1000/T2000, Tesla T4
• Ampere – Tesla GA10x cards, RTX Ampere – RTX 3080, GA102 – RTX 3090, RTX A6000, NVIDIA A40, GA106 – RTX 3060, GA104 – RTX 3070, GA107 – RTX 3050

To Fix
When using a Touring or Ampere card change in cuda.pri:
CUDA_ARCH += sm_30 \ -gencode=arch=compute_30,code=sm_30 \ -gencode=arch=compute_50,code=sm_50 \ -gencode=arch=compute_52,code=sm_52 \ -gencode=arch=compute_60,code=sm_60 \ -gencode=arch=compute_61,code=sm_61 \ -gencode=arch=compute_70,code=sm_70 \
to
CUDA_ARCH += sm_52 \ -gencode=arch=compute_52,code=sm_52 \ -gencode=arch=compute_60,code=sm_60 \ -gencode=arch=compute_61,code=sm_61 \ -gencode=arch=compute_70,code=sm_70 \ -gencode=arch=compute_75,code=sm_75 \ -gencode=arch=compute_80,code=sm_80 \ -gencode=arch=compute_86,code=sm_86 \ -gencode=arch=compute_86,code=compute_86
for max compatibility with newer architecture. Keep in mind that you may loose the compatibility for older generations & Jetson Source.

Used hardware

• OS: popOS
• GPU: Nvidia GTX 1660 Super

Describe the bug
While use a 4K display and resolution (3840 x 2160) the software crashes when opening the 3D view window.
Running the program in Qt 5.12.12 Creator generates the following Application output:

QWindowsWindow::setGeometry: Unable to set geometry 3838x2034+0+46 (frame: 3864x2105-13-12) on QWidgetWindow/"OCTproZWindow" on "\\.\DISPLAY1". Resulting geometry: 3840x2035+0+45 (frame: 3866x2106-13-13) margins: 13, 58, 13, 13 minimum size: 1238x890 MINMAXINFO maxSize=0,0 maxpos=0,0 mintrack=2502,1851 maxtrack=0,0) QWindowsWindow::setGeometry: Unable to set geometry 3840x2036+0+46 (frame: 3866x2107-13-12) on QWidgetWindow/"OCTproZWindow" on "\\.\DISPLAY1". Resulting geometry: 3840x2035+0+45 (frame: 3866x2106-13-13) margins: 13, 58, 13, 13 minimum size: 1238x890 MINMAXINFO maxSize=0,0 maxpos=0,0 mintrack=2502,1851 maxtrack=0,0) Main Thread ID start emit: 0x13e0

To Reproduce
Using a 4K monitor, open the 3D view of the program. It is not necessary to load any data for the crash to happen.

Used hardware

OS: Win 10 64bit
GPU: NVIDIA GeForce RTX A4000 (CUDA 11.7)
Screens: AOC U2879VF

Additional context
This problem has been identified in multiple hardware configurations, always using a 4K monitor. Using the same monitor at a lower resolution (1920x1080) works fine.

These settings worked for me to compile octproz_project.pro

QT Version: Desktop Qt 5.12.10 MSVC2017 64bit
Compiler C/C++: Compiler 14.0 (x86_amd64)
CUDA: cuda_9.0.176_win10

1. Use jom.exe instead of cmake! Even when I checked “Use jom instead of nmake” (settings > Build & Run), Qt Ctreator did not use it. Therefore, I use it manually. So UNCHECK this jom setting.

• Download jom 1.1.0
• In Build settings, Build steps > details, instead C:\yourpath\nmake.exe use: select the directory of the jom.exe
• No arguments for make (delete “clear” if this is pre-set)
• Uncheck “disable in subdirectories”
• Do the same for the “Clean Steps”

2. Qt also seems to miss the location of the rc.exe (I do not know what it does). I add the rc.exe path in “Build Environment” under PATH (for me C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64)

3. After building the release file I had to add multiple QT.dll from the Qt bin folder to the release folder where the OCTproZ.exe is. For me: QT5Gui.dll, QT5Widgets.dll, QT5Core.dll, QT5PrintSupport.dll

4. I had a compile error that virtualoctsystemsettingsdialog.ui could not be found, anyway it was in the correct folder. The problem solves itself when I put everything on the same hard drive as the QT installation folder. (C:/ for me)

Describe the bug
Images in the 2D views (B-scan and En Face View) are distorted when rotated.

To Reproduce
Steps to reproduce the behavior:

1. Open System and start processing
2. Change "Rotation" value within 2D-B-scan or 2D-En Face View window

Expected behavior
Aspect ratio of 2D image should remain the same for all window sizes and for all rotation angle values if "Keep Aspect Ratio" is checked.

Screenshots

Hi there!

Really cool project!!

I attempt to compile the project in QtCreator on an Nvidia Jetson device, the Jetson Nano.

The Jetson line of devices utilizes an aarch64 architecture as opposed to an x86.

My guess is this key difference is why I'm having trouble compiling it.

My guess is this comes down to the following in the cuda.pri file:

unix{
	CUDA_DIR = /usr/local/cuda

	INCLUDEPATH_CUDA += /usr/include/x86_64-linux-gnu/qt5 \	#todo: is there a more general way to access the qt include directory?
		/usr/include/x86_64-linux-gnu/qt5/QtCore\
		$$CUDA_DIR/include \
		$$CUDA_DIR/samples/common/inc

	INCLUDEPATH += $$CUDA_DIR/include \
		$$CUDA_DIR/samples/common/inc

	QMAKE_LIBDIR += $$CUDA_DIR/lib64
}

In which case the #todo could be a way of generalize the architecture, be it x86 or aarch64.

I'll experiment with some solutions. Just thought I'd bring this to your attention! The Jetson boards are really nifty and could definitely have a place in an OCT rig, especially a lightweight one!

Thanks for being awesome!

Matt

Describe the bug
When compiled with Qt 5.12.1 processing performance drops significantly on a system with a dual monitor setup, but just if OCTproZ is displayed on the monitor with DisplayPort connection. If displayed on the monitor with HDMI connection there is no drop in performance.

With exactly the same settings as described in performance.md perfromance drops from about 2.4 MHz A-scan rate to 1.4 MHz A-scan rate with the gaming computer setup.

When compiled with Qt 5.10.1 there are no performance issues at all.

To Reproduce
I don't know what the crucial point is for this bug to occur, but on this specific system the bug can be reproduced as follows:

1. Have a dual monitor setup. One screen with HDMI connection and one with DisplayPort connection.
2. Compile OCTproZ with Qt 5.12.1
3. Run OCTproZ and move it to the screen with DisplayPort connection

Used hardware

• OS: Win 10 64bit
• GPU: NVIDIA GeForce GTX 1080 (CUDA 9.1)
• Screens: Samsung T24C350 (HDMI), ASUS VG275Q (DisplayPort)

Additional context
I really don't know what causes this bug and would be grateful if someone with a similar software or hardware setup could share their observations.

Followup March 22th 2022:
There is a performance drop with Qt 5.12.12 and displayport monitors as well. This is particularly noticeable when rotating the volume in the 3D view, as it does not react as smoothly as it should and a lag is noticeable.
There are no issues with Qt 5.11.1

Is your feature request related to a problem? Please describe.
For some folks it seems to be confusing to have the newest info or error message at the top of the message console.

Describe the solution you'd like
The menu that opens when you right-click on the message console should contain the option "newest message on bottom"
As a starting point, look at the file messageconsole.cpp

Describe the bug
If you run OCTproZ on Linux the processing thread is not started and processing takes place in the GUI thread. This means that on Linux some GUI interactions slow down or even block OCTproZ.
Initially this was done because it seemed like that the OpenGL output windows updated very slowly on Linux when the VirtualOCTSystem was used. After a little bit more investigation, it turned out that this issue does not occur if one increases the value for "Wait after file read" drastically or if an actual OCT system is used.
This needs further investigation. Maybe VirtualOCTSystem needs to be modified.

To Reproduce
Steps to reproduce the behavior:

1. Run OCTproZ on Linux
2. Load OCT System and start processing
3. Right click on B-scan live view
4. B-scan live view is not updating as long as mouse menu is visible

Used operating system
Ubuntu 16.04

How to activate separate processing thread for Linux
If you want to test it on your own, change the following code in octproz.cpp

	#elif defined(Q_OS_LINUX)
		//this->signalProcessing->moveToThread(&processingThread);
		//todo: fix linux bug: opengl window seems to be laggy on ubuntu test system if signalProcessing is moved to thread -> check visual profiler
		this->processingInThread = false;
	#endif

to

	#elif defined(Q_OS_LINUX)
		this->signalProcessing->moveToThread(&processingThread);
		this->processingInThread = true;
		connect(&processingThread, &QThread::finished, this->signalProcessing, &Processing::deleteLater);
	#endif