Oh yeah about the program, its just a relatively simple vb.net app that controls Sumix's camera API. It is intended as the single program necessary to do all of the things one might do with the camera and controlled entirely by a numeric keypad. There is a recording

So basically you are running their capture engine in the background and are sending control commands from visual basic, close enough to what I meant. How long did it take you? I regretted not being on the ball with my programing skills (health) in 2004, because I figured it could be done in 3 days if you knew what you were doing in advance. I tried to tell a few people.

Wish you the best with it. By the way did you find out about the Sumix camera they were doing for us, or has somebody else got it now?

Well, time to take a break from these forums until the new HD camera information comes (the news forum has the Sony HC3 information) running out of ISP hours ;)

Thanks

Wayne.

I was wondering why you (or someone else) choose the SMX-m73 and not the SMX-150C with global shutter. Is it much more expensive?

Any progress Noah? Any ideas on that capture to RAM post (some posts up the thread)

My reason for choosing the M73 over the 150C isnt so much the price ($999 vs $800) as it is the characteristics of the chip itself. I think i went over some of this before, but basically the ibis5 is said to be pretty poor in terms of light and color performance. And I enjoy the flexibility of the M73 with more pixels although it can be more difficult to use the whole sensor area without subsampling.

As for capturing to ram, I have no problem capturing to ram, but of course it provides limited (my current system is limited to 512MB). My current capture system uses ram as a frame buffer, holding incoming frames (in groups that can be easily configured) in ram until they are written to HDD. In other words, you set X and then it captures X frames to RAM and begins writing them to HDD as soon as X frames are in RAM. This of course means that I could just set X to the size of available ram. Then I'd get smooth capture of frames at high rates until my ram is filled at which time itd start getting really jumpy.

As for progress, I am working on my program, started messing with LUTs to 8bit log data, and I am still looking into how I can securely mount my darn IR filter so I can start taking my camera out and shoot handheld.

Very interested in seeing how this develops. good work so far :)

keep us updated!

So from recent tests, ive found that my system has no problem recieving uncompressed 720x540 24p video and saving it realtime etc up to about 34fps. Also, generally it drops no frames in 960x540 24p once the HDD has spun up and assuming no other programs are running (sometimes drops a frame if i run it directly out of Visual Studio, since having the development environment running while the camera program is running eats up cpu and ram). From what ive seen, 1024x576 24p might be a little too much data for my system, but thats what i get for trying to do all this with an cacheless 1ghz intel system. My hope is that cpu is the primary bottleneck and it will be very easy do 720p or more with twice the processing power. Perhaps for now i will continue with that assumption, and focus on testing for framerate consistency and audio sync, and drop my working resolution to 960x540.

In other news, im still looking for designs to mount my mattebox and filter to the lens in a way that accomodates multiple lens diameters, and allows for focus ring rotation but still isolates from light. I've started looking at pro matte box designs because im not totally sure what the accepted method is to deal with a rotating lens front while not being able to rotate the matte box but still getting a good seal between the two. Any suggestions would be awesome.

Noah, what is your hard drive? Often hard-drives are too slow for HD uncompressed (sometimes less than 10 MB/s). We looked at a lot of Seagate rapture like drives (min 50 MB/s sustained real data right, but I would not even trust that not to drop something) every now and then). But now even cheaper lines are moving towards 33-50 MB/s.

These files that you are getting, are they made up of 8 bit pixels, or are they 8 bit pixel in 16 bit words?

I'm curious about these things, to determine the outer limit of a 1GHZ Intel system.


About your Matt Box system, there are many DIY projects on the web, and a few pages full of DIY video projects. Best to google mat box and DIY, otherwise start with goggling slr adaptors (or $14 steadycam) and follow the link lists the sites have to find other types of DIY projects. I once spent many hours doing that and came up with a number.

I dont think at this point (and I hope I am right) that the harddrive is my bottleneck. The data stream I was working with at 1024x576@24p was about 14MBps, and my WD3200JB harddrive should be able to handle 30MBps no problem, given linear writes. I bought this particular harddrive because tomshardware.com listed it with a minimum write speed about 36MBps and averages transfers around 50-60MBps, second only to the 10000rpm raptor line in terms of ATA drives (which brings greater $$,sound, power, and storage issues). If there is a problem with my HDD bandwidth, it is more likely due to limitations of the vb.net filestream methods or of my implementation of them. I have tested the drive and it does 50+MBps no problem. I even partitioned off the drive to avoid using the inner 1/3 of the cylinders (the ones that might result in the only 35MBps). And remember this drive is completely dedicated to raw video writes and avi conversions, which never occur at the same time, so these should all be linear writes. If it were forced into random writes, i think the performance would suffer so much that i wouldnt even be able to do 10MBps with consistency. I think it is more likely that at 15MBps frame captures, the cpu cannot run through the code while writing fast enough to catch all the frames sent by the camera. Someone let me know if im wrong though, because id hate to spend $300 on a mobo/cpu upgrade only to find the problem can only be fixed with a RAID.

