Rather than going pixel by pixel, I would write a method that fills a memory block with the content of the vectors.

@Wenchi said in Crash in function: QImageData * QImageData::create(const QSize &size, QImage::Format format):

Although the code is crashing in various places, but the crash point is always the same:

But that is likely --- or just as possible --- indicating you have a problem elsewhere which only shows up here, such as corrupted/misallocated memory? How else would you explain it "crashing" in e.g. QList<MyWidget>.push_back()?

by the way, I'm fired. ready to get a new start

I am sorry to hear that, good luck for future.

@A-A-SEZEN Thanks, it actually works now

@Nick-Redwill This is what windeployqt is for...

@Dariusz said in Qt 6 fails to load jpg in to QImage:

Do you know whats the name of plugin or dll?

imageformats\qjpeg.dll

@artwaw said in Blurry and strange color when creating barcode using fonts:

@Proton-Phoenix I no longer have access to the Zebra I was using in the past (I changed the company since then).
Zebra printers are a story on their own to troubleshoot anyway...

General approach I used:

make sure the printer is configured properly in the system, with the default page size set to the target page size. query the QPrinterInfo instance for the default page size. use that data with QPdfWriter to render whatever text + barcode I need. remember DPI settings, either set what the manual for the printer says (ideal) or 300 (this didn't end well for Dymo printers I used for a while, needed exact DPI of 204 ;) ). print and enjoy.

In general getting this to work might be lots of trial and error, depending on the brand and drivers. But once it's done right it is literally zero maintenance for years.

<3 Thank you bro for everything <3

Did you consider using the QtGraphicalEffects module ?

Hi,

You should check your video file, but as I wild guess, it's likely a FullHD video which is 1920 * 1024. Since you are creating a RGB QImage out of it, it's already weighing about 6MB per image. QPixmap is meant to be optimised for rendering and thus the backing memory used might even be larger for, for example, alpha channel handling. Depending on what else you do with your application and these images you can pretty quickly hit memory limits if your application is 32bit.

One of the issue here is that the conversion must be done each time the draw method is called. If you know that your images will not change or not much then you should do the conversion upfront so that the painting can be optimized.

Which examples are you referring to ?

Hi,

The most "simple" is to downsample from 10 to 8 bit.

Maybe OpenCV has better support for that kind of format and might be an alternative.

@chessking5544 said in Cannot create QImage using smart pointers:

Will c++ smart pointers work, or is there just no way to do this?

Just for completeness I will answer this. But first I have to agree with the others that you should allocate QImage on the stack. Good C++ style avoids pointers wherever possible. The best lifetime management is variables on the stack. Containers - and in this case I will count QImage as a container - will internally allocate memory on the heap. This is a good thing as your stack is quite small. I don't know C# well (but assume it has some similarity to Java within this respect), but objects do not need to be allocated using new in C++. If you want polymorphism you can use references instead of pointers. Rarely do you actually need pointers in C++.

Now to the answer: C++ smart pointers work with every class. Just use it like this:

std::shared_ptr<QImage> image = std::make_shared<QImage>(QSize(1920,1080), QImage::Format_RGB32);

Note the use of make_shared here. This will automatically handle out-of-memory errors. Internally it will call new and hand down its parameters to the constructor of QImage. It is advised to use make_shared<QImage>(...) over shared_ptr<QImage>(new QImage(...)) (I can't remember all the reasons).

@Christian-Ehrlicher Aha! Thanks, good to know. I guess that explains this, then:

>>> from PyQt5 import QtCore, QtGui >>> i = QtGui.QImage("/tmp/front3.jpg") >>> m = QtGui.QImage("/tmp/mask.png") >>> m = m.convertToFormat(QtGui.QImage.Format_Alpha8) >>> i.setAlphaChannel(m) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'QImage' object has no attribute 'setAlphaChannel' >>> QtCore.PYQT_VERSION_STR '5.14.2' >>> QtCore.QT_VERSION_STR '5.14.2'

Ooh. Then again, maybe not. Looks like Riverbank didn't get a memo. (After installing from the latest wheels...):

>>> from PyQt5 import QtCore, QtGui >>> i = QtGui.QImage("/tmp/front3.jpg") >>> m = QtGui.QImage("/tmp/mask.png") >>> m = m.convertToFormat(QtGui.QImage.Format_Alpha8) >>> i.setAlphaChannel(m) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'QImage' object has no attribute 'setAlphaChannel' >>> QtCore.QT_VERSION_STR '5.15.2' >>> QtCore.PYQT_VERSION_STR '5.15.2'

Welp, I've got a bug report to file. Thanks for the help!

Going to mark this thread as closed since it seems the issue lies with VNC, not Qt. Thank you all for your suggestions and helping me to isolate the problem.

@Christian-Ehrlicher Sorry for stressing you out - I thought you were referring to a specific function for some reason. I really need to slow down when reading and comprehend rather than just having a quick look and then replying which is causing confusion on all sides. Thank you again for your patience and assistance throughout.

so write a test program, meter the performance of canvas writes vs out-of-bounds writes, and report back.

Just let Qt do its work. If by drawing directly on QWidget you mean subclassing it and rewriting its Paint() method - don't do it unless you absolutely have to. Or, when you need to provide a delegate for a view.
So far I've not had the necessity to dive that deep.
And since you can display (and scale) images and videos using QLabel, push buttons can be readily supplied with an icon... I just had not need.
Then again, your needs might differ.

QImage::save() doesn't get the raw bytes of the image, it converts the image to a file format.
If you really want the raw bytes, do something like

QByteArray ba((const char *)preview.constBits(), preview.byteCount());

@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?

Thank you all guys. Your suggestions and expert opinion helped a lot with solving the problem. QT forum is always so helpful.

After trying many things here is the conclusion and code is now working perfectly fine

I removed the tic toc part

time(&start);
timer = double(getTickCount());
tic();
It was working but crashing then just to make sure that QImage is not NULL I removed the img = QImage(); // releasing memory

with

if(!img.isNull())
img = QImage();
Its working perfectly fine now.

@mranger90 said in Save QImage from BYTE buffer segfaults ?:

try:
BYTE *buf = new BYTE[imWidth * imHeight];

So the issue turned out to be with the device itself. Changing the code as above and replacing the device solved the issue. Thanks.