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.