Ill take a look at DIY matte boxes, although im worried they wont be what I need since most people making DIY matteboxes are dealing with fixed lens diameter and fixed filter thread (i have a lens that doesnt even have filter threads), and servo zoom/focus where the lens front doesnt rotate when focused and doesnt move (lengthen) when zoomed.

Fstream.h in c++ is really slow. I done tests with it about a year ago when i was following this stuff and before I started work with FPGA's and found it to be really slow and definetly not able to handle video well. What I found was that it would make out my processor and that would be the bottleneck.

But this is c++ not Visual basic, so it might be different for you. I would do some raw tests first to make sure that it is using dma to get the data to the drive.

Someone let me know if im wrong though, because id hate to spend $300 on a mobo/cpu upgrade only to find the problem can only be fixed with a RAID.

Sounds like your on the right path, what Keith says is worth noting, the stuff the drivers, etc, that ship standard, often are not the fastest. It is best to hunt down custom stuff from the suppliers, or third party. But it might be a lot of fuss, about very little, it might be a hard limit as you suspect. Thanks anyway, this gives me a good idea of the hard limit, assuming a good Intel chipset.

Thanks

Wayne.

Assuming the camera is dma (USB controller isn't, keep this in mind) and that your program is writing to the drives using dma, then your processor power should be very minimal. Probably less than 10 or 15% with a P4 chip or pentium-m chip. If for any reason things in the chain aren't DMA you have a big problem.

I'd say find out for sure that the data coming in is dma and that your drives are transfering in dma and that they are linking the dma together. It could be using dma into the proc and then the proc has to transfer all that data out to the hard drive with an entirely differnt dma channel.

Some terms I used may have been incorrect, i'm always more at the signal level anyway so its hard to figure out your problem exactly.

PC's are disjointed, that's the problem. They are like a bionic man made up different parts from different auto manufacturers slapped together, how does the blood flow smoothly around such a thing, that's my point. Very careful, accurate programming is needed to get around the problem, but the problem could be just impossible to get over. I wish you luck on increasing the frame rate.

BTW, a remote bell rings in my head about some sort of DMA system for USB devices, obviously rarely built in. USB-GO probably had it. So the question is, are there any chip-sets that have some sort of usable DMA support on USB?

You know, we could still get our USB//GigE/Machine vision camera systems, if we asked open sourced people on programming forums if they want to be involved. But I would wait to see what Red/Sumix does in the next couple of months first. Then again, a simple hard disk recording FPGA like you have, would also do the job.

Noah,

I have just looked over the Sumix software page, and realised that they have versions for QNX, for the IBIS Fillfactory sensor based cameras. It is worth asking them if they intend to produce versions for the Micron sensors, like the one you have, as QNX is one of the great embedded real time operating systems. If there are windows related performance problems, it could possibly offer significant performance gains for specific hardware (or virtually none).

Thanks

Wayne.

ok so i took someone or other's advice and went ahead and tried to benchmark my disk access code. I basically set up a mini application to write 10GB to HDD in 1MB chunks with a memorystream for buffer. in other words, 1MB chunks would be written a RAM buffer and then the ram buffer would be emptied to disk as fast as possible. This is basically what my recording program does. if i send it way too much data, the RAM fills much faster than it can empty and i get an out of ram error (i plan to clean this up but im still trying to decide how). anyway, i found that given no video stream to display or usb stream to deal with, my system could handle 32MBps (+-3%) and averaged around 40% cpu usage (20%-60% fluctuation). I was using the system.threading.thread.sleep() method to do the delays, and i think it was because of its poor precision that i couldnt get better results than that at a 10ms delay it couldnt handle the data stream and at 15ms-30ms or so it ended up at ~32MBps. if you do the math, 1MB every 30+ms (30ms delay plus some small processing time to write) should be pretty close to the 32MBps and is just a bit more data than 720p@30fps@8bpp. This makes me confident that even though i dont know anything about getting VB to do anything straight-DMA, the code is fairly efficient and it ought to be able to at least handle a 720p@24p data stream if i were to disable display and could do more with some more processing power. keep in mind that i watched cpu and ram usage while running these tests and even while running at 32MBps ram buffering never really used more than 64MB of my ~400MB RAM left over after some windows services and integrated video take some, so 32MB might not even really have been pushing the limit... any thoughts?

oh yeah, sorry im horrible at separating paragraphs

What happens to the performance and CPU usage when you turn on USB and display on individually and together? The 20% to 60% cpu swing interesting, what is it caused by, burst writing, or some Windows inefficient servicing? If you buffered 256MB before starting to write to eliminate burst writing from gaps between writes, how would performance behave? What ever the case it is likely that twice the performance could be derived from the system, but getting that would require some fancy programming experience, so it maybe worth just upgrading instead.

You could look at those Windows XP performance tuning sites I posted that I in the Digital Cinema home made camera technical thread, and turn off all the unneeded ones, and adjust the rest, and see what happens.

Thanks

Wayne.

I can't imagine Visual Basic handling this vary graciously in the way it is all
implemented (under the covers). I would not be suprised if you see a high
drop in CPU time when switching to C with the native WIN32 API doing
overlapped and asynchronous I/O

If my understanding of C or C++ were good enough, i would have started with it. I even tried C# which is an easier interface for the non-experienced and decided the learning curve was still not favorable for me. I admit some of those cpu usage stats might be off, since I ran them from the development environment so that was all open in the background. normally i have a separate windows installation with most background services and some hardware disabled to keep idle state cpu usage to near 0%. I suppose i could try it out in there, but its much easier to debug from my development installation and most of my benchmark program was quick and messy and in need of recompiling between tests.

I actually thought 40% cpu use in a 32MBps HDD transfer through visual basic on my fairly outdated system was pretty reasonable. If only i knew where to begin in making it work better. I'm almost afraid to get back into trying new buffering and recording options since it took me probably 20 tries to get one that worked as well as it does.

C# would not be much good either with such a system in my opinion. It takes
you too far away from the bare metal that you need.

The "problem" with VB in this case is that you can't tell Windows (as far as I
know) how it should do the I/O. You also can't use multiple threads to do the
buffer filling and disk writing.

