Hi, thanks for the reply...
I stopped trying to swap bit planes because simply swapping the green channel between the Left / Right images worked quite well.
I actually got the Colorflipping mode working (flicker was hugely reduced and 3D depth was much better). The only problem was that the image was fairly dim on my projector when Colorflipping was enabled...
This is due to my projector having a 4x colour wheel which meant the effective shutter rate of the glasses increased to around 210Hz!! I tested it with Elsa glasses, so I see now from your test bench results that the Toff period of 4.56ms is almost as slow as the 210Hz period of 4.76ms. The glasses just can't keep up!
So, for people with fixed 60Hz projectors and 2x or 3x colour wheels, Colorflipping might still be an option for big improvements in S3D. A 2x colour wheel projector would give around 105Hz shutter speed and a 3x colour wheel would give around 157.5Hz shutter speed (dependant on the color segment config of course).
I do admit that the coding might be a bit of a pain though - The controller would need to detect the start of each colour segment with a photodiode to program it for different projectors. This will be far easier in C though. (At the moment, I have to manually code the timings for my projector.)
I might come back to the Colorflipping idea at some point, but right now I'm building an improved controller based on your project so thanks again for making your schematics and code available!...
I literally just got an ATmega16 yesterday and I'm just messing with your code under AVR Studio. I'm starting to add the blue-line stuff but I've never used an AVR chip before. I just need familiarize myself with the datasheet and the different registers / timers etc. I'm sure the ATmega will work better than the PIC I was using since the PIC ran at Fosc / 4 (only 5MHz internally with a 20MHz crystal).
The only problem with blue-line decoding on the old PIC controller was due to lack of timer precision. It did work fine at a fixed resolution though.
I probably could have fixed it, but coding in C on the AVR is already SOOOOO much quicker and nicer.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
(I always used PIC assembly before).
I'll probably need to disable the nVidia IR receiver (or IR remote) stuff when blue-line decoding is enabled because I need to use the timers.
The code for counting the lines is fairly simple and is already working under Proteus VSM, I just need to use a timer to find the center of the last line, then use the comparator to detect the blue line.
btw, I just bought my first pair of wireless glasses (Samsung SSG-2100AB), do you know any tricks for finding the IR protocol as I don't have an emitter or 3DTV? Using a Gameboy seems to be an excellent solution, I'll have to give it a go...
http://furrtek.free.fr/index.php?p=crea&a=xpand&i=2" onclick="window.open(this.href);return false;
I also don't have a decent display yet (hence the Colorflipping experiments). I thought I'd give the Samsung glasses a try with Colorflipping first, then maybe buy an 85Hz projector.
EDIT: Forgot to say about the colour quality. It actually looked pretty good even when Colorflipping was enabled. I did use similar colour bar patterns to yours for testing the ghosting / delays and I didn't notice any major problems. I'm guessing the colour differences are mainly down to the differences in colour wheel configuration.
My projector is fixed at 60Hz though - am I correct in saying that your projector is doing 1.5 revs of the colour wheel per frame? Like in this PDF (page 6)...
http://cmst.curtin.edu.au/local/docs/pubs/2007-05.pdf" onclick="window.open(this.href);return false;
Your Optoma EP739 is on the compatibility list and it says that "many of the projectors which work at 85Hz actually drop the colour wheel speed down to 1.5x". This would explain the differences you're seeing in colour quality on alternate frames. Your solution to the problem was very clever though.
btw, I loved your DVI sync extractor! I didn't think it would be possible without a far more complex circuit or FPGA and I'm stunned that it was so simple. I have many questions to ask you about this, but I'll save it for another post.
OzOnE.
P.S. I think I spotted a small typo in "emit_v12.c" line 406. cons_delay_p = cons_delay_p;
![Smile :)](./images/smilies/icon_e_smile.gif)