Mine was under $1000...

micro pc
 

Obin, do those micro motherboards for the P4 support HT and 800 Mhz FSB yet?

It sucks that the P4 Procs use so many watts!
-Les

guys, I just made a call about that nano pc board that was posted a while back... that thing is THE board its P M @ 1.6ghz has 2 SATA 1 pci-x and is 5inch x 4.5inch in size!!! PERFECT! I am going to be on the list of pre-sale testing for the board!

pci-x = 1080p 10bit!!!!! Altasens!

I guess maybe a cheap shuttle will do for now untill that board is out..This will give me time to design the camera case and have software made for it and find all the small stuff

In case it helps anyone, here's a motherboard finder page.

Obin,

Do you still have a link to that motherboard (or was it the motherboard I posted? :-|)

Huffyuv gives me an amazing speed of 80 fps for a 720x380 RGB source on an Athlon XP 2000.

So I guess on a P4 or similar, 2 GHZ and up, it should give at least 24 fps for a 1280x720.


A question to anybody who knows about the topic:

What could happen if I store Luma info with 10-16 bit depth and U and V with 8 bit depth?

What could be the final bit depht when converted back to RGB??

crossed post,sorry.



Huffyuv gives me an amazing speed of 80 fps for a 720x380 RGB source on an Athlon XP 2000.

So I guess on a P4 or similar, 2 GHZ and up, it should give at least 24 fps for a 1280x720.


So Rob, could you be able to parse data and feed huffyuv with (there is a variant of it called VBLE which uses YV12, which is ideal for the Bayer structure) three seperate planes of G, R and B??
Remember that the seperate planes of a Bayer Pattern will have the same structure of a YV12 source, which is full Green/Luma and 1/4 Red and Blue.

Well here is one possible FPGA IPcore for Steve.
It has a Huffman encoder/decoder and other things.

http://www.opencores.org/cvsweb.shtm...ssion_systems/

Juan, is that 8bit only? we really need 10bit for capture/compression - then we can bump down for 8bit editing later on...if we need anyway...

Huffman IPcore or Huffyuv?

is there a 10 bit open source realtime lossless codec available?

May be Macintosh world, but PC?


About the IPcore I don't know.

Huffyuv is 8 bit, but it is the fastest LOSSLESS OPEN SOURCE codec available.
It won't be so difficult for someone with enough assembler knowledge to adapt it to 10 bits if that is the case although I know it would take sometime.


Also take note that Huffy doesn't make use of SSE, just MMX.So there is a lot of speed improvement available...


BTW VBLE gives me a speed of above 90 fps...(oh sorry it is 8 bit too!!! =S ..... just kidding :) but the speed is real)

Here is also another COMPLETE FPGA project.

Huffman encoding.

http://www.ece.cmu.edu/~ee545/f98/swingers/index.html

Rob we should have a working Version of CineLink today... give me your thoughts on the convert software?

I had thought about adapting it to 16-bit since that would simply amount to doubling the size of the standard data type. If you were storing 10- or 12-bit data, it would simply compress out the extra zeroes.
Please correct me if I'm wrong, but isn't SSE strictly floating-point? If HuffYUV works strictly using integer math, SSE won't help in that case.
Possibly, especially if we have a very efficient Bayer filter.

Problem is, the Bayer filter expands the data by 3x immediately; HuffYUV provides a 2x - 2.5x compression, so the data has expanded, reducing frame rate to disk. Plus, HuffYUV is 4:2:2, so you've already lost some data.

This application would be developed and released under the GPL, perhaps hosted at SourceForge. The understanding would be that none of the code (except code you write yourself) would be used in a closed-source application.

Version 1
A command-line and/or very simple Windows GUI that does:

• Reads a clip in either your "raw" format and my "raw" format into a standard internal representation
• Applies a selected Bayer filter to each frame
• Converts the clip to 16-bit TIFF and QuickTime

Each of us would take pieces of the project. For example, your team might write

• the "reader" for your particular format
• one Bayer algorithm
• QuickTime output

I might write

• the "reader" for my own format
• another Bayer algorithm
• 16-bit TIFF output

... and so on. (BTW, Rob Lohman and I have been working on an open format that you might want to use also.)

Version 2

• The GUI would be based on GTK+ (free) or Qt ($1,500 for Windows) for cross-platform support.
• Realtime playback of clips

I'll correct you.SSE is integer and floating point.
If I'm not wrong SSE is integer and SSE2 is floating point.But I'm not sure.It is usually called iSSE (to avoid confusions)

I've never talked about storing the De-Bayered data ,but the RAW BAYER data.
It is extremely inefficient to de-bayer for storage purposes.
So there is no problem to store the seperate three color components as if they were YV12 compressed with Huffy.
IMHO.

OK, I stand corrected. I've used MMX, but I've barely started getting familiar with SSE.
Sorry, my bad. That sounds like a pretty good idea. I'll look into that when I have a few extra minutes :-)

Why not this, it is well known, is very stable and easy to use.

http://www.wxwindows.org/

It runs on almost every available OS..