I know you can call directly into the WIN32 API from VB, so that might be a
better way than to use the native VB functions, since you'll have more control.

Good luck! :)

Yes, I think I can call win32 apis directly but do I am not familiar enough with it to know what methods to use to get it to do faster writes. Perhaps you could give me an idea about what to do?

What do you mean you cant use multiple threads to do buffer filling and disk writing? do you mean its not possible or its not a good way to do things? currently my main program, for each frame, puts the frame in memory and then calls a new thread to write that buffered frame. is there a better way? perhaps using win32 api?

I actually thought 40% cpu use in a 32MBps HDD transfer through visual basic on my fairly outdated system was pretty reasonable. If only i knew where to begin in making it work better. I'm almost afraid to get back into trying new buffering and recording options since it took me probably 20 tries to get one that worked as well as it does.
Yeah, it is pretty good, but there are GB/s in lots of PC's and getting it to do the job with preview capture and write, would be great. Best bet is to write a start time and end time for each record session (even trying to write frame times to screen can hiccup things if done wrong) and try testing it on your other sterile system you have setup. It would be interesting to see what speed can be achieved on a clean system compared to the development environment. Those links from my thread might also show you new ways to configure windows, because even if you get the programming perfect the OS can still drag things around.


Rob, Noah is using the camera development API and it's engine, so visual basic should be only a small part of the performance picture.


Noah, apart from the previous suggestions I have made, if you have too many options for recording maybe you can program each combination of options into a benchmark program, and run the benchmark program to give you times in comparison to each. Still difficult, but a bit easier than individually trying each separately, also you get to keep the code and retry it when you change your system, or other things, so you can use it to see if the method your using is still the best.

Rob is probably a good person to talk to about programming stuff. Maybe you too should help each other, but then there's the other Rob, what's he upto.

The other Rob had life intervene from what I understand.

Unfortunately I simply do not have the time at the moment to help anyone
out in that regard. Sorry. However, if you (Noah or Wayne) are coming to
NAB we can sit down and do some talking there.

Noah: what VB methods are you using to do multiple threading? I'll see if I can
dig up some info on win32 api calling. But that won't happen before the end of
the week since I'll be out of town on business for the next couple of days.

Would love too, but can't afford it (and buy new camera) would be great to check out the new Red camera, wouldn't mind getting one for doco.

I support Noah's project, but seriously, I've asked Sumix and you guys what happened to their cinema cameras they were developing, everything went silent with no confirmation of death or life of it. I personally have my own project ideas for a cheap pixel shift camera with much less bandwidth than bayer.

Well NAB would be awesome, but I am not in the US at the moment and probably wont be for several months.

Regarding the variety of different ways i was writing to disk, i did do some benchmarking back when i was working on finding one that worked, and this method was by far the best. any single threaded way of writing would drop frames a lot since the camera API function that recieves frames locks up the program until the next frame is available, and then synchronous disk access functions also lock up the program until the write is done. Right now for each frame there is a memorystream buffer into which is written a frame (or set of frames) and then as soon as that returns, a delegate is called to create a new thread whose sole purpose is to write that memorystream buffer to disk. truthfully i was learning as i go, so i learned just enough about it to implement it. I believe i tried other types of threading, but this was a suggested method to do asynchronous writes, and other ways i tried to do threading ended up still taking too long to return to the main thread from calling the new thread.

