@hskoglund Yes. I also have MinGW installed separately on my computer so I could try quickly making another kit with those and see if it works.

Edit: Changing the version of MinGW in the kit worked! I tried using regular MinGW 64-bit and that made it work perfectly. Thanks so much

@Joe-von-Habsburg My example recast with a changing background:

// widget.h #ifndef WIDGET_H #define WIDGET_H #include <QWidget> class Widget : public QWidget { Q_OBJECT public: Widget(QWidget *parent = nullptr); ~Widget(); // QWidget interface protected: void mousePressEvent(QMouseEvent *event); void mouseReleaseEvent(QMouseEvent *event); void paintEvent(QPaintEvent *event); private slots: void setBackground(); private: QImage mBackground; QPointF mFrom; QPointF mTo; }; #endif // WIDGET_H // widget.cpp #include "widget.h" #include <QPaintEvent> #include <QPainter> #include <QLinearGradient> #include <QRandomGenerator> #include <QTimer> #include <QDebug> Widget::Widget(QWidget *parent) : QWidget(parent) , mBackground(500, 500, QImage::Format_RGB32) { setBackground(); QTimer *t = new QTimer(this); connect(t, &QTimer::timeout, this, &Widget::setBackground); t->start(1000); } Widget::~Widget() { } void Widget::mousePressEvent(QMouseEvent *event) { mFrom = event->position(); mTo = mFrom; } void Widget::mouseReleaseEvent(QMouseEvent *event) { mTo = event->position(); update(); } void Widget::paintEvent(QPaintEvent *event) { QPainter p(this); p.drawImage(event->rect(), mBackground); if (mFrom != mTo) { QPen pen(Qt::red); pen.setWidth(3); p.setPen(pen); p.drawLine(mFrom, mTo); } p.end(); } void Widget::setBackground() { QPainter p(&mBackground); const QRectF rectf(mBackground.rect()); QLinearGradient grad(rectf.topLeft(), rectf.bottomRight()); grad.setColorAt(0, QColor::fromRgb(QRandomGenerator::global()->generate())); grad.setColorAt(1, QColor::fromRgb(QRandomGenerator::global()->generate())); p.fillRect(mBackground.rect(), QBrush(grad)); p.end(); update(); }

I have made continuous attempts and discovered some patterns in color conversion. The official documentation of QCursor mentions Qt::color0 and Qt::color1, which indeed follow certain rules. However, I found that the results I obtained are the opposite of the bit values.

As mentioned in my comments, I am currently inverting the bit values of the Windows original AND mask and XOR mask to match Qt::color0 and Qt::color1 as mentioned in the QCursor documentation.

/** * type: MONOCHAROME has (AND bitmap) and (XOR bitmap). * 1 bit = 1 pixed * * Windows: * AND bitmap XOR bitmap Display * 0 0 Black * 0 1 White * 1 0 Screen * 1 1 Reverse screen * * QCursor: * The cursor bitmap (B) and mask (M) bits are combined like this: * B=1 and M=1 gives black. * B=0 and M=1 gives white. * B=0 and M=0 gives transparent. * B=1 and M=0 gives an XOR'd result under Windows, undefined results on all other platforms. * Use the global Qt color Qt::color0 to draw 0-pixels and Qt::color1 to draw 1-pixels in the bitmaps. * * Actual results: * 0 0 Black * 1 0 White * 1 1 transparent screen * 0 1 Reverse screen */ int size = pCursorData->width * pCursorData->height / 2 / 8; if(pCursorData->dataLen / 2 != size) { qWarning() << "[CMouseModule::SetServerCursor] set Cursor Data dataLen failed."; return; } QImage image(pCursorData->width, pCursorData->height / 2, QImage::Format_Mono); QImage maskImage(pCursorData->width, pCursorData->height / 2, QImage::Format_Mono); if(image.sizeInBytes() != size) { qWarning() << "[CMouseModule::SetServerCursor] bitmap size not eq Cursor Data image size."; return; } uchar* imageBits = image.bits(); uchar* maskImageBits = maskImage.bits(); int pitch = pCursorData->dataLen / pCursorData->height; bool andPixel; bool xorPixel; // // `height` is 2 bitmap; for(int y=0; y < pCursorData->height / 2; y++) { for(int x=0; x < pCursorData->width; x++) { quint8 bitMask = 0x80 >> (x % 8); quint8 uint8_x = x / 8; // width is bit size andPixel = pCursorData->pixelData[y * pitch + uint8_x] & bitMask; xorPixel = pCursorData->pixelData[(y + pCursorData->height / 2) * pitch + uint8_x] & bitMask; if(!andPixel && !xorPixel) { imageBits[y * pitch + uint8_x] &= ~bitMask; // 0 maskImageBits[y * pitch + uint8_x] &= ~bitMask; // 0 } else if(!andPixel && xorPixel) { imageBits[y * pitch + uint8_x] |= bitMask; // 1 maskImageBits[y * pitch + uint8_x] &= ~bitMask; // 0 } else if(andPixel && !xorPixel) { imageBits[y * pitch + uint8_x] |= bitMask; // 1 maskImageBits[y * pitch + uint8_x] |= bitMask; // 1 } else if(andPixel && xorPixel) { imageBits[y * pitch + uint8_x] &= ~bitMask; // 0 maskImageBits[y * pitch + uint8_x] |= bitMask; // 1 } } } QBitmap bitmap; QBitmap maskBitmap; bitmap = QBitmap::fromImage(image); maskBitmap = QBitmap::fromImage(maskImage); QCursor cursor(bitmap, maskBitmap, pCursorData->xHotspot, pCursorData->yHotspot); renderWidget->setCursor(cursor);

@friendlyQtBeginner I guess you should connect to videoFrameChanged() signal as described in documentation to make sure there actually is a frame when you call videoFrame:
"QVideoSink will provide individual video frames to the application developer through the videoFrameChanged() signal."
You can also call https://doc.qt.io/qt-6/qvideoframe.html#isValid to check whether you got a valid frame.

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!

Hi I've done something recently I've needed so my approach was:

total_len = qimg.width() * qimg.height(); std::vector<unsigned int> data; data.reserve(total_len); for(int i=0; i < qimg.height(); i++) for(int j=0; j < qimg.width(); j++){ data.push_back(qimg.pixel(j, i)); }

I needed it as an rgb pixels in order to do some image manipulations, but I believe you can also take the uchar data.

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.