Please go there: http://www.dynebolic.org
if you have a fast conection download dyne 1.3, it is a live CD
burn it it's explained there and say in BIOS start from CD voila Cinarella is alrredy ready to use. if you have a firewire, so test it, as it is a live CD and not installed on harddisk it is dead slow but you will have an idea.

For music recording: http://www.agnula.org
there you have with download for redhat just up to fedora 1 all files to have a patched kernel and ardour or demudi thats a debian version with low latency kernel and all installed with ardour.

For a low latency Linux kernel go there: http://ccrma.stanford.edu/planetccrma/software/installkernelandsound.html
and have fun. For high end soundcards, well I'm born Berlin, Nuendo and a lot of people like these cards or hate them:

http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-RME[url]

and sound mastering have a look there: [url]http://jamin.sourceforge.net/requirements.html

What's wrong with WINDOWS ?????? Nothing

so if it will be Redhat or Debian, last is best documented and 2.4xx is the kernel that's is now rocksolid and not the hype 2.6xx, editing, some compositing and all musik can be produced with linux. The operating syatem as download free, or 10 $ for a DV or set of CD applications free and for most of them spam free usegroups. It take time to install sometimes, working with KDE or Gnome is like windows and offioce can open all Word docs abiword will do

MEPIS from US is a live CD Debian based go for it should be low as 2$ with booksellers It can play DVD go for www.distrowatch.org look for articles Mepis and from there follow a link all is explained there as easy as XP but for 2$ and some codec download so what.What is wrong with Linux. It's a low budged solution GNU like a high end GNU Cam

Woking to get my GiG E tool running

But how good is Cinerrella itself. How is the capture part good, simple, fast, reliable?

I think people will need to change it to work with SI, Sumix cameras.

Thanks

Wayne.

Steve. That Arri digital cinema camera (or was it the other one) that used chroma overlap (that I took to be Spaterial pixel overlap, but you corrected and said was from the Bayer mask response curve). It occurs to me what they were doing, and how it could help us.

If the colour coming into a pixel site is not a pure primary colour, but I mixture of the adjacent primary (plus IR or UV). Using a IR/UV filter we can take a guess at the amount of impurity in the pixel from the values of adjacent primary pixels and subtract it. The more we go into an area of colour the more consistant we can debayer a suitable colour, and eliminate a bayer checker board pattern with this extra technique. So purer colours (maybe a bit more than needed, which is what will be done in much post colorisation anyway) and colour areas.

Wayne,
Since a Bayer pattern is a Bayer pattern (with different overlaps due to the differing filter materials), I think you are proposing an enhanced Bayer algorithm. You might want to do a patent search first - Kodak has a boatload of really good Bayer algorithms protected.

I think I understand what you are proposing but don't know if it can be done. I think you are saying that if you have a 12 bit green pixel, it *could* contain up to 20% of blue and 20% of red due to the response overlap, but only at the top and bottom of the B and R wavelenths. The G will be surrounded on the top and bottom by blue pixels (with 20% green information) so you might be able to decide if the 20% of the green is blue or red and extract some real alternate color value at the green pixel.

Not a clue how to implement this since you don't have a pure value at any pixel and it is very shade (wavelength) dependent.

Wayne,

converters like Dcraw already do this.

going slightly mad

Hi all It was a nice time with you, Lots of ideas, so build your cam without any OS !! maybe green beans or what ever you like, without any PC stuff why not. Do the same like Olympus, JVC Viper and all put at the back some strange connectors and basta, like the big ones, let the people alone what to do there, like the big one's. As Dalsa does not care what to do with data and even Arri has no glue , why should we ????? To build 1000 of such a cam is never realistic as all 12 months something new chipwise will be there, more pixel and smaller chips, the industrie does not care of DOF .....no Pixelmania is all about... so good luck

next picture