In other news, I was borrowing my friend's dSLR and got the chance to compare it to my diy camera. I found that given the default LUT (which in my opinion seems to have too hard gamma) and with my UV/IR filter, my diy camera rated about iso 50 at gain 4.0, iso100 at 8.0, iso200 at 16.0 and 400 at 32.0. and there seems to be minimal noise up to about 32.0 so it is potentially useable at iso400. This was a very rough test, but it gives me a pretty good idea of the useable light sensitivity of the camera. the camera goes up to gain 128.0 (iso1600?) but that results in a lot of color and banding noise.

Hmm, from the SN ratio of the sensor, there should always be noise there, just so small it is not noticeable. If you blow up on a really big high SN screen you should notice it at no gain.

I am vary disappointed with the ISO rating of the Micron. I know, from examining the Ibis data-sheet charts, there can be huge loss of sensitivity from the filter across the frequency range. In that camera, I think it does ISO400, but should get around ISO1200 in 3 chip configuration following the chart, which is close to what the Altasens would get (upto ISO1600 from what I heard rumoured). Having a look at the SN between the Micron and Ibis sensors there is a similar difference in their ratios (though the Sumix implementation does not have a good reputation for it's signal).

Pity about that locking thing. I remember what I forgot to mention about programming, that task switching etc, has traditionally been very inefficient under the popular OS, costing even thousands of cycles for a switch. Subroutines are another problem (compile in line) and I imagine starting threads as well. The OS I am designing is designed to do switching in 1 cycle. Most programmers are unaware of the extent to which this is happening a vast number of times a second. But, if the API locks you in, there might not be a way around it, apart from requesting the company that originally made the API to upgrade it so that it doesn't. We should just ask these companies to make video recording primed API and capture program changes. Sumix must have been working on such a thing for their Cinema cameras.

Thanks

Wayne.

Noah -- I really admire what you're doing with this project. I can only give you my encouragement since I have no programming skills to offer advice. I'll soon be ordering an M73 to experiment with myself, but unlike you I'll be staying within the scope of the supplied software since I wouldn't know how to begin to modify it as you are doing. I would be interested to hear more about your decision to replace the supplied IR filtering. You said the difference in colour was so marked, it's difficult to understand why the camera isn't sold in this way to begin with! You say you continue to have problems with the filter mounting -- my own plan is to buy a Pentax K to C-mount adapter (from Edmunds Scientific) to use existing 35mm SLR prime lenses I have. I could then use commonly available filters and holders (Hoya, Cokin, etc) to screw a UV and IR filter on the front without problems.

Oscar -- I think you are interested in "conventional" RAM recording like me using the standard camera application. I have been in contact with the Sumix support team and have had many questions answered about this (a guy called Petrovich has been very helpful and always replies promply). As far as I currently understand it then, standard RAM recording with the M73 works as follows: the camera sends 10-bit RAW Bayer and the camera driver transforms this (using a conversion table) to 8-bit RAW Bayer, accumulating the footage in RAM as an smx file. Having started the recording, it either stops when you halt recording or self-stops because the RAM has filled up. Using the supplied SMXView utility, you can play the smx file held in RAM to decide if you want to delete it (flush the RAM) or keep it (save to HDD). If you want to save, the smx file is converted at this point (Bayer to RGB) to an avi file and saved to HDD at a location you specifiy. The resultant avi is 8-bit 4:4:4 uncompressed. I previously speculated (wrongly) that a utility might be needed to cleave up the RAM to allow recording, but this is not necessary: the Sumix software manages this and, for my target RAM capacity of 2 Gb, 1.5 Gb would be used for recording and 0.5 Gb would automatically be reserved for the OS. With my target video specification of 1280 x 720 x 25 fps, around 65-70 seconds can be recorded within 1.5 Gb of RAM. These figures are for 8-bit -- using the software as it is currently supplied 10-bit is only possible recording tif stills, not video to RAM. However, 8-bit 4:4:4 uncompressed video is such an improvement over DV or even HDV, along with the option of using good C-mount or 35mm SLR lenses, this is potentially an exciting camera specification. However, as Noah says (and he's using one, I haven't!), the software may not be intuitive to use.

Wayne -- I asked a couple of weeks ago about new cameras coming from Sumix and was told about the M8 series, which seem to mirror the M7 series but have slower fps specs than the M7's -- presumably aimed at the scientific/industrial sector? From this I conclude that the Altesans are not ready (though I didn't ask specifically), so the M73, which Noah is using, is still the best Sumix available for film making.

