-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
5.12.9, 5.15.0 RC
-
None
-
Windows 10
-
All
-
0e526ed3f93f9aab1f499f80d703fc4e93314223 (qt/qtbase/5.15)
It appears Qt is using different policy when convert color component.
In most of the code it is using qRound to calculate different component, but for integral value it is using floor to get the component (in unsigned short fixed point). That result in some weird result, for example:
auto hsl = QColor::fromHslF(179 / 360.0, 62 / 100.0, 37 / 100.0); auto rgb = hsl.toRgb(); qDebug() << "hsl:" << hsl; qDebug() << "rgb:" << rgb; qDebug() << "rf:" << rgb.redF() * 255 << "gf:" << rgb.greenF() * 255 << "bf:" << rgb.blueF() * 255; qDebug() << "ri:" << rgb.red() << "gi:" << rgb.green() << "bi:" << rgb.blue();
that prints:
hsl: QColor(AHSL 1, 0.497222, 0.620005, 0.370001) rgb: QColor(ARGB 1, 0.140597, 0.599405, 0.59176) rf: 35.8521 gf: 152.848 bf: 150.899 ri: 35 gi: 153 bi: 151
as you can see 35.8521 becomes 35, while 152.848 becomes 153
| For Gerrit Dashboard: QTBUG-84168 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V |
| 300142,4 | Do a proper convert from [0-65535] to [0-255] on QColor integer reads | dev | qt/qtbase | Status: MERGED | +2 | 0 |
| 302112,2 | Do a proper convert from [0-65535] to [0-255] on QColor integer reads | 5.15 | qt/qtbase | Status: MERGED | +2 | 0 |