[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Possible mistake in builtin LCD filters
From: |
Nikita Zlobin |
Subject: |
Possible mistake in builtin LCD filters |
Date: |
Tue, 22 Nov 2022 11:03:21 +0300 |
Hello. I experimented in past with subpixel rendering (not downfeatured like sublcd) for arbitrary images. For filtering I used 3x box (in gimp — with convolution filter, just copying same value). There’s last exact way:
- scale to required subpixel resolution (for my layout — 3x horizontally, I even tried fft scaling in imagemagick until got it broken)
- shift border channel: for hrgb it’s red to right, blue to left (elementary — I will want these channels later be combined, so it’s cheaper than color-filtering, followed by pixelation and resulting need to multiply by 3, which also would lead to precision loss).
- downscale to superpixel res with nearest filtering (takes just what we need — combined result in center of each superblock).
This is at least to state my understanding of subpixel rendering.
Now about issue, which is main reason.
It seems your filters use 256 as sum value. However, such number is above 8bit limit. We already have 0 as absence, and 255 is real maximum. Thus, by using 256 as sum, we inadvertently increase final brightness by 1 (for white). There’s another interesting issue I discovered: 256 can’t be divided by 3 evenly. You solve this by giving green extra 1, but this makes tiny disbalance. In contrast — just a coincidence, but max value 255 divides to 3 without remainder, so all 3 channels may have the same value 0x55.
By the way, same coinsidence applies for 16bpc color too — value of 2^16-1 evenly divides to 3 (of course, noone would notice such difference, but why ever allow such imperfectness without reason).
I guess, error of using 256 as max may go from mistake of how would you convert between different value formats, including floating: I had such issue when coded tint2, and found existing discussed solution, that 8bit color must be multiplied not by 256, but 257 (i.e. 0x1001), as well as reverse conversion is done by dividing to same value 0x1001. This seems to be field for many confision I remember found in sites like stackoverflow and unixexchange, and I recognized it in case of FT LCD filters too.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Possible mistake in builtin LCD filters,
Nikita Zlobin <=