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);

@helenebro QImage::Format_Mono or QImage::Format_MonoLSB will both do the job. You can then read/write 0/1 with QImage::pixel() / QImage::setPixel(). For faster access to the pixel data, if that is needed, you should use the direct accessors with scanline() / constScanline() or bits() / constBits(), but then you need to take care of the bit offsets for each 32-byte block of pixel values.

@Mikkie I am facing a similar issue. I fetch frames from linux machine(server) and displaying them on a windows machine(client). The image I see in R and B swapped. (I have use QImage to draw image onto a QWidget) QImage((uchar*)buffer, widht , height , QImage::Format_RGB888) If I dump the contents of the buffer received into a file and open it using Windows Image Viewer I observe the Colors in expected format.

Hi @I-d-na, To clarify @SGaist's point: QImage is not an image format. It is a C++ class that lets C++ programmers manipulate images. A QImage cannot be downloaded over the internet. A QImage can only exist in a program that's written with Qt. File names like "main-qimg-salad" are not related to QImage. (Yes, I know the both start with a 'Q' and end with "image/"img", but really: they are not related at all.) Now that we've cleared that up, let's get to the root of your problem. If you download a file and it's called "main-qimg-salad", it simply means that the server gave it a filename that starts with "main-qimg", but the server neglected to include the .filetype extension at the end. Therefore, we can't tell what type of image it is. See https://www.quora.com/Why-do-we-get-main-qimg-e7b0b4951d663c737e5bbf2722d23612-jpg-types-of-saving-titles-when-we-download-images-from-the-Internet for a discussion of this naming system. If you search https://www.google.com/search?q="main-qimg" you will find that most of these images are actually JPEG files. So, try renaming your file from "main-qimg-salad" to "main-qimg-salad.jpg" and see what happens.

@Donn There's no way to loselessly convert 16 bit integers into 8 bit integers, so you can't use QImage to display your image without dropping some of the information. I advise to follow @SGaist's advice and research what OpenGL provides and if that will suit your needs. PS. Please don't post multiple times the same question! I see tree distinct instances of you asking the same thing over and over again in a few hours period. http://forum.qt.io/topic/64650/display-2d-array-of-type-uint16-as-grayscale-image http://forum.qt.io/topic/64657/display-uint16-image

<0, 65535> ---> <0,255> pixel by pixel so probably not the fastest for(int r = 0; r < rows; r++) { for(int c = 0; c < rows; r++) { uchar_data[r][c] = (uchar)( (uint16_data[r][c] - (uint16_data[r][c]%256) )/256 ); } }

@as2388 Yes there is, do the drawing in another thread on a QImage and then trigger the update with that image. I'd add to @SGaist's great point - even convert the image to a QPixmap in the worker (after drawing it), and in the paint event just splat it onto the widget.

Ubuntu 14.? provides older Qt version than the one you use! You should either provide Qt libraries which are used by your application or use Ubuntu Qt libraries to build your app if you use same Ubuntu version. See http://doc.qt.io/qt-5/deployment.html

I was able to resolve the issue by changing the QCameraViewFinderSettings on my QCamera to use QVideoFrame::Format_ARGB32 @ 1920x1080. After this change, the QVideoFrame reported the proper number of mappedBytes. One interesting note, I had to QCameraViewFinderSettings.setMinimumFrameRate(0). For some reason there was a lag on the viewfinder in low light, but changing this setting fixed it.

Fixed! I posted the problem there http://stackoverflow.com/questions/33130691/qimage-and-openmp-when-updating-image-display/33133653#33133653 I needed to declare variables private for the pragma directive. So, instead of using cred, cgreen, and cblue as I was, the code becomes: int cred2, cgreen2, cblue2 #pragma omp parallel for private(cred2, cgreen2, cblue2) for ( int ii = 0; ii < nPixels; ++ii ) { cred2 = (int) 255 * red16[ii] / range; cgreen2 = (int) 255 * green16[ii] / range; cblue2 = (int) 255 * blue16[ii] / range; QRgb argb = qRgba( cred2, cgreen2, cblue2, 255); QRgb* rowData = (QRgb*) newPaintImage->scanLine(ii/naxis1); rowData[ii%naxis1] = argb; } That's all. Then all methods become strictly equivalent regarding the end result. Haven't compared speed though, which is a concern in my context.