if we take a SI or Sumix there is only one part to do, get the data on disk and have a viewinder plus camera control, thats easy so easy as only one cam with Pal or NTSC has done it ...The Ikegami Avid or Editcam, and it's only a format for Avid nothing else, so it must be dead easy and without any OS diskussion. Well I do know I went to far with my Linux discussion, I do know that there is a 98% Wiondows world, sorry for this Windows can do every thing preemtive scheduling, low latency all is build in, nobody knows about okay.

break

If we woudl have our own camerahead why for, Olympus has now 4 Altasens, Jvc a 3X Altasens to build this really cheap we have to have big numbers, but without any sales structure ?? And licensing, never ever the fist mokup will be stolen and the first cam copied. We even have no Big name like Kreines google for Duncan cam hehas done this a bax attached to an Arri S16 but no numbers and nobody tkes it, all waiting for 8 M resolution and if it will be there for 16M resolution. Crazy Do you know that with 8 M you have the maximum of a 35 mm what are they scanned normaly 2k and rarely 4 k and nobady tells you that's not good.

brak again

1980 I is fine for tlevision ok if we would have the same format as 35mm film even with an array of Altasnes taht would be fantastic with flame me a wavelt compression very mild only to get the datastarem a bit down. Okay now 4 Intel core modules on one card big as a graphics car each core module has Giog E and SATA so we can do it with an arry of tiny diskl drives for let|s say 15 minutes, wonderfull and all that for aboy 10K $ magic, but not Windows on each core module never ever please. the canera control is via serial 4 Chips okay but no big problem, only the viewfinder puzzels me.

Crazy or not that's the ??

Now think of this a box that could work with all 35mm Arri out in the world that could be something. Arri will never do this they want to sell new gear not t give a 35mm a new digital life. Have it with a russian 35mm fine, no more motor noise and with a 80/20 Prism like Bolex we woul keep the viewfinder and sznc the mechanical shutter is best with 4 Cmos as I do guess four roling shutters have anyway to be syncd . This Box for an attrcatave pricing would be hot. The camera has all gear,lenses a baasplate know for any staedycam and peaple would take it as all lenses and other goodies will work. We have a box with the electronics in and a disk array. Kinetta works with Toshiba 2.5" disks like the iPod not crazy at all, it is a matter of power, best cells will give a mere 230W per kilo not more I guess. An OS to so sorry, Linux can have the Apple format, Windows ca with a tool read it not vice versa windows wil never rite data in Apple format, Linux in about 40 all you want as crazy as it is.
Sorry very long but we should have something cameramen like to work with not consumers that we let the bib P's C's and S 's do good night
ronlad

Something like that Steve, but in this I was trying to estrapulate what Arri (if that was the one we were previously talking about) was talking about to get their purer colours. Where the routines we use here calculate from the colour of surrounding pixels, in this scheeme an assumption of the amount of impure colour passing through is added to isolate impurity and enhance other colour accuracy at photosites.

I do wish somebody had come up with an obviouse scheeme to tell how much other colours (other light) is reaching the photosite (removing need for filter and improving colour). I can suggest a mechanism right now, but the .... would probably not bother listening to it. We know that biofringence (is that the word) can fitler out unwanted light. Biofringence works on fine patterns/lines filtering the correct frequency of light waves. Now why not put fine patterns of structures on a chip to collect other light (other colours) charge and deliver it to it's own circuit (and I do no there are mass production techniques to do this sort of thing), while letting the pure colour through. Rather than collect charge the other colours could even simply be reflected to a slim adjioning photosite instead (as high accuracy for other colours is not as needed, as debayering will get mostly right as is). You just used 100% of your light while bypassing the need for prism or Foveon x3 patent. By the way I state the above as a non specialist public release statement for genreal public and community benefit, and so therefore can't be patented, unless I can patent it (never mind, get a patent attourney to interpret). This gives you a monochrome and colour sensor on one chip (forget expensive bayer filter registering).

