Obin, 1080p has 2.25x more pixels than 720p, so new Panasonic mini camera will be 2.25x more compressed in 1080p.

Is your camera 1080p Obin? Will it use Altasens CMOS? If so. it could better than HDCAM.

Have to agree with you on that one Obin.

DVCProHD the way the Varicam does it IMHO is only a couple steps above HDV.

HDV is totally unuseable for me.

DVCProHD can be very nice, but if you push it too far, it does fall apart quickly. But the reason is not necessarily the codec itself, but the way that Panasonic records to the codec.

First off, at 1280x720, the codec is actually prefiltering to 960x720. So you're not dealing with square pixels at the native codec level.

Second, although the codec is running at 100Mb/s which is pretty nice, the images you get from the Varicam only have that data-rate when you're recording at 60fps. When you record at 24fps, you're still only using 100Mb/s, but the useable frames are only giving you a data-rate of 40Mb/s, which isn't that much better than 25Mb/s DV for a HD-size image!

That's what I actually like about the Cinealta. When recording at 24p, the camera actually changes the speed of the tape, so you're using all the data-rate the codec can support for any given frame-rate. While only 185Mb/s (including audio) for 1920x1080, at least at 24fps you still get 185Mb/s. Not something less like the Varicam gives you.

If the Varicam actually recorded at 100Mb/s for each frame-rate, you'd be singing a different tune about the compression. But unfortunetly it doesn't, so at frame-rates under 60fps, you're not getting the data-rate you think you're getting, you're getting much less. Or another way of putting it is that at 24fps, the image is 2.5 times more compressed than you think it should be.

just seen vari
 

i 've just seen a project from varicam...it's really ice to see a sooooo big picture , but as you look at midtones and not lightened area you see noise noise and noise ...not even try to adjust gamma ;)

Radek: we will use Altasense yes..


Jason: so true..how can they still get 60k for that thing?!
ugghh and the 960 images!?!?! what the heck is that all about! what a JOKE!

I wonder what the new little panasonic will be like? if it was VariCam quality level for the 10k they are going to ask I would say that is about the right price..

so...looks like we have some weird things happening in our system..seems that we have some strange delays and timming issues...we are looking into it now...more when I get some info...

Well Obin, the Varicam is 5-6 year old technology.

HDCAM prefilters as well to 1440x1080 instead of the full 1920x1080 raster.

The only tape formats right now that do not pre-filter are HDCAM-SR (brand new), and Panasonic's D-5. Except for the Panavision Genesis, there are no camera's with built-in HDCAM-SR recorders.

I did see a prototype for a P2-based D-5 recording camera though at last year's NAB. Approximately the same form-factor as the Varicam. With FILM REC mode, that should be a very interesting camera, as long as it does 1920x1080/24p.

Jason what do you shoot anyway? are you a feature DP? high-end commercials? pron?(gotta be as the "fleshtones" are not good enough with 4:2:2 HD)

LOL :)

Short films (up to half-hour) and commercial/special effects stuff right now. Would like to move up to features in the future, but right now my main line of work is in post production, directing, and visual effects supervision.

I'm more of a Director/Visual Effects Supervisor that DP's, rather than just a pure DP.

Try to shoot on the highest-end formats I can for special effects stuff, which is typically right now a Cinealta with high-end lenses (such as Digiprimes or the HD Primo, haven't used the new Fujinon HAe-series yet so can't comment on those) into a disk-based DDR system for uncompressed 4:2:2 or 10-bit 4:4:4 recording to DPX files. Love to shoot with a Viper, but haven't gotten the opportunity yet.

When on location, I just shoot HDCAM right now, or 16mm. Very little 35mm work around here.

And I definitely don't shoot porn ;)

Jason,

I have to agree with you. After I was told the spec of the format I quickly realised that everything was not as good as it seemed (though I did read that it was supposed to be 10 bit recorded). 6.?:1 is only going to be equivalent to 13.?:1 Mpeg2 compression at the most (maybe a bit better for motion). If they went to Mpeg2 at 100Mb's instead, then we would be getting a clear winner.

But it turns out that the new JVC will do uncompressed out upto 60fps, and talk that the Pana might do the same. They are still 1/3 inch chips though. So a documenters delight they may stay.

Awesome Jason...about like myself...I would say I am more the pure DP/Editor though as my brother does all the effects/animation/compositing/greenscreen/motion tracking etc on our work ;) sorry 'bout the porn..it was a joke trust me...

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

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!

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?

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

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!

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.

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.

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.

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

> 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.

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.

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

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.

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?

<<<-- 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.

> ...I can crank it up as far as I want and still get frames

Yes, I know what you are saying.

There is a limit for the camera, though. The noise etc. in the pixels at some point become unusable, the CMOS pixels don't reset fast enough. I think you are already close to the limit at 65 MHz

The Epix card probably maxes out at 85 MHz.

