Claus wrote:

>On my Q40 it takes roughly 4 seconds. Good work, Dave! You're photon is
>now faster than pqiv (it takes 6 secondes for a 200k jpeg).

I use a 750K jpeg to check time improvement since job set up time becomes
relevant. On Q40 v0.12 was 60 seconds, v0.13 got it down to 24 seconds. Best
pqiv (from ram, no slaving overhead) was 36 (which agrees with your 4:6 ratio).
Current time is now down to 12 seconds (1:3), my humble PC, a mere P75, does it
at best in 15 seconds (using fastest PC image viewer I have).

Most of the time from v0.12 to v0.13 was saved by implementing a clever IDCT
(devised by math experts - not me!!!) and recent savings by ensuring instruction
overlap wherever possible, replacing routine calls with inline code and creating
lookup tables on-the-fly wherever possible. (Also for SGC 68020 ensuring
routines fit within 256 byte instruction cache. Still works on 68008).

>BTW, do you consider the RGB0 bit of Qx0 screen layout? This may take some time
>for pqiv to calculate.

Yes, at present (it may change, I always look for a better way) is done like
this:

RGB data from JPEG decode is stored in buffer as longword Blue,0,Red,Green
(B0RG). This makes it easy to form GRB data format by simple rotates to byte,
then word, then long. But rotates are expensive :-(

m33RGB    move.l    (a4)+,d3     get B0RG (You will be assimilated!)
          roxr.b    #3,d3        get Green G5-1, G0 to eXtend flag
          bcs.s     m33G         G0=1
          rol.w     #5,d3        get Red R5-1
          bpl.s     m33R         R0=0 (G0=0)
m33B      rol.l     #6,d3        get Blue B5-1, use B0 for RGB0
          bra.s     m33done

m33G      rol.w     #5,d3        get Red R5-1
          bpl.s     m33B         R0=0 (G0=1)
m33R      rol.l     #5,d3        get Blue B5-1
          roxl.w    #1,d3        use G0 (from eXtend) for RGB0

m33done   move.w    d3,d6        left pixel done, now do right
          swap      d6
          ...                    inline repeat of above for right pixel
          move.l    d6,(a3)+     two pixels to window save area

Where the Q40 format display word is GGGGGRRR RRBBBBBW. ie From 24 bit RGB data:
G7 to G3 becomes G5 to G1 (same for Red and Blue), G2/R2/B2 is combined to
become RGB0 (W). The criteria being if two or more bits are set then set RGB0.

A slant on this might be simply RGB0 = G2 since green contributes more to
luminance (Y) than red or blue, or both added together (on average). Also the
eye is more sensitive to brightness than colour.

Y  =  0.299  * R + 0.587  * G + 0.144  * B        (ie .299 + .144 < .587)
Cb = -0.1687 * R - 0.3313 * G + 0.5    * B + 128
Cr =  0.5    * R - 0.4187 * G - 0.0813 * B + 128

(where Cb and Cr are the chrominace components. You need to do the reverse of
these equations since JPEG decodes to Y/Cb/Cr).

I haven't tried it yet, so don't know if it makes perceptable difference, though
I doubt it'll save significant time with photon on a Q40.

Perhaps that is why PC adopted 5R+6G+5B (RRRRRGGG GGGBBBBB) ?

Regards,
Dave.


Reply via email to