Just a thought on speeding things up.
How about using a 16 bit lookup table to rearrange the red and green bits some like this:
m33RGB move.w (a4)+,d2 get B0The W bit would be created by the lookup table and depend on RG levels. Not a perfect
move.w (a4)+,d3 get RG
move.w (a0,d3.w),d3 use lookup table to sort RG
andi.w #$f800,d2 mask out B
or.w d2,d3 combine RGB
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
solution but maybe acceptable.
Dave Westbury wrote:
022a01c0a034$a5b7bec0$f8a701d5@default">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, n! ow 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.