> I thought the Epix did not have a buffer,

Yeah, I think Wayne is right here. If you're on a 64/bit/64MHz PCI slot, then burstiness is not an issue (528MB/sec max bandwidth).

misc. note:
With the GigelLink, I have a maximum bandwidth of about 120MB/sec (the limit of gigabit Ethernet). But there is a 16MB buffer, so the burstiness can be smoothed out.

With the SI-1300, I also run the clock high, and add lots of vertical blanking, all with the aim of reducing rolling shutter. But often with a resolution of 1280x692.

Kyle (a good chunk of this is for other people readers to read, thus some of the explanation)

Because they are trying to file so close to the limit of the drives, burstiness on the drive save canbe a problem, inducing misses and waiting to re-access the track. But as they are already getting 80MB/s out of a maximum of 140MB/s it may not be such a problem in their system.

But like traffic on a freeway, a little bit of a problem can ripple through and cause greater problems somewhere else (how many control points some of these programmers must use, must be staggering). But simply dumping the information from the control points to the display can upset everything, so best to build a log data structure in memory, oner page at a time (kept in cache). But ti shouldn't be that drastic here. Obin, just realise that even testing can effect your results, so have a version without it to compare if things look a bit strange.

I think burstiness of memory access can also have an affect. Let's assume that the driver writer isn't experienced and the driver is writing out data in dribs and drabs or some other non optimised size. That would (on a system like this with high memory traffic from competing parallel sources) stuff competing processes memory access. Memory is optimised for writing memory in chunks, and the Rambus memory, on various Intel boards, much more so. So it is best to write at least a memory page at a time, and probably bigger (the details are not in my head at the moment). If they write smaller than a page, the setup overhead for the write access goes up, writing a few words of memory at a time, can make it go through the roof (never to be seen again sort of hight) as other processes can steal memory away to access a separate page. Writing a string of pages at a time would reduce the overhead a little more. Now lets hypothetically think that the driver writer does not block other processes from stealing memory control away during page writes. So now you have odd sized writes competing with each other, with massive overheads.

Running a program from main memory instead of cache, is many times slower. Having a loop that crosses the page boundary produces overhead. This is why I say keep the code in the cache and leave main memory for the card, chipset, graphics and disk to manage among themselves (not forgetting that you need to pack and preview from it too). Because these devices should be programmed to write in optimised chunks, this will reduce overheads in main memory. You have three processes putting in and out of memory in parallel at one time. Although the data-rate might be a fraction (under 600MB/s) of the available to main memory, having memory conflicts will add significant overheads. There is enough room for many of these things to be done in parallel, in the background, and hardly effect the processor load. The trick is controlling and keeping the processor out of the way (working around each other).

Now all this can lead to burstiness in memory, that will translate to burstiness in execution and drive writes.

trying to mix up a lego
 

hi i have been asking a lot of cmos and most of them told me that i have to use a camera link interface (it seems that there is just one cameralink interface for laptop , but anyway there are no so fast hard disk to write on...so i cannot use a laptop)...i think that the tranfer rate for 1920*1080@25 10 bit is about 192MB/s isn't it?...so i started to look for a mini-micro motherboard ...and i found some of them really interesting ...the real problem is where to record...if i use a sta sata i've got 150MB/s ,but this is just the optimal...so i should implement a raid configuration with at least 4 SATA to reach 200MB/s...but in this way i have to take with myself...thimk about the weight and the volume...any suggestion?

1920x1080 @ 24p, 12-bit = 72MB/sec
@25p = 75MB/sec

Leon,

I record 1920x1080 24p with no problems, with 2-port 3ware RAID 8006 controller, and two Maxtor SATA drives. My max bandwidth is 114MB/sec

Leon may be I can explain this,

the mistake is coming from assumtion that from sensor 10*10
we getting 100 rgb pixels (as in uncompressed image).
but
a color sensor is an array of color pixels of one of 3 colors each, not of rgb, and this is called raw data.
so your calculation is 1920*1080*25(fps)*30(10*3bit)
kyle calculation is 1920*1080*24(fps)*12(bit)

i hope i havent made mistakes here :)

Leon,

Have a look over at my Technical thread I am sure I have posted a link to latest Laptop drives, or benchmarks of drives.

You will notice that fastest is around 20MB+/s min (or was that 34MB+/S). There is (apparently) also laptops with room for two internal drives (not including external).

So you can run 720p single chip (Bayer pattern, Konstantin talked about). If laptop is very fast to compress than you can do more than 720p on single drive.

What you must also realise is that drives run faster on the outer track of the drive than the inner track. So you should look for the minimum data rate that it will record. All the recording capture product will also only work on selected target computers at first, latter may work on many different computers (very hard to get it to do).

