Rockbox mail archiveSubject: Re: Still images
Re: Still images
From: [IDC]Dragon <idc-dragon_at_gmx.de>
Date: Mon, 19 Jan 2004 10:51:39 +0100 (MET)
> I chatted briefly with Dogger on irc last night about the display of still
> images ...how many grey scales do we achieve?
As I wrote before, this is no firm number. It's a smooth transition of what
you perceive as grayscale to flicker.
Did you view grayscale.rvf ? from:
Move your viewing angle up and down, the transition also moves.
If we loop a still file, the max. amount of grayscales is # of frames + 1,
so for these looping 34 frames you can't have more than 35 shades. For a
continuous movie, there is no crisp limit to tell.
> If we run at 72fps, and given that the human eye wil perceive animation at
> 24fps, we have the option of pixel on for 0, 1, 2 or 3 periods, giving
> four grey-scale values.
No, first your eye is rather slower (that's why they play movies at 24fps,
to be above), and second I'm also exploiting that the LCD is (a lot more)
When I change a bit from 0 to 1 or vice-versa, the LCD doesn't follow that.
Instead, it does something like an exponential decay. I'm pulsing the pixels
in a way that 1) would hold them at the desired level, if they'd be _very_
slow, and 2) switch them as often as possible to avoid flicker.
Fabian does it different, he uses 6 fixed pulse rates to get 6 grayscales. I
prefer my way...
> If, however, the >4 grey-scales are an optical illusion and my math is
> correct, a still frame viewer should be able to generate the pixel values
> real time and therefore remove the prerequirement for transcoding to film
> before display?
No way, the poor box is just barely fast enough to pump the pre-rendered
bytes to the display, already coded in optimized assembler. Even for that I fall
a bit short, the display scan is slightly faster. No time left for anything
like per-pixel math.
-- +++ GMX - die erste Adresse für Mail, Message, More +++ Bis 31.1.: TopMail + Digicam für nur 29 EUR http://www.gmx.net/topmailReceived on 2004-01-19