|
|||||||||
|
Thread Tools | Search this Thread |
November 19th, 2004, 05:14 PM | #2206 |
Major Player
Join Date: Jan 2004
Location: Bordeaux, going to Bangkok, 2011
Posts: 232
|
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 |
November 20th, 2004, 03:38 AM | #2207 |
Inner Circle
Join Date: May 2003
Location: Australia
Posts: 2,762
|
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. |
November 20th, 2004, 04:09 AM | #2208 |
Inner Circle
Join Date: May 2003
Location: Australia
Posts: 2,762
|
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. |
November 20th, 2004, 07:07 PM | #2209 |
Trustee
Join Date: Jan 2003
Location: Wilmington NC
Posts: 1,414
|
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/ |
November 20th, 2004, 08:08 PM | #2210 |
CTO, CineForm Inc.
Join Date: Jul 2003
Location: Cardiff-by-the-Sea, California
Posts: 8,095
|
Obin,
It looks like the black level is different for this two images. My quick guess.
__________________
David Newman -- web: www.gopro.com blog: cineform.blogspot.com -- twitter: twitter.com/David_Newman |
November 20th, 2004, 08:34 PM | #2211 |
Trustee
Join Date: Mar 2003
Location: Virginia Beach, VA
Posts: 1,095
|
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). |
November 21st, 2004, 07:28 AM | #2212 |
Major Player
Join Date: Jan 2004
Location: Bordeaux, going to Bangkok, 2011
Posts: 232
|
Firewire
|
November 21st, 2004, 03:54 PM | #2213 |
New Boot
Join Date: Oct 2004
Location: BG
Posts: 19
|
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! |
November 21st, 2004, 06:52 PM | #2214 |
Trustee
Join Date: Jan 2003
Location: Wilmington NC
Posts: 1,414
|
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
|
November 22nd, 2004, 04:00 AM | #2215 |
Major Player
Join Date: Jun 2004
Location: Buenos Aires , Argentina
Posts: 444
|
please do it, so I can test mine :)
|
November 22nd, 2004, 06:20 AM | #2216 |
Regular Crew
Join Date: Jan 2004
Location: leicester uk
Posts: 26
|
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?
__________________
how far can we push these cameras? |
November 22nd, 2004, 06:26 AM | #2217 |
RED Code Chef
Join Date: Oct 2001
Location: Holland
Posts: 12,514
|
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.
__________________
Rob Lohman, visuar@iname.com DV Info Wrangler & RED Code Chef Join the DV Challenge | Lady X Search DVinfo.net for quick answers | Buy from the best: DVinfo.net sponsors |
November 22nd, 2004, 08:08 AM | #2218 |
Regular Crew
Join Date: Jul 2004
Location: Helsinki, Finland
Posts: 52
|
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/showf...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. |
November 22nd, 2004, 08:47 AM | #2219 |
Major Player
Join Date: Jan 2004
Location: Bordeaux, going to Bangkok, 2011
Posts: 232
|
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 |
November 22nd, 2004, 08:58 AM | #2220 |
RED Code Chef
Join Date: Oct 2001
Location: Holland
Posts: 12,514
|
Yes, it seems to be written in C(++)
__________________
Rob Lohman, visuar@iname.com DV Info Wrangler & RED Code Chef Join the DV Challenge | Lady X Search DVinfo.net for quick answers | Buy from the best: DVinfo.net sponsors |
| ||||||
|
|