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

@Bonnie Thank you very much, it worked perfectly.

@Bonnie said in QfileDialog::Getopenfilename does not open the second time and after: Remove that static. Static local variables Variables declared at block scope with the specifier static or thread_local (since C++11) have static or thread (since C++11) storage duration but are initialized the first time control passes through their declaration (unless their initialization is zero- or constant-initialization, which can be performed before the block is first entered). On all further calls, the declaration is skipped. So with the static keyword, getOpenFileName will only be called at the first time. Thanks! I just realized that I should not have copy pasted that line of code without looking at it closer. Cheers.

Rather than giving the pointer to your MainWindow instance, pass directly the pointer to your label. Basically: mainwindow->ui->label

Where exactly does it crash? Please provide a backtrace. And please read the documentation the QImage ctor: The buffer must remain valid throughout the life of the QImage and all copies that have not been modified or otherwise detached from the original buffer. The image does not delete the buffer at destruction. You can provide a function pointer cleanupFunction along with an extra pointer cleanupInfo that will be called when the last copy is destroyed.

@SGaist said in QImage from raw array of RGBA32floats ?: Hi, ARGB32 is 4 bytes hence the 32. So in your case it would rather be ARGB128. Argh this explains my confustion! Yep thats it thanks! @wrosecrans said in QImage from raw array of RGBA32floats ?: @Dariusz said in QImage from raw array of RGBA32floats ?: Format_ARGB32 Yup, that's 32 total bits per pixel, not 32 bits per channel like the GL_RGBA32F notation in OpenGL. And even then, there are also 32 bits per channel integer pixel formats that still aren't floating point. So even if you do see a 32 bit per channel format, you can't assume it's floating point if it doesn't say it explicitly. (Admittedly those aren't especially common, but formats like OpenEXR support them, and you'll sometimes see them used for things like Object-ID channels in 3D renders) Basically, every image handling API covers more or less the same basic functionality, but just different enough to make you want to rip your hair out when you try to use them together. It's not even like nothing in Qt can deal with floating point. QOpenGLFrameBufferObject supports OpenGL format names: https://doc.qt.io/qt-5/qopenglframebufferobjectformat.html#internalTextureFormat and can be FP internally. Then if you try to get a QImage from an FBO using toImage https://doc.qt.io/qt-5/qopenglframebufferobject.html#toImage-1 it will know how to do the pixel format conversion to 8bpc. You just can't get the raw FP data in a QImage. shrug. This stuff is always more work than you expect, mostly for no good reason. Argh too sounds about right! Looks like I will either have to build my own image library for format/data handling or perhaps use freeImage as my base... are there any other libraries u could recommend perhaps? I think I'll mark this issue as solved now as its Qt Limitation and me misunderstanding Qt format. Thank you all for help. Regards Dariusz

Hi, Why do you want to combine them back into and int ? If you have a ARGB image, basically you have: uchar *start = (uchar *) img.constBits(); uchar *alpha = start + 0; uchar *red = start + 1; uchar *green = start + 2; uchar *blue = start + 3; // First alpha value: uint8 alphaValue = *alpha; // Second value of alpha alphaValue = *(alpha + 4) if you want to sum them, then make alphaValue an int and that's all.

@KillerSmath That solved my problem. Thanks!

@VRonin Yes, they are, but the pixmap is just grabbed QGraphicsView's content using grab() method.

Hi, See my answer one the other thread.

Back when I was using char table to modify QImage on QT 4, each pixel was stored using 4 unsigned chars (Red, Green, Blue, transparency). I imagine it's still stored that way, so 10th pixel was represented by ptr[40], ptr[41], ptr[42] and ptr[43]. Perhaps that's where your problem lies.

@shwoods said in Alpha channel not written to bmp by QImage::save?: Did you ever get feedback on this? no, since i never asked anyone :) You can ask on the Qt mailing-list if you like.

Why create a QList and not do the conversion directly after calling CaptureImage ? Otherwise, does the library you are using to get the image provide a streaming API ?

@SolaVitae Ok then the default classes will just work. Maybe you can try with http://doc.qt.io/qt-5/qtwidgets-widgets-imageviewer-example.html

Ok, I think a clean and rebuild of the whole project did the trick. I always forget when I don't use it for sometimes. When something is doing weird with Qt you have to clean, qmake or rebuild to get everything in order. I will tag this issue as solved !