Jason, about the area debayer stuff, I think I am suggesting a bit more of an enhancement with the new mechanism to get a even more pure solid colour. As your area colour is going to contain impurity in the solid colour using exisiting methords, this might be able to largely remove that imputity, and keep more real regular detail, rather than averaging it out.

Ronald, I don't think that you went too far with Linux, I think it is valid, and if some people want to do it, it's OK.

With the way we do things, we do little but buy existing parts and put together, no big production lines (maybe for good case, just get them stamped out cheap).

We do things the cheap way. It doesn't matter what the sensor industry does, 720p or 1080p capable sensor is good enough for low end indie. After resolution upscaling most audience will not object. We pick good sensor (maybe Altasens) people will keep for years. If we want new sensor we buy different camera head and add support to capture (maybe extra drives) and it is done. So flexibility saves us cost, quality saves us upgrades.

There are many Windows and Mac owners here, but as I said, if you find Linux users you can get them to join in on new Linux project based on Cinerralla, and eventually new thread. Please do not loose heart, what many think incorrectly does not invalidate what one man thinks correctly.

If you want to go totally custom camera with professional cinema camera gear instead there is room for that to in the Alternative imaging forum. You may have to find people elsewhere and bring them here in a new thread. There are people interested in FPGA here, and most of what you do for the custom camera will be the same (compression engine) so you could even work together and add sata and existing cpu FPGA design for camera controll.

Electronic vewfinding mechanism is available and canbe avaialble through graphics second monitor port. Can tell you accurately what digital film sees.

I need help.

can you guys take a look at both the 16bit tiff files and tell me what we are doing wrong with the one saved from cinelink? if you use a levels meter in photoshop you can see how on the image fron cinelink everything is in the bottom and from xcap it is how it should be..what is going on? both are shot at the same f-stop and light setup/shutter speed/gain

www.dv3productions.com/pub/

Obin,

It looks like the black level is different for this two images. My quick guess.

Not sure how you're doing things, but it looks as though you've clipped the blacks somehow.

Looking at it some more with a histogram, and it seems as though a bit must be off, because you're missing the upper half of the image (for the most part).

http://www.pixelink.com/products_info.asp?id=43

Obin, my guess is - the file "cinelink 12bit - 16bit.tif" was converted to 8 bit/channel at some stage of the process.
And the word "guess" here is just because of a "good upbringing" :) - in fact I'm sure it was!

thanks all. I will speak with my programmer about what could have gone wrong in the conversion from RAW to 16bit tiff files..would anyone like to code a simple standalone converter for the raw files ? just a cheap Lin-bayer would do for now for testing..I am happy to post some raw files for anyone that wants to take a stab at the conversion for 1920x1080 images

please do it, so I can test mine :)

Obin,
Is the rolling shutter artifact still present at 24 frames per second? Or are you running it at 48ps?

My main concern is this: If we have to run the sensor at 48fps with 3300 or altasens, how will we extract half the frames in post if we are not using a frame grabber?

Adrian: I won't speak for Obin, but it easy to implement a system
that every other frame is dropped for example. There are various
solutions, with enough harddisks you could perhaps even record
the 48 fps and then drop half the frames in the processing round
after shooting or keep them for slowmotion for example.

Obin - and others:

I've now made my commandline debayer program and released it with a windows executable. I'm in a hurry now, I'll post some more tomorrow, but here's some info:

-get it from: http://sourceforge.net/project/showfiles.php?group_id=85992

-Bilinear interpolation and Variable number of gradients - debayering methods. NOTE: I've gotten both good and strange results with the Variable nrof gradients method, but the interpolation version is supposed to be as good as it can be.
-reads Obins .raw files, atleast the 720p ones. Also has -w and -h width and height switches, and --header and --bits, switches that you can use if you try to open a 1080p .raw file. I'm not sure if it will work. Try it.
-supports lots of fileformats for input and output: png, tga, tif, jpg, bmp, raw (for input)... No other than 8 bits per channel I think, though.
-uses FreeImagePlus library...

