Wow dude, you have a HAL 9000 in your bedroom! hope your name's not Dave ;-)
Whahey!It looks like the problem is actually something to do with light leaking into nearby pixels. So if you have a lot of pixels lit up, the few remaining dark ones will be half-lit-up, whereas if you have a lot of pixels dark, the few that are lit up will not be darkened (since dark isn't a thing and doesn't leak). LEAKAGE.
(,
Tue 31 Jan 2012, 19:49,
archived)
sorta?I think it's to do with the controllers attempts to interpolate colour to a brightness variable and failing horribly.
(,
Tue 31 Jan 2012, 19:53,
archived)
OohWhy would it do a thing like that? Just add the three channels and divide by the maximum brightness, how hard can it be? I mean divide by three, or something. Whatever gets you the maximum brightness when they're all 255.
(,
Tue 31 Jan 2012, 19:58,
archived)
quitebut there we are. Do you think light leakage is like, an actual thing in this context?
(,
Tue 31 Jan 2012, 20:02,
archived)
No, I think I'll abandon that theory.Why does the controller get things wrong so badly?
(,
Tue 31 Jan 2012, 20:04,
archived)
hmmn`well, in it's defense I think it's largely down to the fact that you only have 256x80 and a 1cm pitch. it then tries to render finely detailed works where 25 pixels on the image is rendered by something like 3 on the screen.
(,
Tue 31 Jan 2012, 20:08,
archived)
That doesn't account for what it did to Bob's 256x80 image.That image was already 256x80 in the first place.
(,
Tue 31 Jan 2012, 20:13,
archived)
hmmyou may be right. I think it must come down to the previously noted inability of the controllers to accurately pin down variable brightnes between 0 and 255. Coupled with viewing angle and distance.
(,
Tue 31 Jan 2012, 20:23,
archived)
Does nyan cat work fine on the real screen, or do some of the values also turn out wrong?Can I see it?
Or how about this version of the monkey animation:
I removed everything that isn't in the red channel. So now it's 8-bit, right?
(,
Tue 31 Jan 2012, 20:38,
archived)
Or how about this version of the monkey animation:
I removed everything that isn't in the red channel. So now it's 8-bit, right?
huzz and aaah!I made some changes to the contollers settings and am getting much much better results, this is how the monkey gif now renders:
(,
Thu 2 Feb 2012, 11:34,
archived)
Not that simplewww.johndcook.com/blog/2009/08/24/algorithms-convert-color-grayscale/
I prefer the luminosity method meself.
(,
Tue 31 Jan 2012, 21:24,
archived)
I prefer the luminosity method meself.
Sure, but even the basic average method produces a tolerable image, not one apparently covered in mildew spotsSee this section of the image from the big screen above?
See the dark part in the middle, that looks vaguely like a peeled banana? In the original, that has red value 173 (and zeroes in the other channels). See the light pixels surrounding it? In the original, those have red value 172 (and zeroes in the other channels). The only difference in the input is the least significant bit, but the difference in the output is really big.
(,
Tue 31 Jan 2012, 21:40,
archived)
See the dark part in the middle, that looks vaguely like a peeled banana? In the original, that has red value 173 (and zeroes in the other channels). See the light pixels surrounding it? In the original, those have red value 172 (and zeroes in the other channels). The only difference in the input is the least significant bit, but the difference in the output is really big.
HmmMaybe wraparound? Depending on how the values are handled, a value of 258 can end up as 2 (258-255). Hard to say without getting into the guts of the code.
(,
Tue 31 Jan 2012, 23:07,
archived)
Yes, I was thinking that, integer overflowexcept there's no good reason for an overflow to occur at that boundary between 172 and 173, unless there's something scaling the 172 up to some 2^N-1, and though I fiddled around with the calculator for ages I couldn't find any reasonable way for that to happen. To get the 255/256 boundary you have to scale them both up by around 1.48; so that doesn't seem to mean anything. If you multiply by three, they just miss the 511/512 boundary: 172*3 is 516. Maybe *3 and then minus 5? Why, though?
(,
Tue 31 Jan 2012, 23:53,
archived)
This is getting far too geekyThe only thing I could think of was bad handling of signed/signed bytes. Then you get wraparound/overflow at 127. Java did it to me a lot when I ported a bunch of my old c/c++ code (the bastard, *shakes fist*).
[edit] Using the luminance algorithm, 173 * 0.72 is 124(ish), which is pretty close to the boundary.
[editedit] Except 0.72 is the factor for the green channel. Fucksocks!
(,
Wed 1 Feb 2012, 0:40,
archived)
[edit] Using the luminance algorithm, 173 * 0.72 is 124(ish), which is pretty close to the boundary.
[editedit] Except 0.72 is the factor for the green channel. Fucksocks!