4:4:4 10bit single CMOS HD project

[Obin Olson]

running lots of tests today on our system to pin down what is going south causing the issues we have been having for weeks..

[Rob LaPoint]

Obin, all I can say is that at 5:00 on a Friday when the rest of us are at happy hour you are earning every great reward you have coming when this project gets finished. Great work man!

[Obin Olson]

Steve N. what is the highest you think we can run the 3300rgb before noise starts to set in on the image? I need to make SURE the rolling shutter crap is not going to be an issue and I know the Altasense has a MUCH higher MHZ then the 3300rgb right? what is the most mhz we can push from the pci-x epix card?

[Obin Olson]

Kyle:

I've been analyzing data since last night. I now have a pretty good
> picture on what to do next to get this to work. For some reason there is
> some latency in writing to disk and the system does not perform at full
> speed. I will be doing some trials on this in the coming days with different
> methods of writing to disk to see if I can improve the speed. Theoretical
> speed should be sufficient, but it is not operating at full speed in
> reality. We are getting about 80MB/sec on the writing operation now, and we
> would need much more nearer to 130Mb/sec to do it in he time we have. Right
> now we have 41.66ms between frames at 24fps (1000/24). The loop overhead is
> very low at 0.013ms. Here is what is going on in this time:
>
> Framebuffer read: 9ms That is copying data from the framebuffer to memory
> via the sdk
> Packing the data to 10bit: 6.8ms
> Converting data for display: 2.5ms
> Displaying data: 3.6ms
>
> Thus our processing overhead is around 21.9ms and it leaves us
> 19.76ms for the actual saving to disk. The fastest method I have tested so
> far gives us 34.9ms for doing this. Thus the system does not work properly
> as it takes too long to save. I have some ideas to improve things in the
> frame overhead.
>
> It seems that DirectX is not helping there and by dropping it I
> might be able to gain about 1ms form the overhead. We can probably also save
> another 1ms or two so by displaying during recording at 1/8 resolution
> instead of 1/4. Another thing would be to increase efficiency of your
> memory. I do not know if you can get faster memory than what you currently
> have there, or overclock the board to get faster memory speed, but compared
> to my board you are about 3 to 4ms slower on framebuffer read than I am. You
> are faster on most everything else though. So lets say we get an extra 2ms
> from memory and CPU overclocking. That would reduce the overhead by around
> 5ms if we get lucky. I will do some test for this in the coming days to see
> if that can be done. I will also play with the parameters for writing to
> disk and research to see if there would be some high performance disk I/O
> routines that would be faster than the Windows API WriteFile that I am
> currently using. So far I have not found much on this.
>
> In the coming days I will see how much overhead I can reduce in the
> routines, and also I will see if we can get the disk throughput up. It's too
> bad that you do not have a twin disk SCSI setup as we could use them both
> and effectively get rid of the problem as using the overlapped I/O API would
> be ideal in a twin disk setup.
>
> BTW, I want to also try the overlapped I/O routines, which are a bit
> slower, but might prevent reentrancy. I will keep you posted there. We are
> getting there slowly...

our tests show 140MB/sec write speed from a disk speed test app...that is for the 2 raid sata 10k/rpm disks

[Obin Olson]

ok does anyone know if this would help us?

File Mapping: What Why When?


File Mapping is an easier and faster way to access files, once you know how to do it. It's one of the capabilities of Windows that is so good, you can't understand why so few use it.

With File Mapping you don't get a handle to use with other APIs, you get a pointer to the raw data in memory. And Windows is the one that has to worry about what part of the file to copy to memory and so on.

The unique disadvantage of this system is that you can't change the size of the file while it's filemapped. With normal file handling functions, you can execute a WriteFile at the EOF and the file will grow. But you can't do that with filemapping. You have to unmap the file, and change the size with any known method (for example, SetEndOfFile).

But the easiness of use and the speed increment is so big that you don't need to use the normal file handling functions any more. Wrap it in a class, and use files as memory!

[Kyle Granger]

Obin,
I used File Mapping on the SETI@home project, where we wanted to share a large chunk of memory between two processes. I am sure you don't need it for your capture program.
I am using overlapped file IO, and it works fine.
One thing I noticed, is that your capture is taking 21.6% of your time. This is 0% for me. This is just getting the data from the FrameGrabber card to system memory. You should not be paying ANYTHING for that. But it may be another unfixable problem with the Epix card.
Before doing a 1/8 resolution draw routine, I would first thin out your drawing by skipping one or two frames (giving you display of 12 or 8 FPS).

> Packing the data to 10bit: 6.8ms
> Converting data for display: 2.5ms
> Displaying data: 3.6ms

You want to convert your RAW data (16-bit) for the display, not the already-10-bit-packed data.

[Kyle Granger]

I have tried doing exactly what you are doing on my system: SI-3300, 1920x1080, 61.44 MHZ clock, 24.0512 fps.