Regards,
John.

Yes, saw those, forgot to mention them, you probably would have to ask directly about the Altasens and the other camera. They seem to be pretty silent about the Altasens and the other camera.

In case I wasnt totally clear about the IR filter thing, John, this is the deal. I recieved my M73 with no IR filter at all, so it took (for the most part) monochromatic, soft images. Monochromatic because the sensor is so sensitive to IR that all color pixels are saturated with IR and the actual red/green/blue light readings became so washed out and equalized that everything was one color (which would whitebalance to nearly black and white). The images were soft because from what i understand most lenses are not designed to focus light outside of the visible spectrum into the same plane as RGB. Kind of like bad lenses have chromatic abberation that often results in blue color fringing, in IR imaging, many lenses have white IR fringing that diffuses the image a lot.

Anyway, sumix sent me a filter the screws into the c-mount behind the lens that was branded fillfactory, and it didnt seem to fully remove IR light since there was still limited color information and some image softness, also that filter messed with the backfocus (ffd) (unless maybe that is because i did not use it correctly? I just screwed it in far enough it wouldnt effect the lens position, and put the lenses on like usual) which meant I had to unscrew the lens a big to get it to focus right.

Also, keep in mind that when using 35mm slr lenses, you might have trouble finding ones that give you a usable field of view. the multiplication factor for focal length will be nearly 6x. Also, you are working with 3.2^2 um pixels which i imagine is pretty darn fine even compared to the grain size that 35mm slr lenses are designed for. Youll be lucky to find an slr lens wider than 18mm thats not very expensive and slow. and on a 1/2" sensor, even that is a mild telephoto. also, there arent a ton of front-mount IR filters around, and the good one i found is the B+W #486 which i believe comes in 62mm (which i have) and 37mm or something like that. so no matter what you will probably be dealing with step-up/down attachments for the filter.

Noah, have you tried the Tiffen Hot Mirror? It comes in the common SLR thread of 52mm. The larger ones are really expensive, but the 52mm is only $65 at B&H.

http://www.bhphotovideo.com/bnh/controller/home?O=productlist&A=details&Q=&sku=95466&is=REG&addedTroughType=search

They have lots of other sizes.

i wasnt aware of those, that could be very useful considering they come in so many sizes. Any idea what the color response looks like on them? they just dont seem very well documented. I mean the way its written they seem to be intended as a supplement to a digital camera's normal IR filter, which might not mean they are suited as a primary IR filter?

If you can find a suitable triplet condenser you can condense the full field of view and light down to the chip.

Noah -- wow, 6x multiplication for 35mm lenses. I think I originally thought: 35mm is about one-and-a-half inches across, the Sumix sensor is half-inch, so that's 3x. But of course, it's area you have to consider, so include another layer of 3x and you have 6x as you said. My widest 35mm lens is 28mm, which would become an equivalent 160mm -- perhaps ok if you're filming outside, but go into a normal size room and you'll be limited to shooting big close-ups all the time. This is no good. And I don't plan on even using all of the sensor so it gets worse. I always thought the resolution of 35mm lenses would be ok (very fine grain film can have grains of 2 microns), but in light of the excessively narrow field of view, resolution now seems achedemic. I was about to order the Pentax/C-mount adaptor but now I won't bother -- I'll be seriously looking at second-hand C-mount lenses (I don't have any any more, sold them many years ago with my 16mm gear). With small filter diameters though, I would need some serious stepping rings to get back up to 35mm size for access to SLR filters to solve the IR filter availability problem. This is annoying! Anyone know of any sources for big diameter jumps like these? Maybe two rings might bridge the gap?

With regard to how well an IR filter is blocking IR, I remember reading in a book called 'Hacking Digital Cameras' by Chick Cheng and Auri Rahimzadeh of a rough test. They said the IR block in digital still cameras is usually not total, and you find out how muich is getting through for a particular camera by using an IR-emitting TV or video remote control. With the remote about one foot from the lens, when you activate it you can see how much IR light flashes on the camera's LCD screen. If you were to do this with a camera that has had the IR filter removed, the IR flash from the remote would fill the frame. Don't know how useful this is...

Wayne -- I'd like to use 35mm SLR lenses if I could, but I don't know anything about condensors -- can you steer me to some website info on that?

Regards,
John.

Sorry John, been a long time. But if you have a look through he original adaptor threads they explore condensers for their projection screen adaptors, similar but in this case there is no screen and the condenser is one suitable to take the image from the lens. They link to a number of Optics science sites in those threads, that discuss things. The thing to watch out for (apart from bad ones that will give you various chromatic and lens aberrations) is that triplets generally are designed to correct for two primaries and either the IR or UV range, instead of three primaries. Such a triplet that corrects for the three primaries are usually ,ore expensive (hundreds even).