You'd need to modify Qt code to print some message when detach happens. But you will get a lot of these messages, as implicit sharing is used everywhere (all container classes, plus many more general Qt classes). You can use clazy tool to get some hints of inefficient use of shared classes, I think. One good rule of thumb is - if you pass QImage (or any other implicitly shared class) into a function, always use const reference: void someMethod(const QImage &image); Also, be careful when using ranged for loop, it can detach if container is not const.

@joeQ As per your suggesttion i'll make changes in the code on my own.Once again thanks for your help.

Hi, Can you show how your create the image that you pass to the function ? Also, can you provide a stack trace of your application crash ?

What do you think about this? int length = this->boundingRect().width(); length = (int)(((double)length * (double)value) / 100.0); QPixmap pix(this->boundingRect().width() - length, this->boundingRect().height()); pix.fill(Qt::transparent); QPainter p; p.begin(&pix); p.fillRect(pix.rect(), QColor(0, 0, 0, 120)); p.end(); gauge->setPixmap(pix); gauge->setPos(pos().x()+length, pos().y()); It works fine and the effect is the same as on example pixtures above.

You can add a widget to the scene using QGraphicsProxyWidget *QGraphicsScene::addWidget(QWidget *widget, Qt::WindowFlags wFlags = Qt::WindowFlags()).

Hi, you should be able to do so by overriding the QRectF boundingRect() const function. Just call the base function to get the current rect., and return rect.adjusted(2,2,2,2). -Michael.

I did try to open the buffer (and close it). QByteArray ba; QBuffer bu(&ba); //bu.open(QBuffer::ReadWrite); bu.open(QIODevice::WriteOnly); image.save(&bu, "PNG"); //bu.close(); //QString imgBase64 = ba.toBase64(); QString imgBase64 = QString::fromLatin1(ba.toBase64().data()); qDebug() << "image base64: " << imgBase64; qDebug can't show the base64 string for some reason because std::cout << imgBase64.toStdString(); prints the correct base64 string. I did try serval version of code before i posted here. If i read the png from file and get a base64 from it, the same happens without the buffer. qDebug won't print out the base64 string. QByteArray ba; ba = file2.readAll().toBase64(); qDebug() << "base64 from png: " << ba.data(); // nothing std::cout << ba.data(); // works I wonder why.

First, look and feel is a very vague thing. You should try to find something concrete, such as that the image is too light, too contrasty or something. I think you have not assigned a color table to the input image, which it should need just like the output image. But wouldn't the conversion have been done with that already...

Hi, QPainter can draw a QImage. So you can for example create a new Widget, subclass for QLabel for example if you want and reimplement paintEvent. Like this you work all the time with your QImage without creating another one. And better you can only update the region that changed, no need to refresh everything. I did not try it but it should work. Sincerely

Haaaaaa… I missed that… You didn't pass the pointer to the QImage data...

slightly more refined solution using the fact that QImage uses "a matrix" internally QDataStream outStream(&outputFile); outStream << image.height()<< image.width(); /* You need this to recover the image size, if not needed remove*/ QImage testImage= image.convertToFormat(QImage::Format_Mono,Qt::MonoOnly); /* 1 bit= 1 pixel*/ testImage.invertPixels(); /* black is 1 and white is 0 normally, you need the opposite so invert*/ const int bytesInWidth = testImage.width()/8 + (testImage.width()%8>0 ? 1:0); /*This is image.width()/8 rounded up */ for(int i=0;i<testImage.height();++i) outStream.writeRawData((const char*)(testImage.constScanLine(i)),bytesInWidth);

@sabativi unless it's not a bug in the image writer plugin on OS X i would suspect that your QImage/QPixmap is already invalid. Please show the code where you create and paint into the image.

Hello @raven-worx, Yes you are damn right. Saving is synchronous. The problem i was facing is that i checked just after save if the image was written. Apparently it takes some times for the image to be written on disk. I use QTRY_VERIFY_WITH_TIMEOUTand it solved my problem. Thanks again

@kevin32 Great :)

Hi, You have two memory leaks now. There's no need to allocate pixmap nor painter on the heap. i.e: QPixmap pixmap(ui->label->width(), ui->label->height()); QPainter painter=(&pixmap); painter.drawPixmap(100, 0, 50, 50, QPixmap("C:/Users/user/Pictures/a.png")); painter.drawPixmap(0, 0, 100, 100, QPixmap("C:/Users/user/Pictures/1.png")); painter.end(); ui->label->setPixmap(pixmap);