Here are the CPU usage stats I get:

1) Capture and display: 16-18%.
2) Capture, display and writing: 40-44%. This is 72MB/sec, packed 12-bit. No dropped frames, I just got 2.327 GB file after recording 745 frames, 31 seconds.
3) Capture (24fps) and display (12fps): 9%.
4) Capture only: 0.25%, est. (somewhere between 0 and 1%)

Please also bear in mind that my system is slower than yours: 1.7 GHz Xeon, 3-4 year old NVidia Quadro 2 with 32 MB, AGP 4x.

[Kyle Granger]

You should consider perhaps the Pleora iPORT GigeLink. My software only works with that interface -- it can't help you out with the Epix card.

Maybe Steve can give you a good price on it! ;-)

Just a suggestion.

Longer term, especially with something like the Altasens SI-1920, you may want a frame grabber without the capture overhead, and that handles 12-bit packed data, too.

[Obin Olson]

how is your rolling shutter at 61mhz Kyle....

[Kyle Granger]

> how is your rolling shutter at 61mhz Kyle....
I don't know -- the scene was static. The vertical blanking was only 28 lines, so the scan duration of the active lines is 1080 / 1108 * 41.66 ms.
I use faster "shutter" times with the SI-1280.

[Kyle Granger]

I think you want your scantime in the range of 1/48 - 1/60 of a second.
What kind of artifacts you see is heavily dependent on what is going on in the shot.
In general, I would not use something like 1/24.62 sec. as in my little test. But for a talking head, it could work.

[Obin Olson]

I have found less then 65mhz sucks and things "lean" in the image

[Kyle Granger]

Well, you're stuck between a rock and a hard place. As you increase the clock rate, the pixel quality decreases.

You can always just grab less pixels:
1) 1920x817 (2.35:1)
2) 1600x900
3) 1280x720
etc...

This will cut you scan time (and RS) significantly.

[Obin Olson]

see Kyle that is the GOOD thing about the Epix card...I can crank it up as far as I want and still get frames every 41.6ms or 24fps....the framegrabber will just sit spitting out frames REALLY fast but that does NOT mean you need to pick them up...see?

[Wayne Morellini]

<<<-- Originally posted by Obin Olson : ok does anyone know if this would help us?

File Mapping: What Why When?


File Mapping is an easier and faster way to access files, once you know how to do it. It's one of the capabilities of Windows that is so good, you can't understand why so few use it. -->

Probably because many programmers do not think there is anything past normal programming. Real time embedded programming is a different kettle of fish, it is the real game in programming and normal programming style doesn't help that much. But, then again, remapping might be unsuitable for normal applications. I am unfamiliar with the term file mapping, I probably use a different method on my OS design.

Pick the average commercial desktop, non games, program (that is not hardware co-processing intensive (like 3D, media players etc) and you might find that it could be sped up ten times and be a tenth of the size, if it was done properly, but this is a tall order for most programmers.

I knew, for me to program a capture app that operates at max efficiency (90+%), in 3 weeks. I would have to spend upto 6 months researching, brushing up my embedded programming knowledge, and designing the best solution, before starting. To take the average programmer (that can do it) up, it might take a year of practice.

P.S. How long does the re-mapping process take?

------------------------------

When I hit reply I thought you were asking for help with the questions above, but looks like you were not. At the risk of incurring the wrath of Odin ;) , I say. You are on the right track, you are looking for the correct things now. You just have to do the research to find out the best methods. Asking here will only get you my half knowledge and whatever Kyle can throw in over that. Going to the resources I suggested (in times past) and asking on more professional forums to do with Windows Embedded Realtime would also help get to the rest of the knowledge.


[bold]<<<-- Originally posted by Obin Olson : see Kyle that is the GOOD thing about the Epix card...I can crank it up as far as I want and still get frames every 41.6ms or 24fps....the framegrabber will just sit spitting out frames REALLY fast but that does NOT mean you need to pick them up...see? -->>>[/bold]

I thought the Epix did not have a buffer, which means that it is using main memory to buffer, then you are picking it up from main memory, packing saving to main memory and saving to disk. If it does have a buffer that has space for two frames, then that is excellent. Otherwise, this might explain why capture is so high (I thought it was supposed to be 6% some time ago?). In the unlikely event that the drivers (or MB chipset drivers/bios) are not written to be the most efficient at this process, it could be really stuffing up main memory access in competition with the program. There are two options: 1. Determine it's timing, and work around it's timing. or 2. do it yourself, and establish the best timing for the system. 3. Figure out which is the fastest. 4. Write a test program to determine the best combination of methods and timings on any MB/HDD/System and use relevant methods and timings on a system by system basis. This program can run at installation/hardware change on a system to get best performance. I think ATI uses similar testing method when installing (the screen goes blank) their graphic cards. You might like to leave doing such a program until your finished.