-Try "pihlaja_debayer.exe --help" or readme.txt for more info.

Everything is under GPL. Hope you find it useful. I spend a lot of days writing it. And I hope it works...

More tomorrow if it for some reason doesn't work. gotta go now.

please tell me is it written in C+
or what would like to try to compile it with Linux
as I do have in some days my code ready to get anything from an Gig E port direct to disk array and each time it starts a new file

Yes, it seems to be written in C(++)

Rob Lohman,

Could you possible shortlist some of these 48fps-24fps solutions for me? I am looking to purchase equipment within next two weeks.

Ronald:
The Pixel link is an IBIS-5A camera. Global shutter, 6.7 microns. In global shutter mode, you will only get those frame rates with no exposure time. Otherwise, exposure and readout times add together to make the total frame rate. Check the posts from Ben - he has had good luck with IBIS-5A cameras but we discourage them for DV applications.

looking good we need 16bit tiff export from that convert app to have any use from it at this point.

Latest Raw file format at 12bit 1080x1920
www.dv3productions.com/pub/Rec00001.rw2

>>Latest Raw file format at 12bit 1080x1920
>>www.dv3productions.com/pub/Rec00001.rw2

wow. that's a lot of latitude.

do you have a website for this camera yet? We would be
interested in one of these when it's complete.

Thanks,
Will Griffith
producer/editor

Yes Will it's amazing what I am getting from the Camera at this point..if your new you may not have seen some of the great images I have because of server space. Our ISP told us to delete stuff because we are over the 1 gig limit..I will try and repost some stuff soon for the new people on the list

We have the 2 SATA disks from WD. Nice HEAVY DUTY disk drives..they really feel heavy when I compare them with the standard IDE drive ...anyway I have the Drives and motherboard..still waiting on the CPU a Dothan 2.0ghz and I gota find a TINY atx powersupply or figure out how to feed 12v into the atx connector on the motherboard..anyone want to give me a clue about motherboard power??

David Newman:
I need your stuff for testing!

<<<-- Originally posted by Ronald Biese :
..
with Linux
as I do have in some days my code ready to get anything from an Gig E port direct to disk array and each time it starts a new file -->>>

Cool!

<<<-- Originally posted by Obin Olson : looking good we need 16bit tiff export from that convert app to have any use from it at this point.

Latest Raw file format at 12bit 1080x1920
www.dv3productions.com/pub/Rec00001.rw2 -->>>

How are we supposed to open files with the extension .rw2?

your not. that is a RAW data file that some on the board can play with if they write code. Not for consumer use. ;)

I am working on the tiff fix. It looks like we are using a SDK for tiff save that may be trashing 1/2 the data before save

BTW I got my dirty little hands on some good C-mount lenses today from a National Geo / BBC camera guy / Producer that just moved to town. He has lots of 8 and 16mm lenses. I will do some tests with them asap and post results :0

>>How are we supposed to open
>>files with the extension .rw2?

change extension to .raw, open with photoshop

- 1920x1080
- 1 channel
- 16bit

-will

Ronald:

Yes, it's C++. I don't know about the speed of the program, as I haven't got anything to compare with. Should compile on linux without any problems. You just need FreeImage and FreeImagePlus (find them, make them, install them, -link: -lfreeimage -lfreeimageplus). It was written on linux, but the last version was ported to mingw32, so there might be some code left, that doesn't work with linux (but there shouldn't be).

Obin:

Sorry, if it doesn't work for you. I think I can't get 16bit files out of FreeImage library, because it uses BYTEs. And as far as I know BYTE is 8bits. If I'll find some library with 16bit TIFF read/write, then I might be able to do it later, but it propably won't happen soon.


If somebody's already tested my program, I have to say that it uses the Variable number of gradients method by default. You can use the Bilinear interpolation method by giving the command --interpolation on the commandline. The gradients method worked well with the trucks picture, but the interpolation was better on the flowers. The gradients method is exactly the same as described in that paper about debayer methods - and it was supposed to be the best method in that paper. In the flower picture it makes some new kind of artifacts, kind of like "maze - or labyrinth" like pattern. And on the trucks picture it doesn't get rid of all the zig-zag, but some of it is gone. I also tried coding the Laplacian second order methods but they give me some strange results on the dark areas, and overall, they don't seem perfect even if they worked.

So, I think that it would be best to make a basic interpolation and then remove the zig-zags with some simple algorithm. I'm slowly working on that and the 16bit export.

Obin,

What are those verticle stripes going down the image?

not sure jason screengrab what your talking about and I will check it out

Hi
you wrote----------------------------------------------------------------------
Ronald:
The Pixel link is an IBIS-5A camera. Global shutter, 6.7 microns. In global shutter mode, you will only get those frame rates with no exposure time. Otherwise, exposure and readout times add together to make the total frame rate. Check the posts from Ben - he has had good luck with IBIS-5A cameras but we discourage them for DV applications.
----------------------------------------------------------------------------------

I do think so too, but Rai and Markus do use the same chip. I wonder how they and why they do it ?


Anyway any news for Gig E Altasens ??

What was the mother you were using?
The one Jason told us about? (Kontron)
Or the new Mini-ITX from DFI ?

Ronald

If I can rember right from the posts, it is because IBIS5 is the only relative CMOS Global shutter solution available, and they have better external AD convertor than IBIS5a normally comes with. But still performance is less than Micron Obin used (which has different faults).

Rob S (Steve)

How did you go with adjusting gain etc to get past the smearing? From memory, Obin also mentioned that for some reason he had to adjust his camera by 3db from 0db to get normal image (I forget either +-). I speculated that the camera might have been a bit faulty, have you found the same problem?

Also, when are they going to upgrade that camera to the new non smear technology of the 1080 version.

In matter of fact, I'm sure somebody mentioned a 720p Altasens before based on their older sensors, does such a beast exist, and how good/cheap is it to use compared to Micron/IBIS ones?

I thought DFI's board was MicroATX, not Mini-ITX, or do you have a link to the new board?

Obin, here's a screen grab, blown up to 200% to make the vertical lines very clear, although they're fairly plain at 100% too.

http://home.mindspring.com/~jrod/Lines.jpg

DFI..looks like a good board I have it in the office with no CPU or hard disks yet ;)

I am away on THanksgiving Vacation now. I will have the CPU and disk drives next week. Stay tuned!

Ha the lines Jason! I didn't know you could see them in that raw file..Steve tells me I have a bad chip and I will have it replaced soon ;)

Steve I sent you the 1300 Fedex could you please send me the new 3300rgb ?

Obin:
I have requested your replacement camera.

Wayne on Micron smearing:
They will not be doing a new rev on the sensor - it is what it is. You only get the smearing for oversaturated pixels but it does kill it for natural lighting. They apparently knew about the problem because they went to a different pixel architecture for the sensor in the SI-3300 - it doesn't smear.

David Newman:

Can you let me know how it's going with the support for 1080 12bit encode?

Steve:
Thank you I look forward to the new one.

DOthan 2ghz chip is in and we are getting 70-85% cpu in Black and WHite preview..this is not good..we got 22% with the 3.06ghz P4..not sure what is going on yet...

also does anyone know if windows 2000 supports SATA disks? it seems that the drives I have (10,000rpm) are not working at a fast datarate..maybe a limit of windows 2000? can someone point me to a good disk speed test .exe for testing the disks on the system?

there seems to be some dramatic speed changes in the chip
depending on which application. I t seems to be a killer chip with certain games . but less so with photoshop and others .

