I gained insight from all your posts. It turns out that simply correcting the line length sorted the problem, thank you.

@JonB Thanks. I didn't know about those links. they look promising. This whole networking stuff is really new to me @Christian-Ehrlicher Thanks. So for large data, I guess QWebSocket::binaryFrameReceived() is the correct way

Maybe that QByteArray is the culprit, you could try rewrite into more vanilla standard: ... { QByteArray block; QBuffer buffer(&block); buffer.open(QIODevice::WriteOnly); QDataStream out(&buffer); ... at least you would expose more stuff to the debugger :-)

@jsulm said in QDataStream an openCV::mat serialisation...: @Dariusz What is stream here? Is it QDataStream? "Any idea what did I mess up with this ?" - well, what is not working? Yep :- ) I think I might "got it". Naturally 5 min after asking question... elemSize1() return incorrect number of channels. Looks like I need elemSize() instead. still testing. Yep it was wrong element number. Hope it helps other "serializers" out here : -)

@Dariusz Simply seek to the position where you want to read and then read the amount of bytes you need. https://doc.qt.io/qt-5/qfiledevice.html#seek https://doc.qt.io/qt-5/qiodevice.html#read-1 You can seek to the beginning of the file if you decide to read whole file.

@Christian-Ehrlicher Thanks, that was exactly my problem.

@JealousFish Yes, In Qt Creator is called “Build Directory”, where file .o are created and where you find your application. In the past I had the same issue, when I deleted the build folder the problem disappeared. Sometimes, when compiler failed and the code seems ok, I delete the builder folder and the problem disappears. I think, but it is only my idea, when this happens some files .o are locked, perhaps because I stopped the previous compile.

Ok got it solved. Since my widgets were a little "complex" as I had QDockWidget, that had QMainWindow, so that each dock widget could house sub dock widgets. The native QT storeGeometry did not work for DockWidgets and I needed storeState/restoreState, so I subclassed my widgets to work on states of my mainWindows instead of geometries. In any case it all works now. Hope this helps if any1 else tries it.

@Paul-Colby Thanks i myself did something like this :) QVariantMap json_map; const QJsonDocument doc = QJsonDocument::fromJson(output); qDebug().noquote() << doc; qDebug().noquote() << doc.array(); foreach (auto value, doc.array()) { qDebug().noquote() << value; qDebug().noquote() << value.toObject(); qDebug().noquote() << value.toObject().value("name"); json_map["name"] = value.toObject().value("name").toString(); json_map["installed"] = value.toObject().value("installed").toBool(); json_map["id"] = value.toObject().value("id").toString(); json_map["filename"] = value.toObject().value("filename").toString(); }

I found where the problem was! As Christian Ehrlicher said according to the Documentation QByteArray::fromRawData() only store the pointer to the data. That explain why it doensn't work outside the function since the data goes out of scope. Instead of using this method I used one the constructors that make deep copy of the data. And it just works fine! QByteArray data (value.dataPointer (), value.dataSize ()); return data; Thanks all!

@sierdzio and @jsulm Thank you both for the suggestions. I will work on number 4 with moving of tempfiles or using a QSaveFile.

Hi all, thanks for the assistance. The issue has been fixed. Initially i was attempting to read and write data sequentially to achieve Real Time audio playback. However, this probably caused the issue of buffer underrun. I decided to save all my incoming data into a qbytearray and then buffer qiodevice to write.

@Diracsbracket I think it should, let me try it, thanks you so much for your time!

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.

@hariny , @onek24 Since this thread was not resolved; the buffer is not open !!! your are missing two lines of code: buffer->open(QIODevice::ReadOnly); buffer->seek(0);

that is wrong way of doing it try this: QByteArray bytesArray QDataStream out(&bytesArray ,QIODevice::WriteOnly); out << someVector; //saves it //////////////////////////////////////////////////////////////////// QDataStream in(bytesArray); QVector<qreal> otherVector; in >> otherVector; //load Please note that qreal is only 99.9% safe when saving to stream and sending it around to programs built with other versions of Qt. use QVector<double> instead

@econsysqtdev QString hex(ba.toHex()); should work? PS: Note, however, that: ba[0] = 01; ba[1] = 80; ba[2] = 7F; ba[3] = 52; should rather be: ba[0] = 0x01; ba[1] = 0x80; ba[2] = 0x7F; ba[3] = 0x52;

Thanks! It worked!

So does the QT appends '\0' terminator after every append? ( For QByteArray - No.

@kahlenberg Would this be of any use: http://doc.qt.io/qt-5/qbytearray.html#toHex

Not every member function needs to be a slot. If it produces some value it doesn't sound very slottish. Consider you have a slot like QByteArray MyClass::saveData() and you connect it to some button: connect(button, &QPushButton::clicked, myObject, &MyClass::saveData). You can connect it that way but where would the byte array data go? Button is certainly not gonna do anything with it. Instead something like this seems more reasonable: class MyClass { ... public slots: //could be private or whatever void processPictureData() { savePictureData(loadPictureData()); } void savePictureData(const QByteArray& data) { /* write the data to some storage thing place */ } public: //could be private or whatever, but it's not a slot QByteArray loadPictureData() { // it could even be made static member to allow greater reusability /* do what you did and return the data */ } } Now you have a nice modular design, each piece of functionality reusable in isolation and hermetic. You can connect either of the slots to some signal. Btw. as the help in the footer suggests please use ``` around your code, not @.

Hi and welcome to devnet Check out fromHex

I figured out what is going on, sort of. download_content in QByteArray seems to contains ^M (MSDOS newline) in some parts of the file when written to dump. When written to the desired file, it does not have those. Later on, in compareDownload the QBytearray does ontain the "^M" characters and the written file does not, therefore their bytes are different by x*^M. I currently do not understand why ^M is there and then not when written and I do not know how to remove from the QByteArray in the compareDownload function. Also during my tests to figure this out, QByteArray new_contents saves to file with ^M once I added that in there to compare with QByteArray file_byte_array. Edit: Actually the regular file that becomes file_byte_array does have the ^M, but the QByteArray that reads the file lacks it.

@SGaist Windows 7 64bit/ Qt.5.4.1 /MinGw 32bit

@cybercatalyst said: This dependes on the format, which most likely adds some kind of compression. The compression result is depend on the ordering of the pixels, which may be entirely different when pixels are differently aligned after scaling. This has a direct impact on the size in bytes. So, the conclusion is that there is some dependency (image contents, format, size) -> (size in bytes), but unless you aren't using an uncompressed format I wouldn't expect to be able to calculate the inversion of that function. This would be really complicated if even possible. Thanks for the answser. I think I will have to look for using BMP format. (https://support.microsoft.com/en-us/kb/132271) It is not the best optimization but it is the most quick calcul...

@Rondog Thank you. After a good nap I figured out what I needed. Your post confirmed it. (I didn't need the toLatin1(); either.)