Now on the other side, one of the threads I posted on is an old one from virtually before the SLR adaptor thing took off. A guy on the short thread has a commercial Canon SLR lens adaptor for his XL1 that has a condenser instead of the normal hollow tube. He reports much brighter images. So it will be a thread from 2001-2003 that has XL1 and me on it, so an advanced search should find that, I was only on a couple of threads from those days.
rear screen adaptors

Wayne -- thanks for the Condensor info: I'll try and follow this up next week (I'm editing a short film at the moment).

Noah -- I rediscovered a company here in the UK which I dealt with many years ago called SRB Film Service. They sell branded filters and a huge range of stepping rings, including some they make themselves. They also make custom one-offs for you at a reasonable cost. Check out their website and if you can't see what you need email them your requirements -- they might be able to solve your IR filter attachment problem.

www.srbfilm.co.uk

Regards,
John.

Ok, remember how I said sumix's IR filter was kinda crappy? I just noticed their website had a new updated pdf on how to correctly use the IR filter. I thought, perhaps they are reading my posts and this is their indirect response to my complaints about their filter, i dont know. Anyway, it made me think maybe i just dont know how to use the filter correctly, so i set it up again, screwed it in and tried it out, and it wasnt as bad as i remembered. Granted, I still have problems with the backfocus distance, but I suppose i just need the right size washer to wedge behind the lens so it sits in the right place. Anyway, I tested the camera in a few configurations, with the rear filter sumix gave me, with that rear filter and the one that came with my computar lens (its not that good), and then with the sumix filter and my big b+w UV/IR filter. I will try to post shots to illustrate the difference, but basically its no good without a filter, much better but not amazing with the B+W filter, and then really not much worse with just the rear filter. Cosidering my difficulties with mounting the front filter, I will for now stick with the rear filter and try to find a way to adjust the backfocus. This will be a problem for my nice schneider lens since it doesnt actually fit in the c-mount all the way with the rear filter in. The schneider lens protrudes a lot past the cmount threads and that protrusion moves in and out relative to the threading when the lens is focused. maybe this will be ok with a spacer or maybe if i can figure out why the heck the last piece of glass in the schneider lens can be screwed out since it might fit if i just took out that part of the lens, but im a little afraid to mess with it.

That's good news. I'm looking forward to some new tests.

I've been doing a few tests when i had free time. John's plans to play with Sumix's standard application inspired me to look into it a little more. It's not such a bad application. Saving directly to avi is still not really a worthwhile function because i tried it a few times and it recorded at a framerate about 1/4 whatever I had the camera running at at that time. Saving to RAM (which saves to available ram and dumps it to a .smx file), on the other hand, isnt so bad. Given you have enough ram (i had only enough for about 8sec of video), it maintains the framerate well without dropped frames and when converted to avi in the smxview app, it saves the effective framerate in the avi so it should play back realtime (although its unclear how accurate that is). it doesnt use the microsoft vcm to allow you to choose an avi codec, so you are stuck with uncompressed rgb which could then be converted to something more efficient.

I've been looking at things like gigabyte's i-ram or solidstate disk raids (not unlike P2) to remove disk access lagging. I wonder if saving to a ramdisk would be as efficient as saving directly to memory (memorystream in .net) or if my lag is a problem with the filestream.

Not to much better (goes through the PCI bus) unless something is wrong, as the streaming to disk should be very streamlined by the hardware in parallel with your capture already, so slow up take speed of data by disk should not effect it (there is another possibility, if it is accessing memory a few bytes at a time to dribble it to disk that would severely break up memory performance and degrade overall performance, but I doubt in this day and age that this would happen).

So, yes it could be great, but if it is, something is not optimized in the software.

