I had some fun tweaking the tiff file obin posted. Nothing great - just a quick level and curve adjustment(s). The second image is more neutral in its color.

http://www.weet.us/test.tiff

http://www.weet.us/test1.tiff


Anyway, just thought I would share :). I definitely like having the extra room to tweak the image!

----

Interestingly the highlights on the flower seem to be blown out....

Obin,
Yes that one :).
After I apply gamma 2.2 it looks really washed out, so I must assume it is really overexposed or it has been gamma corrected.
Could you take the same image at the same hour but 1 or 2 stops darker?

You are wrong, it was not over exposed and it looks GREAT at gama 2 or 2.2 .... you MUST add contrast on the DARKS and work all your colors how you like...you will NEVER get an image you like with gamma only..gamma is not an endall/fixall solution..i'ts one of MANY steps to apply when going for your final "style" or "look"...

Yes I agree about gamma not being a fix-all. I am, however, not completely convinced that the image isn't over exposed. The image is clearly showing blow out highlights and this is only with a simple levels adjustment.... this should not be the case with normal footage.

I'm honestly somewhat confused by the images that have been pulled out of the camera. Don't get me wrong they look great and having the extra latitude is wonderous for color manipulation. There just seems to be something not quite right. I can't lay my finger on it yet though...

I blew out the road just a tad so that I could keep the really darks...just like I wanted it...I would not call that "blowout" just exposing for the darks..but maybe some will not agree...

Steve N:

what is the fastest we should have the 3300 running at in CIneLInk?

I need a max number for CInelink

Obin,
please don't get angry, I'm just saying what I found.
If I apply gamma 2.2 the image looks really bad, just that...
It looks to me it is not linear at all.That is why I asked you for another picture.Anyway, if you are so sure about everything was perfect, I believe you.
No problem , Never meant to say you were wrong :)

Hey, I was wonder has anyone tried to use the SI-1280? Also can the SDK be compiled in mingw32?

Hi all,

Just to let everyone that's contributing to this fascinating idea - I've been keeping track of this exciting thead for a while now. I'm not a very technical person so try to stay out of the discussions to avoid adding unneccesary noise...

But I was wondering: when looking at the preview window while capturing images from the camera - is there any noticeable delay or lag in the 'viewfinder'?

I guess this depends on the quality of the de-bayer and the preview resolution.

Thanks and keep it up :-)

Barend

tiny bit of "lag" yes..not much..I think it's ok to shoot with

Hey guys,
i lost track of this threat a while ago and just tried to read through the last 10 pages...
well, wasn't there some site where you put together the f.a.q.s about this project and what you have achieved so far?
i follow this as a filmmaker and potential future user and have to admitt that this is way to technical for me (of course it is...)
you guys are doing an amazing job here, this DIY ethic is highly appealing to me and i think, once you have a finished product out, a lot of filmmakers will buy from you rather than from the big asian corps...
keep on keeping on!
regards,

christian

Obin,
Could you tell me anything about your experience with the Epix FG?
Is their SDK easy to use?
Are you using Windows or Linux at this moment?

Christian Schmitt wrote:
wasn't there some site where you put together the f.a.q.s about this project
Yup, it's at ObscuraCam (http://www.obscuracam.com/wiki/static/ObscuraCamWiki.html).
Juan M. M. Fiebelkorn wrote:
Could you tell me anything about your experience with the Epix FG?
Is their SDK easy to use?I know you were asking Obin, but I've used it too ... and I'm not overly impressed. It seems to work OK, but it's cryptic and complicated. Not easy to use. It does work in Windows and Linux (haven't tried Linux yet).

I'm asking cause, day after day, I'm thinking about using a better FG, with good capabilities.
You would tell me 'Oh, those FG cost a lot more money!!', and you will be right, but if that FG has a powerfull SDK, and if it has an onboard CPU, FPGA or IDE connectors I won't need to spend more than 1,5K bucks on a pentium M 2.0 GHZ with 2 GB RAM with a PCI-X slot and a riser card to get two (working?) PCI-X slots to be able to put a RAID controller.So that money will go totally to the FG.
Anyway that seems to be like finding the Holy grail..... :(

Rumor has it that all the FG are hard to use..I have talked with some that say the EPix is easer then most!! dunno maybe is rumor ONLY...but then maybe not..;)