http://www.gamepc.com/labs/view_content.asp?id=dothandesktop&page=1

Guys, remember what I say.You will have big headaches using Windows for these cameras....
Also try to avoid threads as much as you can...better is to have fast sequencial tasks..

I agree, if you don't need the thread cut it out. The problem would be different CPU, different achitechture, maybe the main board bios hasn't been updated to support it properly. Consult Intel on coding for your application, and consult mainboard and chipset companies for drivers and bios updates.

Wayne.

Rob S

I had a look at this page here:

http://www.epixinc.com/products/sv9m001.htm

And it gave me some ideas.

Infrared (IR) Cut Filter: The CMOS sensor is more sensitive to infrared wavelengths than a CCD sensor. Infrared sensitivity skews color fidelity. An IR cut filter attenuates (reduces) the CMOS sensor's response to infrared light while improving color fidelity.

This gave me an idea:

Maybe we can get rid of the smear problem by reducing the overload causing it. There are a few ways:

- Use IR and ultra violet cut filters to reduce these emissions from strong light sources, thus reducing the satuation of a pixel compared to the surrounding pixels. As most strong light has high UV or IR content, then this might work very well. If we are extremely lucky the smear problem might be more sensitive to IR or UV.

- One changing gain to compensate (maybe change some on board components, but we aren't up to that, to reduce the circuits max load)

- Increase shutter speed, or use the artifical dual slope technique Steve suggested before (one fast frame and one normal 48th of a second).

- Use a ND filter to get it within limits.

- And playing around with pixel clock and parameters (read out) to see how they effect the smear.

Rolling shutter artifact, as per normal techniques.

So what do you reckon Rob, is it worth going to a camera store for filters to try this out?

Wayne.

Wayne,
I think you could test it out just by stopping down the lens. Sure you will get more DOF, but that shouldn't be related to what you are testing. If you can keep the Micron 1.3Mpix from saturating, any which way, it should be OK. Micron has said that the smearing is inherent in the pixel architecture and they changed that for the 3.2Mpix.

All CMOS color cameras are made with an IR cut filter to keep the colors from being skewed by IR. On some of ours it is built into the sensor cover glass, on others we add it.

Yes, thanks, I would like to see if Rob can improve his camera by doing this. Also if it canbe readily done to just the right amount, rather than having to stop everything down by half. If so, then that makes a reliable low end camera available for his software.

arrg!! why would I now be getting the PCI overflow issue with the new board?? "FIFO overflow" is the error

New board, new chipset design.

First In FIrst Out buffer. Long line of memory cells, circular (when it overflows it is trying to overrite a cell that hasn't been read out). Two pointers, one that pionts to new entry and ine that piont to entry being read. Whn pionters match problems, nothing canbe written (well at least thats a simple FIFO design, maybe more complicated). Different chipsets may have different fifo buffer sizes. So you can monitor how full the fifo is, and buffer anything that won't fit in dram, or findout what the smallest fifo buffers are in any chipset/PCI card/bys chip, and keep writes under this size. N ow I don't know if windows allows you to monitor this though. The problem might also be some timing hickup somewhere else in the computer/code causing data to be written to the fifo in big spurts that are too big to handle.

Because you are getting this problem, my guess is that the system doesn' throttle the FIFO, but that it works most of the time because i is big enough and fast enough to keep ahead of most applications (typical PC stuff). It could also mean that your framerate/pixel size is too for that chipset high.

When I think of it, if you are using dma from dram, then the dma/fifo circuites should throttle it.

the Dothan chip should have a heavy amount of on-chip L2 cache, around 2MB worth. What it doesn't have right now with the 855GME chipset is the memory bandwidth of the Prescott or Northwood on the 800Mhz front-side bus with dual memory channels. For that sort of memory bandwidth, you're going to have to wait till next January for the Alviso chipset which will have a dual-channel memory bus and 533Mhz front-side bus.