It is probably worth asking Sumix, and the manufacturer of the software, to help sort this problem out with you (streaming Bayer to disk and preview displaying at the same time). They will have the know it all expert programmers (if Sumix doesn't, the software manufacturer should). Maybe you could swing some work out of it,. They must be missing lots of sales because they don't ship their software with a friendly video capture application as standard (hardware needs 12 bit dual slope packing at minimum, head memory buffering, and even compression, which they were working on and direct to external disk caddy recording).

I just remembered something about these cameras that could affect performance, even though they have a set average data rate, unless the head has memory buffering the frame read out comes out in spurts around blanking and other operations.

Noah -- RE Schneider lens problem. I got some C-mount info from Schneider concerning their "older manual iris lenses" as they referred to them in the email. They list the 17mm Xenon f0.95 as a 2/3" format C-mount lens. They don't list a 1" C-mount at 17mm focal length (according to them for 1" it goes: 10mm, 16mm, 25mm, 50mm etc). When you say "the last peice of glass in the lens can be screwed out" I'm wondering if this is in fact a 2/3"-to-1" adaptor? If your lens-front IR blocker performs the same as the between-lens IR blocker, you might prefer to go back to using the lens-front one to avoid the Schneider rear element protruding into the between-lens blocker? The 17mm Xenon should have a filter thread diameter of 35.5mm (?). Looking at the range of stepping rings available from SRB Film service, you could make a light-tight connection for your lens-front IR filter using two stepping rings: 35.5mm to 49mm (special SRB ring) then 49mm to 62mm (standard ring). Standard rings cost between £4.90 - £5.50; special rings between £8.70 - £12.95 (I don't know what charges for overseas shipping).

John.

Yeah it's definitely a 2/3" lens but im not sure why it would have a 1" adapter, and I tried removing that piece of glass only to find the image was not focusable or usable really. That element does seem to focus the image but I think if it is inteded for adapting with another format i dont think its a c-mount. anyway for now i will use other lenses and I need a spacer to increase the backfocus distance anyway which might fix the problem if it gives the scneider lens more clearance.

Sorry i wont be able to make many updates for at least a week, I'm off traveling in France a little.

As for ordering parts overseas, i havent heard good things about recieving packages in morocco (and i dont really even have my own mailing address there). so hopefully the rear ir filter will do what i need for the time being.

Noah -- as far as I understand it 1" is the standard form for C-mount, with 2/3" and 1/2" being smaller off-shoots. I believe the Sumix lens mount is 1", therefore if the 17mm Schneider lens is 2/3", then the 1" adaptor is definately needed for it to fit the camera. I was wondering though if it's the adaptor which projects further back (into the IR blocker) than a "native" 1" C-mount lens would? Buying second-hand C-mount lenses for box cameras can be problematic; I've found it difficult to get information on different brands (like Angenieux or Bausch and Lomb) to make good buying decisions. Perhaps I should start a thread to post what info I have (which isn't much), and this might encourage others with knowledge of these lenses to contribute and build a useful resource?

Enjoy France,
Regards,
John.

I wasnt aware c-mount came with any sensor/film format specifications. I have seen plenty of c-mount lenses for everything from 1/3" (although thats usually CS) to 16mm and 1". From what I understand c-mount only relates to a backfocus distance and a screw thread spec. I really dont think the single piece of glass in my schneider lens is a relay lens that converts its image coverage to allow the same field of view in 1" and 2/3" formats if thats what you mean. In general c-mount lenses just are rated 1/3,1/2,2/3,16mm,1" to tell you what the largest size sensor you can use without vignetting. All lenses intended for different sensor sizes still fit in the same c-mount, its just a matter of wether or not you are using the full coverage of the lens. Or are you referring to something else?

Noah -- I thought when an adapter includes an optical element as you described, it suggests that the adapter is involved in redirecting light because of the difference in original coverage, though I'm probably wrong about that. I've started the new lens thread called "Call for C-mount lens info", so maybe we can find out more about these great little lenses if others join in.

Regards,
John.

Sorry ive been bad about updating lately, I was traveling and hadnt made any significant progress. But to update whats going on with my camera, Sumix has sent me the spacer I need to fix the backfocus on my lenses with the behind the lens IR filter. For now I've decided that IR filter is enough (my computar lens actually came with another IR filter so that improves the situation a little). Neither nor both, however, are as good as the B+W IR/UV cut filter that i cant get to mount on my lenses.

I've been working on the program a little, I intended to test audio/video recording at the same time to test whether the camera's framerate will allow it to sync with audio, but i found that my computer just cant really handle doing both at once. This in turn has turned me toward focusing on ram recording since that may be required to reduce cpu usage and data writing lag and since I know i want to eventually end up with resolutions higher than 1024x576. Just today I finally picked up my camera handheld and recorded some shots to check out the rolling shutter artifact. Unfortunately it reminded me rolling shutter could be a big problem depending on what i am shooting. I think I might try to play around with some settings a bit and post some videos and see if people here can give me advice as to what is acceptable in terms of rolling shutter artifacting. I will keep looking further into using blanking instead of sumix's built in functions to control framerate, since it seems likely those functions are not at all written to minimize rolling shutter issues.

Noah - any news on your project? Have you shot any more tests with the M73 camera? Rolling shutter and RAM recording results would be of great interest...
Regards,
John.

Hey I'm glad there is still some interest. I have been working on the camera on and off, but really not much lately, although I did get adapters to allow me to mount my IR filter on all of my lenses, which has so far given me good results. I have been experimenting with rolling shutter a bit, but have come to the conclusion, its not great but it will do as long as i set framerates myself. If the siliconimaging HD camera runs its rolling shutter only twice as fast as its framerate, I figure that should be good enough for my camera. this means I should be able to handle a ~20MBps data stream at 24fps. (~40MPps performance at 48Mhz, i think this has to do with minimum possible horizontal blanking limits and control data overhead, the sensor's manual seems to confirm this somewhat, but I am still not sure why my actual pixel rate seems so hard to calculate, although it is consistent) Maybe some more if i allow a little more artifacting.
Actually the main thing i have worked on lately is the LUTs, which i find to be very cool, since I can get an 8-bit log image out of my 10-bit hardware. This means more highlight latitude (subjectively) and more apparent light sensitivity. Of course 10bits linear isnt a ton to start out with but its nice to have so much control over it.
Another thing that interests me is when I looked through the micron manual, its exciting the amount of control that an be had through register programming. I hope to get into this since sumix supplies functions that allow access to the cameras registers. for example I might be able to do horizontal line skipping to get an anamorphic image, so that i could get a 960x1080 anamorphic image that uses (nearly) the whole area of the chip and is very compatible with 1920x1080 HD and fits my datarate requirements. This wouldnt be too different from the imaging of the FX1/Z1 (except mines 1/2", 24p, uncompressed dtd, 8bit log, with better faster lenses, and cheaper).
Anyway, there isnt a lot of time to work on this lately and my computer has been acting up (it seems moroccan electricity may be damaging to computer equipment) but i want to at least try to get some nice handheld test footage off the balcony of my new apartment. I also now have a new website to post it on. I'll let you know when that happens.

Hi Noah,

We're way over twice the frame-rate for the rolling shutter . . . while double is good, we're clocked much higher than that.

I think people are still subscribed to the thread, but we are just waiting to hear from you.

Jason, sorry, that was just what I gathered from the siliconimaging forums, Ari had told me that you were running at twice the pixelrate and capturing every other frame, which I imagine would lead to a rolling shutter difference of half a frame length, no? This made sense to me since I figured the camera runs at 75MHz or so which on an altasens translates to 150MP/s which would make sense for 12bit 1080/24p (~75MP/s). You're saying the silicon imaging camera actually runs at over 150MP/s? or am I missing something? I thought the altasens couldnt go past maybe 85MHz max.

Quick update:
I finally got around to playing with sensor registers directly through sumix's API. They do not provide any documentation on it, but it turned out to be surprisingly easy to do, and I successfully implemented anamorphic imaging in a matter of minutes (and after bugged sumix so much to implement it in their software). This means I can run at resolutions like 2048x1152 using the full frame skipping every other column to get a squished 1024x1152 image that is much easier to deal with in terms of data rates and using extra pixel clocks for vertical blanking (cutting down rolling shutter artifacts) . Anyway, I am excited about being able to use the whole size of the sensor and be able to run at resolutions compatible with 2k and 1080p. I've also been able to optimize the recording algorithm a bit, but still not enough to get more than 960x540 to disk at 24p with my slow slow processor. I am getting excited about my plans for upgrades, I got the idea to build a modular computer system that folds out to fit in a suitcase for a mobile editing bay and that folds up to about the right form factor to run on rails with my camera head for handheld work. I'll take some shots with the camera in the next week and post them on my new website, and I'll be sure to add updates when i return to the US and am able to start building my new and improved computer end (should end up being compatible with the siliconimaging camera head, just in case ever get enough money to afford one and get tired of working on my own camera)

This isnt anything totally new or special, but I have a video now posted:

http://www.noahyv.com/videos/01_01_01_01_xvid.avi

Let me know what you think and if there are things I am not seeing that needs to be worked on. For one, its at 960x540 which is still a bit too much for my prototype 1ghz computer for the camera(you can tell since it drops one or two frames), in the future ill probably just post 720x540 videos until i upgrade my system. Also note this is a compressed representation of uncompressed video, so any compression artifacting you see are not issues with the raw video I am capturing, just the xvid compression. Note the gamma curves which i've implemented based on some film log response curves. This was shot with vertical blanking set to more than the vertical height of the frame so any rolling shutter artifacting in this video will probably be less than when I run the camera capturing a larger frame resolution.

This means I can run at resolutions like 2048x1152 using the full frame skipping every other column to get a squished 1024x1152 image

Just curious, but will that create aliasing artifacts when you un-stretch the image? I'm assuming optically there will be "gaps" where those columns were suppose to be, so it's not exactly the same as using true optical anamorphics is it?

BTW, Your video looks great!

You should think about using a new Core Duo setup with the Yonah or Merom procs . . . there's a ton of processing performance on those machines (I mean we're doing a bunch of real-time signal processing AND CineForm compression at very high resolutions on these procs).