Mine was under $1000...

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 (http://www.acme.com/build_a_pc/boardfinder/) 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.shtml/video_compression_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?

Juan M. M. Fiebelkorn wrote:
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.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.
Also take note that Huffy doesn't make use of SSE, just MMX.So there is a lot of speed improvement availablePlease 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.
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??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.

Obin Olson wrote:
Rob we should have a working Version of CineLink today... give me your thoughts on the convert software?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 outputI 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.

Juan M. M. Fiebelkorn wrote:
I'll correct you.SSE is integer and floating point.OK, I stand corrected. I've used MMX, but I've barely started getting familiar with SSE.
I've never talked about storing the De-Bayered data ,but the RAW BAYER data.... as if they were YV12 compressed with Huffy.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..

Juan M. M. Fiebelkorn wrote:
wxWindows ... runs on almost every available OSI've heard good things about it, and I'm not sure why I hadn't considered it for this project. I'll look into that one too. Thanks!
(Easy to use = A Good Thing)

Could someone tell me anything about the SI-3170-CL ????
It is supposed to give 2048x1536 @ 30 fps.

Why nobody talks about it?

Sounds good,

BTW, do you know what type of bayer algorithm you're going to incorporate? Variable Gradients, spline-based, Optimal recovery, etc.?

One thing I might mention is the inclusion of some sort of "blur" or filtering effect that can be variably applied (variable from none to a decent amount depending on the image, not really a gaussian blur, but some sort of anti-aliasing type blurring filter so it doesn't just create overall "softness" like a gaussian blur does, but it does soften to reduce edge artifacting or other bayer-artifacts). IMHO I think Bayer processing can really be a weak link in this whole system because that's where you get your final image from. If you don't have a good bayer algorithm, then you can have all the bit-depth you want, but you're going to be fighting all those nasty bayer artifacts that can be quite distracting, and just scream out the fact that you shot on digital.

BTW, one more thing,

Obin, the motherboard we were looking at from Kontron (the P M model with 64-bit PCI-X), how would you hook a battery up to it if it requires an ATX-type powersupply? Can that even be done without making the mechanism a behemoth? Just curious how that might be done.

Little PC nice, case, could be made to look like a shoulder cam. If you have a look through this thread, the viper thread ands my Custom camera thread, you will find references to simular devices.

There is some miss conceptions here.

For 720p RAW, 1Ghz should be enough, using MMX, SSE, GPU, the new media processing architechure that via seems to be developing, and whatever else we can milk, maybe even simple lossless routines (Huffyuv ??). PentM claims simular power consumption at 1 Ghz, so maybe it is as good, or better.

Just because it is on an itx board, doesn't mean it can't use a laptop chipset.

As I said before, whatever board and whatever case you want, the future software is meant to support a wide varitey of configurations. If anybody wants to use a laptop great, do it. But there are other people we also want to consider and serve aswell, and we are trying to do cheap entry level and professional versions for them.

Looking at the big picture, thinking of the majority of people out there, and growing this market:We want people, for the project to be a sucess, rather than a red herring, that will also give involvement, supporting products, and volume.

To get success we need it to appeal to the most people. For this we need it to be simple, reliable, professional, cheap and with good quality performance.

The majority of people are not techy computer people. Techy people, and their circles of techy/very intelleigent freinds, often miss this piont and try to get everybody else to conform to how good they are.

A big portion of people are video/film people rather than computer people, and don't want the computer hassels or the techy image, they want simple, reliable, plug and play.

People who are video/film people might mock at the techy idea of carrying a laptop around instead of a easier professional END shoulder case, and not support it.

Raise the cost and you loose most of the wanabees, prosumers, and low end local professionals (wedding videos etc). So we want cheap non laptop versions for these people aswell.


Earlier I was writing:
It might be splitting expensive hairs to use a laptop instead. The via embedded, and Antaur laptop, chips/chipset are very close to laptop versions. Unless you use the laptop intact, it is not going to be simpler. If you do, then how easy is it going to be to carry the laptop around (on shoulder strap, waist, backpack etc) corded to a camera head, then using an ENG shoulder case. To warp the laptop to another shape case you will have to break it apart and use some longer cables. It will be more expensive, and the laptop drive might be a low data rate drive that needs to be replaced with a desktop drive. And the laptop main baord may not even be much smaller than the nano itx (12*12cm size, but I think I heard of 12*8cm aswell). The other problem is that unless your using USB2, a pccard cameralink will have 20MB's less bandwidth than mini-pci. The truth is that a good nano itx motherboard will be just as low profile and low powered (or not a significant enough difference) as laptop boards except they are cheaper. If you use the PCI-E desktop bus derivative of PCCard (formerly Newcard) then you will have 266MB/s, enough for basic 24fps/24th sec shutter (48th sec requires twice the bandwith on most sensors) 8mp 8bit shooting, or 100fps/100th sec slow motion 1080 shots (10bit with require twice as much bandwidth unless packing is used) which could also be used as an electronic exposure.I am focusing on a few cases. A small sized allweather/underwater shoulder case (I want to give it long sexy lines simular to, but not the same, as the Olympus SHD case), nano itx (12cm*12cm) is preferable. A whacky styled (move over XL1) Indie special for upto 17cm*17cm boards (or newer simular sized Intel), the case for my camera project last year. The last one is a handheld model (upto PD150 in size, but handycam would be preferable) nano itx sized (or handheld portable PC). The allweather case can be designed so that any small pc, like the Little PC mentioned, can be slid inside, but this will defeat the unique cooling system, so it might need to be dropped. Some of the cases could be made to accomodate upto micro-atx size, but any bigger you might as well goto fullsized cases and dolly for them. But the work on these has yet to be started.

Originally posted by Jason Rodriguez : A 2Ghz Pentium M is very fast when you turn off all the lower-power settings. A 1.6Ghz Pentium M was out-doing many 2.4Ghz P4 Desktop systems on AE benchmarks, Cinebench, etc., so at 2Ghz, I'd expect even better performance.Very impressive, it is amazing what outside of Intel designs can achieve (they bought the Israeli company that developed the Pent M). If 1 Ghz VIA is 7w, smae as a 1Ghz Pent M, then we should also closely watch the Pent M as well. But the question is how does the MMX, SSE etc modes perform on the Pent M compared to the P$(4) that is supposed to have a special enhanced architecher for media processing. Does Intel get beat again?

Originally posted by Ben Syverson :Wayne, as we were discussing on other threads, I don't think the VIA systems can handle raw 720 @ 24fps. At least not yet. Maybe they'll come out with a kickin' 2ghz system at some point, and we can take another look. But for now, their 1ghz fanless nano boards aren't even out yet and they will be underpowered for our purposes.The software isn't ready yet, we are waiting a few months, and I think the 1Ghz nano-itx were announced a week or so ago. Use a laptop now, it doesn't matter.

On a futuristic, pie in the sky, aliens abducted my XL1 type of side note. Interesting article in New Scienctist last week.

A researcher was claiming they could, one day, make a device that uses Ultrawide band technology to deliver between 100 to 1000 Gb/s that could be held in the palm oif your hand (and probably be used as a tricorder I would say). Ultra HD could barely dent that.

Well, I guess that the SI-3170-CL is the camera Steve N. was talking about (but he called it SI-3300-CL).
Anyway here is the datasheet from a German site that is offering it now!!

http://www.ehd.de/products/cmoscameras/3.2MegaCamera.pdf

What I still can't get is: if it is the Micron sensor or not.

Juan M. M. Fiebelkorn wrote:
SI-3170-CL / SI-3300-CL ... What I still can't get is: if it is the Micron sensor or not.
Check out the SiliconImaging (http://siliconimaging.com/) site. The SI-3170-CL and the SI-3300-CL are different cameras.

SI-3170-CL (http://siliconimaging.com/3170%20Specs.htm): 2048 x 1536 Resolution 1/2” Imaging Format, 3.3um Pixel
12 Bits per Pixel (Dual-Tap)
100Mpixels/sec Throughput
30 FPS Sequence Capture at full resolutionSI-3300-CL (http://siliconimaging.com/SI-3300%20Specs.htm): 2048 x 1536 Resolution
1/2” Imaging Format , 3.2um Square Pixel
Rolling Shutter, Progressive scan
10 Bits per Pixel, 48MHz Sampling
QXGA(12fps), UXGA(20fps), SXGA(27fps) & XGA(43fps)

Note that the 3300 can get only 12 fps at its full resolution.

So?

There comes my confusion.....

Steve wrote a couple of times 3300, then appears the SI-1920HD and so on..

And I still can't understand why we aren't talking about the SI-3170CL

I accidentaly posted to the wrong thread before:

Originally posted by Obin Olson : 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...It should be a lot easier to extend this to 10+ bits in code or FPGA, then design a new one.

I agree with Jaun, with MMX, SSE etc and all maybe Huffy canbe made to work (impresive it gets so far without it).

It is best to keep it in bayer for master accuracy aswell.

Thanks

Wayne.

Juan M. M. Fiebelkorn wrote:
And I still can't understand why we aren't talking about the SI-3170CLPerhaps Steve accidentally said 3300, because it really is not suitable at all.

We have talked about the 3170 a lot, and Obin was considering it. The problem is that scaling from 2048 -> 1920 is not a simple pixel "binning" proces, it requires interpolation. Or else you have to "window" it -- losing some pixels, but worse, you have a smaller chip area so your DOF is worse as well.

For HD, the AltaSens (SI-1920) is definitely a better choice.

Oh, thank you Rob, indeed.I was really lost :).

I've been testing the Elphel's camera 313 wich uses the same Micron sensors, and it is very sensitive, really.
If you set an exposure higher than 10 ms, everything gets blown out!!!!.

What would be the problem of using it at 2048x1536?
Anyway we need to apply heavy processing on the images after capture to De-Bayer them, so adding to this a simple crop and a Lanczos resize to 1920 won't be bad.
The other advantage is we could use an anamorphic adapter anytime!!!!! ;)


hahahahaha, sorry.I see the problem now!!
It would give as at least 108 MB per second (suppossing we get only 12 bits and not 16) @24 fps.

Juan M. M. Fiebelkorn wrote:
It would give as at least 108 MB per secondYes, the data rate would certainly be higher. The image quality might be marginally better since you'd be downscaling from a higher resolution after the Bayer filter. But I suspect that the AltaSens chip is going to be better quality overall anyway.

<<<-- Originally posted by Juan M. M. Fiebelkorn : 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?? -->>>

This can be a good approach -- I'm considering it myself. Increasing luma bit depth without chroma increase in precision will result in cleaner gradients and better dynamic range in shadows and hightlight where chroma subtly is less import. 8 bit chroma will limit you a small amount for color corrections that involve increasing the saturation.

David,
But when we go from YUV to RGB, U and V planes are merged again with some portion of the higher bit depth Luma, to get the Red and Blue channels again.
So from this very moment, Red and Blue can't be 8 bit depth anymore......My thought..

There is no direct effective bit depth due to this conversion, but you are correct that red and blue will gain additional precision is luma precision is improved. Increasing luma alone does provide more quality increase than increasing chroma alone.

Do we have to go with compression? Can't we compress after the fact so that those who want uncompressed high-bit depth can have it?

If I wanted compression I'd shoot tape! :-)

Jason, you can record on tape without compression.......
Go buy a SDLT600. :)

36 Mbytes/s (72 with its internal 2:1 LOSSLESS compression)

Not trying to be agressive, but you are not the only person in this forum, so if you want it pure big and RAW, there is no problem.
That's the funny thing about this system, if you build it you can have it the way you like!!
But please let others discuss what they want. (Did I overreact :) )

Jason Rodriguez wrote:
Do we have to go with compression? Can't we compress after the fact ...So far, the two projects (Obin's and mine) are talking strictly raw, uncompressed data to disk. Period. Any talk of compression on-the-fly is for the future. (Though possibly near-future.) And I believe there will always be an option to capture raw and process offline.

