Weird QImage pixel manipulation issue.

VRonin

If that is the only case then it's much more efficient to use the colour table

inv.convertToFormat(QImage::Format_Indexed8);
const int colCount=inv.colorCount();
for(int i=0;i<colCount;++i){
if(inv.color(i)==qRgba(0,0,0,0xFF)){
inv.setColor(i,qRgba(0x33,0x33,0x33,0xFF));
break;
}
}

Nicolas Kogler

That actually is a great idea VRonin, as flat-styled images will never really contain more than 256 colors!

Solved :).

kshegunov

@Nicolas-Kogler said in Weird QImage pixel manipulation issue.:

isn't setPixel costly?

Depends on your definition of costly. A function call, couple of ifs and a switch I don't consider to be much on the costly side.

Nicolas Kogler

We are not necessarily talking about small images here. I believe setPixel is costly when big images are involved. But thanks for that solution, too. May come in handy for small images later! :)

kshegunov

As one Donald Knuth once notably remarked:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

Which I happen to agree with. So before you know that the call to setPixel() is a bottleneck I advise you just forget this (really) tiny inefficiency.

Nicolas Kogler

@kshegunov said in Weird QImage pixel manipulation issue.:

As one Donald Knuth once notably remarked:
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

Which I happen to agree with. So before you know that the call to setPixel() is a bottleneck I advise you just forget this (really) tiny inefficiency.

I agree, but as Niklaus Wirth once stated:
'Software is getting slower more rapidly than hardware is getting faster.'
I tested it now, both algorithms work and the method with 'scanline' and 'bits' is faster, so why wouldn't I take the faster one?

btt:
I finally found the issue (I felt like this could be it for a while) for the weird rendering, but I cannot really explain why it happened, given the fact that 'c' is copied in invertImage():

void setImage(const QPixmap &img) {
    QImage c = img.toImage();
    // ... do some pixel fetching (but not manipulating) ...
    m_pm = QPixmap::fromImage(invertImage(c));
}

now with

void setImage(const QImage &c) {
    // ... do some pixel fetching ...
    m_pm = QPixmap::fromImage(invertImage(c));
}

it just works fine.

kshegunov

@Nicolas-Kogler said in Weird QImage pixel manipulation issue.:

I tested it now, both algorithms work and the method with 'scanline' and 'bits' is faster, so why wouldn't I take the faster one?

Few reasons (whether they're good is up to you to decide):

It depends on the internal representation of the data inside QImage which isn't guaranteed to be compatible between versions, while the Qt API is binary compatible between minor versions (that translates to years).
It's a (tragic) fact of life that code is read much more than it's written, so one'd be wise to opt for more readable (and type-safe) code as every opportunity presents itself.
Faster is a relative term - faster compared to what? Knuth's whole point is that you can spend months making a piece of code to run 10% faster, but if that piece of code carries 10% of the total execution time, in reality you've optimized only to remove a meager 1% of execution time. Ultimately, it boils down to profiling, finding the bottlenecks and finally removing them.

PS.
Talking about micro optimizations I'd suggest changing:

inv.byteCount() / 4

to:

inv.byteCount() >> 2

it isn't that clear and pretty though, is it?

Nicolas Kogler

Bitshifting is just plain beautiful <3

Jokes aside, of course you are totally correct. I implemented the same algorithm twice because I thought that my initial issue was caused by that. Anyways, now I am just using pixel and setPixel to interact with the data, because I agree on the readability reason with you.

@kshegunov said in Weird QImage pixel manipulation issue.:

Faster is a relative term - faster compared to what? Knuth's whole point is that you can spend months making a piece of code to run 10% faster, but if that piece of code carries 10% of the total execution time, in reality you've optimized only to remove a meager 1% of execution time. Ultimately, it boils down to profiling, finding the bottlenecks and finally removing them.

This is also a good point, but I guess it only applies to companies which actually only have spare development time. This is a hobby project, therefore I have plenty of time to try different stuff and play around with the features of Qt. Not to mention that I am 18 years old only and need to gain experience working with the Qt framework.

We shouldn't abuse this thread for these kinds of discussions anymore. You can always send me a private message, if you want. :)

kshegunov

@Nicolas-Kogler said in Weird QImage pixel manipulation issue.:

We shouldn't abuse this thread for these kinds of discussions anymore.

I tend to wander off, so that happens to me a lot ... sorry.

Nicolas Kogler

Sorry to put this back on top, but for anyone who has the same problem as I had:

The reason for the messed-up background was that after copying the image, Qt somehow converted it to a premultiplied-alpha format. Hence attempting to edit the pixels was disastrous. A call to 'convertToFormat(QImage::Format_ARGB32)' after 'copy()' should do it :).