QT QImage Read From Error

mvsri

@JonB @Christian-Ehrlicher reason for using thread was the entire code snippet will be in a while loop, continuously grabbing image. and main GUI has other functions on it.
and also i have tried without using qthread but there was no real time image capturing happening there (i also used QTimer).

JonB

@mvsri
Just for now: instead of a single image declaration somewhere, in your code try:

QImage *image = new QImage;
bool result = image->load(image_path);
...
emit sendImage(*image);
// or, with corresponding change to signal/slot parameter
emit sendImage(image);

I know this will leak the image! Assuming it's not too big, and you don't do it too often, so that memory is not an issue, does that make a difference to the "black" you see?

Christian Ehrlicher

@JonB No need to create it with new, a local instance on the stack will work fine

JonB

@Christian-Ehrlicher
I don't see that as safe? If the stack variable in the thread goes out of scope while the signal has been emit()ed passing the image for the main UI thread to use, won't that release the image while it is still needed by the main thread?

mvsri

@JonB @Christian-Ehrlicher
i tried both methods using new and local instance.
still it doesn't make any difference.
will it be advisable to use QMutex for this?

Christian Ehrlicher

No need for a mutex, please post code with stack variable.

will be in a while loop, continuously grabbing image. and main GUI has other functions on it.

So you say the image reading take too long?

mvsri

@Christian-Ehrlicher
This is the code

while(true)
   {
       bool check = doesFilexExist(image_path);
       if(check){
           QImage image;
           bool result = image.load(image_path);
           QThread::msleep(20);
           if(!image.isNull()){
               qDebug() << "==> Timestamp for image grabbing: " << QTime::currentTime();

               emit sendImage(image);
               QFile::remove(image_path);
               QThread::msleep(50);
           }
       }
       else {
           // Do nothing
       }
   }

@Christian-Ehrlicher said in QT QImage Read From Error:

So you say the image reading take too long?

I'm not so sure about that.

The logic is very simple :
1. Check if image exists in folder.
2.if exists, load image
3.emit the image
4. delete image from the folder

Note: 3rd party camera stores a single image in that folder

Christian Ehrlicher

@mvsri So are you sure the camera does not override the image while you try to load it? Please try without the camera with a static image.

J.Hilk

@mvsri Have you thought about using QFileSystemWatcher to listen to changes in the folder,?

No need to reinvent the wheel, you can simply react to the directoryChanged signal

If @Christian-Ehrlicher is right, and the camera overwrites the image, than the fileChanged signal will be much handier to use.

mvsri

@Christian-Ehrlicher
I think the camera does override the image when i try to load it because when i tested it with static image the code worked perfectly

mvsri

@J-Hilk said in QT QImage Read From Error:

@mvsri Have you thought about using QFileSystemWatcher to listen to changes in the folder,?

I haven't thought about that will try to use it now.

Christian Ehrlicher

@mvsri said in QT QImage Read From Error:

I think the camera does override the image when i try to load it because when i tested it with static image the code worked perfectly

So you've your explanation of the issue - Qt can't do anything against this.

mvsri

@Christian-Ehrlicher
yeah i got that, but the thing is if you see the code,
after reading the image i'm deleting the image from the folder, so the chances for image override is very less

Christian Ehrlicher

@mvsri Maybe try to rename it before you try to read it.

Bonnie

Maybe try to find out if that 3rd party camera has other API than save the image to the disk.

JonB

@mvsri
I really don't understand what is going on! What is it that produces that image_path file? Something external? How do you know that whatever is creating it has finished writing the file and flushed it before your thread decides to read it in, such that it might read in something incomplete? :confused:

mvsri

@JonB said in QT QImage Read From Error:

@mvsri
I really don't understand what is going on! What is it that produces that image_path file? Something external? How do you know that whatever is creating it has finished writing the file and flushed it before your thread decides to read it in, such that it might read in something incomplete? :confused:

image_path is nothing but a QString which stores the path to a bmp image in a folder. the path is static it doesn't change.
I don't know whether the image writing is finished or not. that's why i used QFile exists to check if the file is created or not and read the image if the path exists.
I also have the same doubt whether i'm reading the image in an incomplete mode.

@Christian-Ehrlicher said in QT QImage Read From Error:

@mvsri Maybe try to rename it before you try to read it.

I'm trying it now.

Thank you everyone for all the help. will try to update if i found something useful.

JonB

@mvsri said in QT QImage Read From Error:

image_path is nothing but a QString which stores the path to a bmp image in a folder. the path is static it doesn't change.

I know that! My question is about the content of that file.

I don't know whether the image writing is finished or not. that's why i used QFile exists to check if the file is created or not and read the image if the path exists.

But that doesn't tell you anything about whether it has started but not finished writing to that file, does it? (Unless you are relying on Windows or something not allowing a file to satisfy "exists" until it has been closed, which I would see as dodgy in the extreme.) In which case, you will read in an incomplete image file, maybe that's why you have "black" at the bottom? At least put in a qDebug() << image.sizeInBytes() after loading it (though I'm not sure if that's reliable)....

QFile::remove(image_path);

It gets worse! This, or renaming: how do you know that at the instant you execute this the camera has not re-started writing to that file for the next capture, and you are (trying to) removing/renaming a file while it is being written anew?

Is your camera-image-capture-write-to-file a separate process from your code? How do you know when the capture has started/finished writing to the file?