The real-world maximum of USB(2) depends on a lot of things. So I can't really
say much about that. Okay, let's work out the table for 24 fps @ 1280 x 720
in RAW bayer format:

1280 x 720 = 921 600 bytes per frame (in 8 bits !)
921600 x 24 = 22 118 400 bytes per second (in 8 bits!)

22118400 : 1024 : 1024 = 21.09375 MB/s

That is if you select 8-bit mode. Which you can either select or perhaps use
8-bit log where 10 bits are made to fit into 8 bits, which may be an option to
still get the higher bitdepth but stay at a lower bitrate.

For 10 or 12 bits the camera (head) can do two things. Simply store it as 16
bits or pack it. If it just give you 16 bits (which hopefully an USB head will
*not* do, but only Sumix or the SDK can answer that) you can simply multiply
the numbers by 2:

1 843 200 bytes per frame
44 236 800 bytes per second which is 42.1875 MB/s

However, if it packs the 10 or 12 bits you get:

(1 843 200 : 16) x 10 = 1 152 000 bytes per frame in 10 bit
(1 843 200 : 16) x 12 = 1 382 400 bytes per frame in 12 bit

That's:

27 648 000 bytes per second in 10 bit which is 26.3671875 MB/s
33 177 600 bytes per second in 12 bit which is 31.640625 MB/s

If you count MB (megabytes) by dividing by 1000 instead of 1024 then simply
replace my numbers in the calculations (31.64 MB/s will become 33.18 etc.)

So to give you a table with rounded MB/s for 1280 x 720 @ 24 fps:

8-bit: 21.09 MB/s
10-bit: 26.37 MB/s
12-bit: 31.64 MB/s
16-bit: 42.19 MB/s (if 10 or 12-bit or not packed by the camera head)

Hope that clarifies some stuff

p.s. this assume the data is being send in complete raw bayer form, without
any other stream data as headers or audio etc.

If you want to see a whole host of resolutions and bandwidths you can
download my Excel sheet from the URL below:

www.visuar.com/DVi/resolutionvsbandwidth.xls
(right-click, save target as)

Wayne and Rob -- thanks for your valuable imput. The way the Sumix camera/software does things is the great mystery at the moment. I'll try and find out more myself, and will be following Noah's tests with interest.

Thanks,
John.

Believe it or not I am actually starting to get some work done on this camera. Unfortunately I have reached an obstacle wherein my original plan for mounting the infrontofthelens IR filter isnt quite a working option since the lens doesnt really mount to the mattebox/filter it only sits in the hole. I am trying to figure out a way to keep the filter mounted without light spilling in between the filter and lens and that still allows me to access the focus ring. Easy solution = get a step up adapter allowing me to directly screw my 62mm filter onto my M35.5 and M40.5 (anyone know what that means in standard filter size terms?) lenses. Problem is I am in morocco and no such thing exists unless i take a trip to casablanca which i just might end up having to do. I've been searching stores for several days for something to solve my problem with no luck. I'm also open to any DIY ideas anyone has for this problem. It is incredibly important that section between the lens and filter is closed to light since the filter is very reflective (reflects IR light, thats how it works) and the sensor very sensitive to IR light. So all light must come from in front of the filter not behind it.

Also, i quickly came up with a few pictures that are now at my newer photo website:
http://community.webshots.com/user/nyvz4
(in the camera project album)

The camera is starting to look wonderful. Do you only get still frames or have you already captured clips with it?
It's difficult to see from the pictures where the IR filter is. I'd like to help finding a solution though. What's the diameter of the lens, and how far to the front is the focus ring?

Ok bit of an update. I was playing around with my camera today and with my IR filter pain, I almost forgot how many good things there are about this camera. Anyway, I have interface screenshots and a sample video showing that video capture is pretty smooth direct to disk at 1024x576 24fps on my 1ghz intel. Also note the shallow dof of my super sharp 17mm f.95 lens (did i mention it was about $1 on ebay? oh yeah i did but i just like saying that again). Anyway I output this directly to divx avi from raw bayer using my conversion program which is going to be integrated directly into the playback interface of my camera program. My program read it out as something like ~23.7fps maybe with one weird frame or two (still need to iron out all the kinks in the way my memory buffers work i suppose). Also, I think that 23.7fps really means a few dropped frames rather than non-24fps performance, so i think the frames are still 1/24th sec just a couple might be missing.

Ok here is the link for the sample video:

http://rapidshare.de/files/11809919/...01_01.avi.html

If anyone is interested in giving me a little space to keep video samples, let me know, I might even be able to do some with less compression. Ive never used rapidshare before so let me know if there are any problems.

You're doing your own capture program, congratulations, 1Ghz, sound like something somebody around here used to say. Anyway, Can you tell us more about this program, how it's programmed, what it is based on etc?

How does it perform under 720p resolution?

Noah, as you have such a good relationship with Sumix, could you ask them something for us. Previously they were supposed to be making
a camera for our needs. There was to be an Altasens based camera (very nice performer) and IBis5a based camera, with a buffer, compression engine and Gigabit Ethernet interface, that was to be released in 2004/2005. Can you ask them what happened to that? We just get big silence when we ask them.

One last thing, don't let people discourage you about programming your camera program, work professionally with expertise, and learn whatever you need to do the job properly ;)

God Bless.

Well, the first impressions are pretty good hey? No rolling shutter effect so far either. What is exactly the problem with the filter? Does the front of the lens rotate when you focus?

I certainly like the look and control I am getting from this camera. My filter problem is that the 62mm IR filter doesnt mount directly to the m40.5 and m35.5 lens threads. I can mount the filter in the matte box and fasten that in front of the lens using my rails, but then there is a lot of reflection from behind the lens. For those pictures and the video, I set the focus and then threw a black sock over the section between the lens and the filter to block out light (certainly not a lasting solution). Also I have tried using sumix's framerate function and also separately tried setting blanking myself, but the problem with 1024x576 at 2x2 subsampled is there isnt much to vertically blank and use to reduce rolling shutter, only like 192 lines of blanking... As for 720p, i experimented with that a lot before and its certainly possible just not with my little 1ghz shelton board, although i might be able to do it if i turned off display of the image to reduce cpu usage but then how would i see what im shooting. For now I am sticking to using as much of 1/2" chip as possible and doing 1024x576 for proof of concept and for development. Anything I do here will be easily scalable to 720p given a hardware upgrade which i forsee happening when i get back to the US in 4-5 months. Maybe then I'll go back to my original venice core amd cpu plan (or see what new technology i can use to my advantage).

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 and playback interface which i posted screenshots of. the playback interface reads the raw bayer videos and can skip through them and works in conjunction with a simple commandline conversion app that uses the avifile api to convert directly from bayer to any avi format using the windows avi codec dialog and sumix's lapacian debayer function. for some reason the encoded video is coming out upside down for me but im sure thats an easy fix. It's interesting because my playback program reads the bayer data fine rightsideup.

Oh yeah and dont mind the crappy look of the interface, I had to resize it for my little 800x600 screen so it looks a little funky now, it was originally designed to shoot 16x9 or 2.35:1 images on a 4:3 screen so there wouldnt be overlap of the gui stuff on the displayed video. I'll probably wait to fix it again until i get a screen that can support more than 800x600. You may notice the display cuts off some of the video that was captured, thats because it displays 800x600 and the video is 1024x576 and sumix's video display function doesnt scale the video without scaling the stream (using subsampling).

that link again for screenshots of the gui and captured stills is:
http://community.webshots.com/user/nyvz4

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.

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?

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.

RAM recording
 

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/cont...ughType=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.

35mm lenses
 

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.