Update:

I should have an installer for CineLink today so that I can test on the new machine that has a GIgabyte board with full spec PCI slots. ;)

We will be testing with 3300RGB and making changes for that chip as needed...I think I will stick with this chip for a while and see how things go as the Altasense seems to be a some-time-in-the-future project still...


Steve still no word on the MAX MHZ for the 3300rgb? I really have the feeling we need to crank this puppy UP above 60mhz because I can see lots of rolling shutter at 1080x1920 @ 24fps 60mhz

Obin on clock rates:
The direct answer to your question is that we only qualify the cameras to 60MHz clock but I just tested mine at 80 and 85MHz and it was happy. I got 32 and 34fps. To do this in the XCAP GUI, you need to send strings with the serial peek and poke. These are the same strings as the SDK will use.
80MHz is lc346882
85MHz is lc31c00f

Now for the indirect answer - you will need to go to a 64 bit grabber and bus or get a grabber with a big buffer (full frame of storage) or dynamic byte packing. The Epix, and many others do not pack data. Any bit depth above 8 bits uses two bytes per pixel. 60MHz is 120MB/sec - right at the max of the PCI-32 bus.

that means we are stuck at 60mhz with the rolling shutter stuff at 1080p?? I have spent enough time and money at trying to get the epix working I cannot switch cards now unless the epix 64bit is out soon( I talked with Epix and they are saying about 2 months!)

Steve I don't care about 35fps on the 3300 all I want is the high mhz to correct for the rolling shutter..can this be done?

why does the pci buss have to deal with 35fps at 80mhz? can't we use the blanking to cut that down to a datarate of 24fps 12bit @ 80-85mhz?

<<<-- Originally posted by Rob Scott : Yup, it's at ObscuraCam (http://www.obscuracam.com/wiki/static/ObscuraCamWiki.html).
I know you were asking Obin, but I've used it too ... and I'm not overly impressed. It seems to work OK, but it's cryptic and complicated. Not easy to use. It does work in Windows and Linux (haven't tried Linux yet). -->>>

Speaking of ObscuraCam, it hasn't been updated in a while. Have you been busy with other stuff Rob? If not, can you give us a short run down on how the convert app is going?

what would the datarate be from the 3300 @:

1920x1080
24fps
85mhz?
12bit/10bit

Joshua Starnes wrote:
Have you been busy with other stuff Rob? If not, can you give us a short run down on how the convert app is going?I have been distracted for the past few weeks, yes. Work, family, Olympics ... the usual :-)

I am continuing to make progress, however. The Convert software (which will soon be released under the GPL) is operational, though it only has a Nearest Neighbor Bayer filter at the moment. Here's a sample frame from the system:

TIFF, 16-bit (5.4 MB) (http://www.obscuracam.com/clips/0206/pixel_raw.tif)
JPEG, 8-bit (133 KB) (http://www.obscuracam.com/clips/0206/pixel.jpg)

This is a picture of my dog (who is appropriately named Pixel). I'm sure it is badly focused and exposed. It has only been Bayer filtered (Nearest Neighbor -- you'll see definite zippering along the edges of objects) and has not been processed in any other way.

I am currently working on an implementation of the "Color interpolated image using Laplacian second-order color correction I" algorithm which can be found here (http://www-ise.stanford.edu/~tingchen/). It seemed like a good compromise between CPU load and image quality.

Obin,
What you are banging into is peak vs average data rates. Average is fine for calculating storage. Unless every step of the way (camera to FG, FG to memory, memory to disk controller) has its own FIFO, you have to look at peak data rates with bus loading.

The whole point of using higher clock rates is to read out the frame as fast as possible. That means that the entire frame will be transferred from the camera to the memory buffer at 80MHz clocking if that is what you selected. If there is no packing (and ther is none on Epix), then you will move two bytes per pixel or 160MB/sec during readout - exceeding the PCI-32 limit (132MB/sec theoretical, 100-120MB/sec realistic).

I think your options are:
- Go to the 64 bit FG when Epix has it available - should be almost no software changes
- Go to a fancier (much more expensive) 32 bit FG with on-board storage to stream the video frame to memory at 24th sec
- Go to GigE to use the data packing (3:2)

This is why the Altasens is being released with the 64 bit interface as the main interface. The SI-1300/3300 are low cost cameras - 64 bit is an option but not standard. It is only an issue for >8 bits and overclocking for RS artifact removal.

A simple question what is your time frame to have the camera hit the market?

I know you need to make tests but in small simple statement what do you want the camera to do?

And what will it have, interchangeable lens, etc.

Gary are you asking me about my project or Steve N?

So your Saying Steve that 60mhz is the MAX I am going to get on the PC? with 32bit? what if I capture 8bit images what mhz could I run?

Are you looking at this with 1080x1920? or the full 3megapixel size?

I haven't read through all the posts. I wasn't sure if they're two groups or not.

So tell me simply what are you trying to do. I think at the beginning you were taking apart a 16mm Russian camera and turning into a HD camera.

Also is there a web site or is that too soon?

Can I just import the footage into for example FCPHD?

Gee, it'd also be nice to record variable frame rates. So we can get a slow-mo in the camera and then still play with it in post.

I think waht we're all looking for is a low cost camera that will put out outstanding images to give us outstanding production values. I've seen footage from the posts here and other places that their is talent out there. We just need a great camera to match that.

And if Steve wants to do a short bit about his that's fine also. Thanks.

BTW Juan, there's going to be some non-linearity in the darks, these sensors are still analog devices, so while they may expose linearly for most of the image range, there's still going to be a portion in the darkest regions that will not expose linearly. I think a lot of that has to depend on noise and where you set the internal black point on the chip, but I'm not too sure about that.

Also Obin is "over-exposing" his images, but here's the thing: If you try to go for "nice" looking images, you're only going to get around 2-2 1/3 stops of over-exposure. You can set as much over-exposure as you want, but if you want that 5 stops over that film gives you, you're going to have to underexpose quite a bit to simulate the overexposure headroom that film gives you. For instance, on the Altasens, to get 5-6 stops over, we were having to underexpose the chip so that the white patch on the Macbeth chart was at 10IRE instead of 90IRE! That's a long way down, and the image must be normalized after that. Also the dark linear image look depends on which way the bits are packed. It won't look so dark if the bits are packed at the bottom intead of the top (or the other way, I forget which way is which).

Anyways, real-life tends to have many areas over 2-2 1/3rd's of a stop over 18% grey, so if you expose the chip in that manner, you going to get some clipping.

Hey Jason, it´s been a long time..... :)
So you´re saying that the outdoors image is right?
Or the opposite?

<<<-- Originally posted by Obin Olson : what would the datarate be from the 3300 @:

1920x1080
24fps
85mhz?
12bit/10bit -->>>

Your programmer should have no problem calculating that, but here goes:

1920 x 1080 @24 fps 10 bit:
datarate unpacked from camera: 94.92 MB/s
full RGB datarate: 284.77 MB/s
packed datarate: 59.33 MB/s

1920 x 1080 @24 fps 12 bit:
datarate unpacked form camera: 94.92 MB/s (remember, it's 16 bit!)
full RGB datarate: 284.77 MB/s
packed datarate: 71.19 MB/s

Keep in mind that the 3300 can't do 1920 x 1080 without reducing
the field of view. So it would be better to capture at the full
horizontal resolution with the approriate 16:9 vertical resolution
and scale that back in realtime to 1920 x 1080. Which I'm hoping
we'll implement in Obscuracam one day.

Gary McClurg wrote:
I haven't read through all the posts. I wasn't sure if they're two groups or not.Gary, Steve Nordhauser is with Silicon Imaging (http://www.siliconimaging.com/), the company that makes the "box" cameras that we are working with.

Obin is using the SI-1300 and SI-3300 box cameras to build a complete PC-based camera system (http://www.obscuracam.com/wiki/static/ObinOlsonDesign.html), the "head" of which is in a Russian-built K-60 16mm film camera. Obin has hired a developer to write the "firmware" for the camera.

There is a second group (myself and Rob Lohman) independently working (http://www.obscuracam.com/wiki/static/DevelopmentBlog.html) on "firmware" (http://www.obscuracam.com/wiki/static/Capture.html) and an offline "Convert" app (http://www.obscuracam.com/wiki/static/Convert.html) which will be released under the GPL. My hope is for both camera efforts to contribute to this project.

Rob L:
I'm not quite sure what this means: "Keep in mind that the 3300 can't do 1920 x 1080 without reducing
the field of view. " It is a half inch sensor at 2048x1536 so the 1920x1080 is slightly less than 1/2" where the SI-1300 is 1280x1024 native so a 1280x720 window is a full half inch. Is that what you mean? Or that both the sensors are less than the 2/3" of the IBIS-5 and Altasens?

Rob L on packing:
Your numbers are correct. I'm not sure 10 bit packing is too useful because it is so much more difficult to do than 12 bit. I think that an important point is that full RGB data derived from a Bayer filter doesn't have any new information - it is just a data expansion. To me, this is exactly why we shouldn't use RGB for storage unless it is a precursor to compression.

Steve Nordhauser wrote:
I'm not sure 10 bit packing is too useful because it is so much more difficult to do than 12 bit.Really? It's a little tricky, sure, but I didn't think it was that bad. And I can see someone finding it useful to do a 12-bit linear to 10-bit log lookup to reduce disk bandwidth during capture. (Or, naturally, using it with the SI-1300, which is native 10 bits. But then again, I think the AltaSens is going to be the preferred platform.)

Totally agree on RGB expansion. No-one seems to be doing that
and I can testify Rob S. and myself ARE NOT doing this. It's just
there to see what scale raw and packing are on.

I think 10 bit packing is very useful, it offers almost 40% reduction
of the datastream without any futher need to do anything else.
Rob S. and myself didn't have too much trouble implementing
that. I've got a bit shuffling engine running for my compression
anyway.

Regarding compression. The first test to compress a 16-bit still
frame from the SI-1300 @ 1280x720 resulted in a futher 38.72%
datasize reduction using my compression "engine". This is with
plane splitting. Optimizing the compression per plane increased
this to 39.13%. This is on top of the packing which gave me a
total compression ratio of 61.70% and 61.95%.

Regarding the 3300 and FoV. If the full width of the chip is 2048
and you only sample 1920 you will loose a bit of the fiel of view.
Depth of Field will slightly change as well. Or was this the chip
with fractional row skipping or am I mixing up the AltaSens. One
of these had fractional skipping so to not reduce FoV, the other
didn't. And you would have to scale in software to keep the FoV.

Here is some bandwidth information that may clear things up a bit. When dealing with video transfer using a PC, every step of data movement must be understood as part of a system.

Into the PC:
USB 2.0 can transfer data at about 320Mbps (with the wind at its back and the sun shining). Spec is 480Mbps. Remember, all bps are bits and Bps are bytes. You need to know if the data is packed or not. 12 bit data can take 2 bytes unpacked (16 bits) or 1.5 bytes packed (12 bits). (Peak vs average - below- applies here also)

Someone else can suggest real world numbers for firewire.

Gigabit ethernet is 200Mbps with windows drivers, 800Mbps (100MB/sec) with custom drivers.

Camera link is pretty much unlimited.

PC buses:
PCI-32 theoretical is 132MB/sec, realistic is between 100-120MB/sec. There are some PCs with a split PCI bus that can move data independently on each half.

PCI-64/66MHz is 4x the bandwidth of PCI-32/33MHz

PCI-64-133MHz is 8x the bandwidth of PCI-32/33MHz

If you put a 32 bit board in a 64 bit bus, the whole bus slows to 32 bits. Same with clock rates.

Some operations, like moving incoming data to system memory, take bus bandwidth at a peak rate that must be available, others can use an average rate (like moving compressed data to RAID). Some, like display to a monitor might not take any bus bandwidth since the pathway to an AGP slot does not cross the PCI bus. Some of the new chip sets show a two drive serial ATA pathway off the bus (the southbridge is an ICH5R). This might be very important but I haven't seen any benchmarks.

Mass storage:
(someone correct any numbers that they feel are incorrect please)
ATA drive - highly dependent on drive size, RPM, interface but maxes out around 25MB/sec continuous per drive
SATA (serial ATA drive) - around 40MB/sec continuous
UltraSCSI 320 - about 50MB/sec continuous

Drives start putting data on the outer rim where access times are quicker (fixed rotational speed, more data in a circumference) and slow as you go further in. Be sure to watch benchmarks to see if they are really putting data on at least 2/3 of the drive.

CPU speed:
Some operations take no CPU time just bus time, using DMA transfers. Others, like USB 2.0 drivers, take CPU time that must be available. Real time packing, compression and preview display all take CPU time.

Steve, a while back you posted a link to a page which would calculate the pixel clock command for a given rate. I cannot find it now -- can you please post again?

Thanks.

Obin, do you definatly think it is feasible to shoot a large project with the 3300? (By feasible I mean big screen potential)

What is the deal with this rolling shutter artifact?

Does this make it unuseable?

Is any of the mechanical shutters on the silicon site useful?

After looking at the streampix software information on the silicon website it claims that it can stream to hard drives compressed or uncompressed. How much compression are we talking about here?

Does this still mean that a RAID is necessary or is there a possible external hard drive solution?

Lastly, what is going the most straight forward NLE? If we are staying with PC is Vegas Video 5 practical?

Is there anyway we could use the ethernet option to get the images into Final Cut Pro?

I ask these questions because the arrival of altasens has still not been confirmed. I have heard rumours that cineform may develop a codec for use with adobe premiere pro, but again there is no indication of when this will arrive. Also no news from sumix either.

As I am based in the England (about 100miles from London) any order I make will have to be shipped across the ocean to me. I have a project I wish to shoot within the next two months so knowledge of any further developments is crucial right now. If you can shed any light on these matters at all I would be very grateful.

I will see today how bad the rolling shutter is @ 60mhz 1920x1080 on the 3300

Adrian,

It is hard to tell how long it will take.

I will have a product but I am still in R and D on the whole thing...stay on the board and keep reading

Adrian: personally I would not calculate on using these camera's
on such a short term (2 months). As Obin indicated both teams
are in R&D stages and developing a product. There is no 1.0
release yet. When we reach that there are other things to work
out like casing and how well these systems will work. And we
haven't even touched on things like audio synchronizatione etc.

ROb what one of the 12 are you using from that paper?

This one:

Linear Interpolation with Laplacian second-order correction terms I ??


I am currently working on an implementation of the "Color interpolated image using Laplacian second-order color correction I" algorithm which can be found here (http://www-ise.stanford.edu/~tingchen/). It seemed like a good compromise between CPU load and image quality. -->>>

Obin Olson wrote:
what one of the 12 are you using from that paper?
This one:
Linear Interpolation with Laplacian second-order correction terms IYup, that's the one. In that paper, it's also referred to as "Interpolation with color correction I" and "Laplacian color correction I".

Have you tested it yet? can you show me a still from it?

Obin Olson wrote:
Have you tested it yet? can you show me a still from it?It's not quite working yet. I'll post a sample image as soon as I have one.

that would be cool...Rob we are saving RAW files on the disk..would it be a good idea to send you one so you can test your convert app?

Obin Olson wrote:
that would be cool...Rob we are saving RAW files on the disk..would it be a good idea to send you one so you can test your convert app?Once I release the Convert app source code, your developer will be able to add support for your file format -- or you can use the IHD format if you prefer.

Hey Jason, it´s been a long time..... :)
So you´re saying that the outdoors image is right?
Or the opposite?These are linear sensors (for the most part). That means that ANY exposure is "right". The only limiting factor is noise. If you want a "filmic" image, then you're going to have to underexpose a whole lot to get enough head-room to simulate the highlight compression that film can do (or simulate a logarithmic respose to light instead of linear). Enough head-room compression so that the eye can't see the clip-point, just like with film. It's the same thing as with digital audio trying to sound like Analog-you have to go way under 0db (like 20db for the tone), and allow that top 20db to be used as headroom so there's no digital overload, the same thing to us as "clipping". I'm sure you've heard when somebody doesn't watch the DAT and lets that overload-it doesn't sound good. Same thing with digital imaging. So anything is "right", but that doesn't mean it'll look good. Now if there weren't any bright hot-spots in that image, say in a studio somewhere, then he'd have no problems, no clipping, and we'd probably be saying great things.

But again, our only limiting factor with how far we can underexpose these chips is noise, and that's why it seems the Altasens will be such a great chip, because we can underexpose a WHOLE LOT, hardly much noise, great color saturation, etc.And we haven't even touched on things like audio synchronizatione etc.After talking to Steve about this, I'm not really sure that's going to be a problem, because with the camera-link cameras we have very fine control of the frame rate through partial Hz frequencies and vertical blanking. In other words, trying to hit 23.976 or 24fps won't be too hard (and both those frame-rates are VERY important, along with 25fps-for PAL-29.97 and 30fps). Only those frame-rates need to be spot-on with audio sync, the others are for MOS-type stuff only.

ok I have CineLink with full color display 24fps and GAIN, RGB GAIN, SHUTTER SPEED control with the 1300rgb...looking good...now if we could just get the 1300rgb without the smear factor this would be at the point that I could start thinking about a box design and buy all the rest of the stuff we need!

I am stuck right now...seems the smear is bad enough to halt production with that chip and the 3300rgb datarate is so high that I can't even do what I want with it unless I have a 64bit pci card..I can't get a 64bit pci card because I have been working with the 32bit card from Epix and the whole project is wrapped around that brand..Epix does NOT have a 64bit card out that may take 2-3 more months. The only other thing is the Altasense running at 720p untill the 64bit card comes out...as you all know even the Altasense is NOT out yet!...would any of you guys think it wise to go ahead and use the 1300rgb smear and all?

arrgg

Obin,
If you are already going to use the ground glass for DOF, can you use the SI-3300 in 1280x720 windows? It would run at the same speed as the SI-1300 (same clock speed and frame rate) without the smear. Less sensitive, of course, due to the smaller pixel size. Less DOF without the ground glass. The reason the data rate is so high on the 3300 is that you are using it in 1920x1080 mode and that is a lot of data.

Also, Epix swatted their last bug on the 64 bit board last night and will be going out for new boards very soon. I'm expecting 6-8 weeks for production boards.

Check out the development blog (http://www.obscuracam.com/wiki/static/DevelopmentBlog.html) -- I got the LCC1 ("Color interpolated image using Laplacian second-order color correction I") algorithm working! I put a sample image up that you can download, plus the same image as a pre-Bayer TIFF.

<<<-- Originally posted by Rob Scott : Check out the development blog (http://www.obscuracam.com/wiki/static/DevelopmentBlog.html) -- I got the LCC1 ("Color interpolated image using Laplacian second-order color correction I") algorithm working! I put a sample image up that you can download, plus the same image as a pre-Bayer TIFF. -->>>

It looks good, but it's awful green. It seems like you're using the LCC1 as your Bayer filter? Is the green normal when the image has only been Bayered?

Joshua Starnes wrote:
It looks good, but it's awful green. It seems like you're using the LCC1 as your Bayer filter? Is the green normal when the image has only been Bayered?Yes, that image is using LCC1. I'm guessing the green cast is normal and it just needs color correction, but I don't know that for sure.

I don't see the image what is the name Rob?

also Steve:

Steve I would be very happy to do that with the ground glass BUT..this chip is so much less sensitive then the 1300 I am really not sure we would get anything that could be used professionaly from it..if it was the same as the 1300 it would work...argg ;)

Obin Olson wrote:
I don't see the image what is the name ROb?pixel_pcc1.tif (http://www.obscuracam.com/clips/0206/pixel_pcc1.tif)