Yep :-)

Sorry, I'm not really sure if this is a group software thing going on, or little side discussions. Sometimes it has felt from the traffic that group consensus was moving towards a compressed solution, but if we can do whatever we want, then that's good.

How much Jaun, any links? I have been considering the use of backuptape to archive footage (and maybe record it). One of the biggest problems with broadcast tape, is that the broadcast manufacturers control it and price it out of reach.

Thanks.

Wayne.

Wayne, I'm pretty sure an uncompressed tape system is out of your reach. :)

- ben

Google, search for SDLT.
It is a well known standard with support of the biggest computer companies.
Every new generation is backwards compatible and tapes cost around $ 45.

Is tape back-up fast enough to record to?

I think you'll have to use it as offline, and even then, it's only 130GB a tape for AIT-2, and you need SCSI for most DLT's ($$$).

SDLT600. :)

36 Mbytes/s (72 with its internal 2:1 LOSSLESS compression)
300 GB/ 600 GB that's why it is SDLT "600".

Anyway, an ultra 160 card at $400 is ridiculous against its price :) , hahahahaha....

Ben Syverson wrote:
Wayne, I'm pretty sure an uncompressed tape system is out of your reach.Why? It's only $7,750.95 (http://www.aimlower.com/best/price/OpID_mpbr/mTRN_TRN200403080325402647712262544/sfx_2233/bot.htm)!

It doesn't matter, just another option for people. It is more about saving and reusing a $1000 dollers of Hard disks per major production (we are aiming for 1080 and eventually SHD in the future) many of thousands per year, and it might be very cheap compared to buying a broadcast/digital film tape mechanism. For some professional people and indies, that is going to be a major bonus.

I posted a good Toms hardware review of tape backup on one of the threads, I think that the stats were even more impresive than the one above (I think they were way over 200Mb/s=SHD). I think they might be a lot cheaper than that device to. They are doing a Raid 5 8 drive review at the moment.

On compression/raw, they are only doing what we can do for the moment, pie in the sky, fantasy etc etc compression comes latter.

<<<-- Originally posted by Obin Olson : I guess maybe a cheap shuttle will do for now untill that board is out..>>>

Don't forget the PCI-E one.

i have a question:

..a camera that shoots at a resolution of 2048x1536 would obviously require a great deal of bandwidth and storage... however, if you were going to crop the image in post to a cinemascope format closer to 2048x900, would it be possible to design the software to only capture a window of that size??

Eric Gorski wrote:
if you were going to crop the image in post to a cinemascope format closer to 2048x900, would it be possible to design the software to only capture a window of that size??Absolutely. These sensors support "windowing," where you can choose the area of the sensor that you are retrieving. Since you are retrieving less data, you reduce the required bandwidth. (Of course, you could also choose to speed up the frame rate.)

have those people who have worked with these cameras noticed a considerable amount of strobbing when panning or tracking?

To everybody.

Another big question came to my mind.
Why Steve Nordhouser and many other people are so concerned about Sensor's seneitivity (I mean the sensors we discuss here)???
From the specs I've seen the sensors we are discussin or using here are far more sensitive than a normal e.g. Sony 3 CCD Broadcasting camera.
What am I missing here?

I need some help I will post a RAW file from our capture software and I need to know if it's full RAW as in 10bits? or is it 8bits? we don't know because we don't know what the SDK is doing it's DOCS suck..
www.cameralink.greatnow.com/raw_file.rar

The first thing I can tell you is that if it is one frame, it has been written as 16 bit.

Juan,

If you have a Mac, open up the file from within GraphicConverter. Set the filter to RAW, and then use these settings:
Grayscale, Unsigned Short, Black is $00, Intel Number Format, and then click "Guess." Voila.

Basically, the file is an array of unsigned shorts (it's 16bit) -- but I think the data is 10bit (padded).

- ben

You can put an 8 bit image into a 16 bit file. Just because photoshop shows it as mode 16 bit is not a guarantee that you have X number of bits. To be absolutely sure, look at the histogram of the image after brightening it ( multiply X 4 ). You should be no missing values.
I hope this isn't too confusing.
-Les

Les, it looks like that's what's happening. I thought the data might be 10-bit, but it seems to be 8-bit data in a 16bit file. Why the programmers/developers would let you double the file size for no gain is strange.

And you have to multiply 8 bit by a lot more than 4 to get a full-range image -- try multiplying by 256. (65536/256 == 256)

I think I made a mistake -- the file seems to be 12bit after all. You can open the file directly in Photoshop by setting the format in the open window to "Photoshop Raw", setting the bitdepth to 16, byte order to IBM PC and w/h to 1280x720. Then if you apply a Levels with the input white set to 16, you should get the whole range. If it were 8 bit, you'd have to set the input white much much lower.

After doing some tests, it looks like we have all 4096 values.

- ben

4096 values out of a 10 bit camera?
Interesting.
-Les