Issue with threading and opencv

[J.Hilk]

Hi @Kira

a solution doesn't quit come to my mind, but I have to ask, why do save the image in the HD first ? Seems like an unnecessary step ?

[Kira]

@J.Hilk : Yes i agree with you its unnessary to save the image. In future we will store it internally in queue. But this is an interesting use case. I wanted to know the problem exactly so that i can avoid it in near future.

[J.Hilk]

@Kira how do you save the file, also with Qt ? Than maybe QSaveFile will help

https://doc.qt.io/qt-5/qsavefile.html#details

---

That said, maybe using QFileSystemWatcher to monitor your saved file should also reduce the error frequency ?

[Kira]

@J.Hilk : I am using imwrite an opencv function to save the image.
Actually the problem arise after i start using thread. So i just want to know how the thread is causing the issue.

[jsulm]

@Kira The thread writing the file should emit a signal when the file was written and closed. The thread consuming files should only read files which were already notified through that signal. This way you would avoid reading and writing same file from two different threads at the same time.

[Kira]

@jsulm : Just one question for clarification.
If i use two different mutex, will the one mutex will inform about other if i tried to lock ?
Or should i use same mutex where the conflicting situation is expected ?
Also i was going through opencv i got the following warning which was not seen before:
Warning:Premature end of JPEG file

[jsulm]

@Kira said in Issue with threading and opecv:

If i use two different mutex, will the one mutex will inform about other if i tried to lock ?

No.
But with the solution I suggested there is no need at all for any mutexes. Just use signals/slots as I suggested with queued connection type.

"Warning:Premature end of JPEG file" - I guess it's because the file is damaged.

[Kira]

@jsulm : Thanks for highlighting the possibility of signal/slots.
I will have to redesign my approach for implementing the same.
Just couple of question:
-> If i queue signal and slot will it affect my overall program.
ie. Suppose i queue the signal/slots related to this program will it affect the other signal/slots
written in my program . For ex: delay in execution of the signal/slots of the main program.
-> How to make a mutex wait for the previous lock if we are not sure how much time it is going to take.

[jsulm]

@Kira said in Issue with threading and opecv:

Suppose i queue the signal/slots related to this program will it affect the other signal/slots
written in my program . For ex: delay in execution of the signal/slots of the main program.

Queued signals do not block anything - they are just in a queue. The only delay you will have is the slot when it is actually called - but that you will have anyway as you have to execute the code anyway, right?

"How to make a mutex wait for the previous lock if we are not sure how much time it is going to take" - I don't understand this question. A mutex either blocks the thread which wants to lock if the mutex is already locked, or you can continue immediately. So, you already have this "waiting" if the mutex is already locked.

[Kira]

@jsulm
Queued signals do not block anything - they are just in a queue. The only delay you will have is the slot when it is actually called - but that you will have anyway as you have to execute the code anyway, right? : Yes

Thanks for the help cleared a lot of implementation doubts.
Just a small question. If i have a thread which acquires the lock and there is one more thread which requests for the locked resource. How will i tell the other thread wait until and unless the lock in the thread have not been unlocked.
We can currently use the wait time but is there any way to tell when create a notification when the lock is released and tell the other thread to wait for that specific time.

And one more thing how to highlight specific lines which we are answering. Which you have did for my earlier questions. :)

[jsulm]

@Kira said in Issue with threading and opecv:

How will i tell the other thread wait until

That's exactly what a mutex is doing: it blocks the thread which tries to lock a mutex which is already locked by other thread, as soon as the other thread releases the mutex the OS will wake up one of the blocked (waiting) threads. So, you do not have to tell the thread anything.

[Kira]

@jsulm : Hello i have implemented the save image function in a slot as suggested by you.
But the problem is that the image is not being saved. I would like to share the given code:

signals:
void signalSaveImage(cv::Mat,String row,String column);
slots:
public slots:
void saveImage(Mat finalImage,String row, String column);
Slot Definition:

void MainWindow::saveImage(Mat finalImage, String row, String column)
{
    cout<<"Inside image save function"<<endl;
    cout<<"Row"<<row<<endl;
    cout<<"Column"<<column<<endl;
    String imagePath = "D:/testN/"
    String imageFormat = ".bmp";
    try {
           cv::imwrite(imagePath+row+"_"+column+imageFormat,finalImage);
       }
       catch (cv::Exception& ex) {
           fprintf(stderr, "Exception in saving image: %s\n", ex.what());
       }
       fprintf(stdout, "Saved PNG file with alpha data.\n");

    cout<<"\n Entering inside save mutex"<<endl;

    cout<<"\n Completed image save function"<<endl;


}

Signal to slot connection:
connect(this,SIGNAL(signalSaveImage(cv::Mat,String,String)),this,SLOT(saveImage(Mat,String,String)),Qt::QueuedConnection);

MainWindow.cpp
Emitting signal to save image:
emit signalSaveImage(image,to_string(row),to_string(column));

But my problem is that my images are not being saved.

[J.Hilk]

@Kira said in Issue with threading and opencv:

QueuedConnection

forces a copy of the arguments, The MetaSystem doesn't know the type cv::Mat -> can't be transmitted via QueuedConnection.

Check your console output you should have warning of unknown metatyps (declare and/or register)

[Kira]

@J.Hilk : I have registered it.
#include "mainwindow.h"
#include <QApplication>

int main(int argc, char *argv[])
{
qRegisterMetaType< cv::Mat >("cv::Mat");
QApplication a(argc, argv);
MainWindow w;
w.show();

return a.exec();

}

[J.Hilk]

@Kira

the data goes most likely out of scope, as the copy constructor of cv::Mat does actually no coping

I had the same issues in my time with opencv.

ended up converting it to a Image before transferring it from the opencv thread to the normal one.

[Kira]

@J.Hilk : Just for clarification should i replace this part with cv::clone
void saveImage(Mat finalImage,String row, String column);

[Kira]

@J-Hilk : will try and also i tried to run the program in debug mode and getting the following error.

Debugger redirects to following line of file of ostream:
// MANIPULATORS
template<class _Elem,
class _Traits> inline
basic_ostream<_Elem, _Traits>&
__CLRCALL_OR_CDECL endl(basic_ostream<_Elem, _Traits>& _Ostr)
{ // insert newline and flush stream
_Ostr.put(_Ostr.widen('\n'));
_Ostr.flush();
return (_Ostr);
}

And the program quits.
Can u please explain what may be the relevant reason for error

[jsulm]

@Kira Please post the stack trace after crash

[Kira]

@jsulm : I thought this is the stack trace after crash

[jsulm]

@Kira said in Issue with threading and opencv:

this is the stack trace after crash

no, it isn't