Laptops are now available with Express card, that supports upto 250MB/s each way (250MB/S read 250MB/S write simultaneous). Problem with many capture cards, no frame memory buffer, do not even out data to frame per second, but bursty, and many chips, if you want higher shutter speed, you get higher data rate. So 132MB/s struggles, but 250MB/S much better. So ask if Camera link Express Card will be available. Other good option is get a buffered Gigabit Ethernet camera (Just enough for 1080p, but compressed better). They do not normally "pack" pixels, so any pixel above 8bits, is sent as 16bit+ (more bandwidth). If you want 720p with over 8 bits than Firewire (maybe USB2.0, but USB2.0 canbe CPU hog) might do.

Apart from capture software, and fast enough, and correct, hardware, these are the issues.

Thanks

Wayne.

Any news?
 

So Obin, what's cooking? Any progress?
Just curious. :)
-Jonathon

sorry gang for the "away" I have been in pre-production for a project and will lens it Sunday..not been doing much camera work(but my programmer is and tells me we are making some good progress) I post more next week as I will have a bit of free time!


gota go make the cash that keeps the R/D machine going! can't blame me on that can you! :)

I am told today that we have enough CPU and memory speed to do what needs to be done in the amount of time we have. THis, after I ran a bunch of tests for my programmer Friday...I will be out all day Sunday on a shoot and report in on Monday....

a toast to our progress!

Well, Mike over at http://www.hdforindies.com/ has a lot of interesting information about digital cinema it's raw formats and JP2K compression.

Competitive analysis:
(This just turned up)

JVC has released it's new HD camera, which is good news for us (though I would keep price down):
http://www.camcorderinfo.com/content...00U-24P-HD.htm

$6K+, 1/3" 3 chip, MinDV, optional module to take uncompressed signal to HDSDI, 720/60p. Nice package (the Panasonic does not look as nice and has 1440*1080 mode) professional features, but once you go raw it is going to cost a pretty more penny than it presently does. They will sell to video people, but our product should be clearly superior for Indies. But I think this is a Milk Cow to get money in. This means that it may have the latitude to drop half in price in the future (the uncompressed recording canbe also cheaply worked out) if the competition demands it. So we might have to compete with a $5K, uncompressed to disk, name brand, pro ENG like camera system that would probably give at least the image quality of the Micron 1.3MP with none of it's faults, in the future. But video people like already worked out name brand products.

So, for the moment, good news for us.

Wayne.

Dear Wayne
 

so as Pana and Jvc are out and Sony who ever knows
so as there a rumours that Pana will also record on a harddrive and even Juan is on the show...so
why should we spend $$ to build a single Cmos cam
a cynic one

Ronald has been for month's away sailing
on a 17m wooden gaffer from 1908 a restored
Norwagian fishing boat. That was for real
and no electronics beside radar and radio

Ronald, we expected to hear from you months ago.

The JVC/PANA is expensive pieces of .., for Cine shooting, fine for videoing and Wedding market, will sell. Now the bottom line of what we are doing is less for more quality. Add an HD-SDI card, computer and software (or Linux stuff) to the JVC/Pana and watch the price go up. There is still a question as to the actual resolution of the Pana (which looks less than true 1080, and the Pana HD tape codec had even less and I am yet to here what format this camera will have). So would I bet Obin's or Sumix's Altasens ($3K) single chip camera should be able to beat this, yes? I have not seen output of this camera yet, but believe it would be better than the Sony HDV, but still not compared to the Altasens.

Get this, I hear the JVC Altasens camera shown at NAB last year, will be delayed until NAB next year. So what is this, more Altasens delays (Obin has one, but this is small volume for developers, but where is mass volume)? Maybe they are waiting for cheaper/better sensor next year. They do 1/3rd inch semi pro camera (I like, but the price) not the normal low end 1/2 inch ENG camera (I love). We need Cine camera enclosure like JVC HD100 in features/style. These are latter generation HD chips so we can expect that they will have good picture for sensor size. Sensor size is not the complete picture on performance, technology and refinement increase performance closer to old bigger sensor. On cheap camera we also see dumbed down performance (look at the quality Juan's "Film Stream" compared to original DVX100 1/3). I also work on adaptor to make little sensor increase performance, SN ratio is the only thing I cannot solve. I think maybe Foveon X3 sensor camera (in extra wide cine window).

I hear Altasens from Sumix sooner, and then latter :(

Problems with sensors is, technology spread. Fillfactory have some useful features, Altasens has other useful features, Smal has others, x3 has others, but none has all. So each has own compromises affecting performance. Fill now has Smal, Altasens and X3 are the main ones I know, if only one would buy out another we would have one or two good sensors.
----------------------------------------------------------
Just announcing new Pope on TV, Joseph Ratzinger (we had better be nice to Rai and Ronald now ;) ).

Maybe stupid
 

I do wonder what type of imager is working in the Pan wondercam. The Arri will have a custom 6M from fillfactory