Wayne:

Yes Raavin is Jason Keenan. I'm using my normal handle just so when people reply to me, others don't get confused with the other Jason. I've seen cameras cheaper from www.videoguys.com.au. They have a good selection too.

Ben:

From a lay point of view, I agree with you about leaving the raw data alone and converting it with a codec. It just seems to make sense. I think it was you who replied to my comment about using avisynth. I suppose that's more what I was thinking.

I'm still trying to get my head around the 8 bit versus 10 bit stuff. Having a look at the raw file in a hex editor and using some flawed logic, it seemed to me that when you drop the raw file to 8 bit you halve the size of the original because the original 10 bits needs a full 16 bits to fit into. Is that right?

On another line, just thinking out loud, is it possible to stream the file through a fantasy 8 bit conversion codec, basically just dropping the 2 extra bits on the fly for preview and editing, then be able to change codecs for colour grading and final rendering. I'm assuming though that you need at least most of the bits to do the bayer conversion though. It just seems that in order to keep things flexible and compatible you need to have the ability to open the file in anything and at the full frame rate.

Anyone got any links to how bitmaps are arranged in hex format for me???

Raavin :)

Did it help at all with the "gridding"? I thought your de-zipper system was already really good, so I definitely couldn't see much improvement there, but the "gridding" in low contrast areas/out-of-focus/gradient areas was really the problem for me at least.

The gridding is an artifact of the de-zippering that only occurs when the two green offets or gains don't quite match. So since I wasn't doing any de-zippering, there wasn't any gridding. However, since the two greens on the shot I was working on didn't quite match, you could see a slight horizontal line pattern (just as you would with bilinear)...

Basically, the solution is to correctly calibrate your shot before you record. Otherwise, you'll either get a horizontal line pattern. Or gridding when you de-zipper.

- ben

Another couple of stupid questions

1) In the '10 bit' raw bayer file, does that mean that in each pixel, there are 1024 shades of grey?

2) Anyone care to give a breif explaination of how these pixel values are represented in the file???

Raavin :)

Raavin, yeah -- 10 bit represents 1024 values. You can always determine the number of values by doing
2^x
Where x = the number of bits. So 2^10 == 1024

I don't know what you mean by "represented in the file," but any native 10-bit format will do bit packing. That is, since a byte is 8bits, and since the byte is how we write to files, it means that uncompressed 10 bit would be written like this. I'll use "1" to represent the first 10-bit value, "2" to represent the second 10-bit value, etc. Each group of 8 numbers is a byte written to the file.

11111111____11222222____22223333____33333344____44444444

etc

That means it won't make much sense in a hex viewer. However, one extremely inefficient way to store 10bit data is to pad it to 2 bytes (16bit). That would look like this:

0000001111111111___0000002222222222___0000003333333333___0000004444444444

As you can see, we're using far more bits/bytes to represent the same data.

- ben

<<<-- Originally posted by Ben Syverson :
But I'd rather not work directly on Rob's app, as I think he's focusing on a PC-based solution, whereas everything I do is on the Mac. Also, I think Rob's sw is basically capture software specifically for CameraLink

@Wanye: the fastest codec (huffy??)

A 10 or 12 bit JPEG/Wavelet would be fine for 99.9999999999% of the people on this board, but it would be slower than lossless, so what's the point?

- ben -->>>

Only mentioned it because those two are popular topics here and support the range of compression ratios that people want to see.

I think it was Jaun that spoke about a Bayer version of Huff.

The wavelet stuff is not the fastest but one of the best people like here, and able to do completely lossless.

Rob is trying to do a Universal version of capture software that works with any codec, on the PC first then MAC/Linux. I think he intends to support USB and Gigabit versions of cameralink cameras, but I am unsure. So the codec and capture side would still be seperate.

Wayne.

<<<-- Originally posted by Jason Keenan : Wayne:

confused with the other Jason. I've seen cameras cheaper from www.videoguys.com.au. They have a good selection too.
-->>>

Thanks.

Ok, I think I've got it.

So, in your example-

"11111111____11222222____22223333____33333344____44444444"

-if we had 4 pixels which were alternating white and black, it would be

11111111____11000000____00001111____11111100____00000000

yeah???

Would this then show in a hex editor as

ff C0 0f fc 00 ?????? if it was true 10 bit and not padded to 16 bit????

Has it been ascertained whether the bin captures are padded to 16 bit or not. Every other byte has a leading zero so if it's the 'rawest' format available I'm guessing it is.

eg "00 00 90 05 ac 06 18 05 54 06 38 06 28 07 28"
from raw_cap.bin

Thanks for the answers, I'm just trying to get my head around it.

Cheers,

Raavin

@Raavin: Would this then show in a hex editor as ff C0 0f fc 00 ?????? if it was true 10 bit and not padded to 16 bit????

Yes, precisely. As Rob clarified, the 10-bit data coming off the SI cameras is padded to 16bits in the following manner: (this would represent 1 value)
0000##########00
Where the hashes represent bits with data. So it's 10-bits of data, padded out to 12-bits, within a 16bit number. It seems very strange to me.

But yes, that's why every pixel will look like: 0X XX in hex, because the first four bits are always 0. And the last two bits are always zeroes, so the last hex value of every pixel will always be C, D, E or F.

But who cares about hex? :)

- ben

Hi, this is my first post but I've been following this thread since the start. Congratulations everyone for the great work!!!

-Avid has a codec called DNxHD http://www.avid.com/DNxHD/
6:1 full raster (sampling every pixel on the image) It works for 8-bit and 10-bit at 4:2:2
this will give us uncompressed quality at almost uncompressed SD size

I think this realy would be the best codec to go for, with this project.

The reality is that Its likely I won't get this camera. I'm just a geek so I like to learn geeky stuff. I'm looking at other cameras though so this stuff will probably apply.

Re the hex stuff, I've done a little bit of assembly in my younger days. In reality it was mainly 'disassembly' so fairly basic, but I just wanted to know what I was dealing with if I decided to have a play at a basic assembly based bayer filter. It wouldn't be very good, but hey, it's just geek fun.

As you say, I remember this discussion earlier in the thread but at the time I had no idea what it meant. Now i do, sort of. If I understand how the image is constructed, this will obviously be easier.

Cheers

Raavin ;)

Raavin: I totally understand. My own interest in this project is about 50% film geek, 50% computer geek. :) That's the ratio I like to maintain. I guess that adds up to 100% geek in any case. :)

Ben,
Do you have an aproximate ASA equivalent of the Sumix camera you got?

Obin?

Juan, I'd put it at between 50 and 100 ASA. It depends on whether and how you're using the LUT -- which will also affect dynamic range. But at 8 bit, your choices as to how to use the range are more limited.

There are definitely times when it seems equivilent to 100 ASA film (which I've shot a ton of), but with certain settings/light levels, it feels a full stop slower.

Please note this is a totally emotional appraisal, because there's no good way to rate a CMOS/CCD sensor in terms of ASA. These sensors are linear, whereas film has a distinctive "S" curve response to light. So an ASA/ISO rating is only a small part of the picture.

I just got my 10mm Schneider Cinegon f1.8 lens in the mail today... This is a gorgeous lens. It's only single coated (multicoating is overrated), but it kicks the pants off of the multicoated Computar 8mm I've been using, and it's nearly as wide. It's sharp, high contrast, and has none of the barrel distortion I feared it might exhibit. I think this will become my main shooting lens, with the 8mm used for extra wide shots, the 25mm Angenieux for close ups, and the 75mm Angenieux for telephoto shots. God I love primes. The best thing about this whole HD camera setup is getting to work with primes again, and only using zooms when I want to.

I'm anxious for Sumix to come out with their new software -- I'm ready to shoot!

Ben,
Do you agree with the 640 ASA rating given to the DVX100?
(I ask this because I want to make a correlation between you camera and DVX to get myself a better idea about sensitivity)

I haven't used the DVX100 extensively, but 640ASA is downright laughable, unless you crank the grain.

The DVX100 gives a much darker image than my GL1 at 0 gain, and I would put the GL1 at 0 gain at around 400 ASA. Shooting with the DVX100 is like shooting with about 200 ASA film in terms of the amount of light you need...

I compared it with a photometer, and to me that scale of 640 was right.I used it everyday for 6 weeks, with and without Mini35 adapter and Zeiss Primes F1.2 .
All the movie was shot at night with only the light coming from sodium street lights and in some ocassion the camera was more sensitive than my own eyes...
I must accept that what you get is very dependant on Gamma adjustments , pedestal etc....
I didn't use more than 0 db gain setting.

So you would say your camera is one stop less sensitive than a DVX100?

Juan, I haven't played with the DVX100 for months, so I can't give you a hard and fast comparison, but I would guess that SMX-150c is anywhere from a stop to 2.5 stops slower than the DVX100... Maybe more... But again, I'm not sure stop math is the way to think about the differences.

For example, once the 10bit software is available, it may be possible to shoot 100% linear, which looks dark, and then apply a gamma curve in post to bring the image out and make it look "normal." If we can do that, it will effectively make the camera a stop to two stops faster, because we'll need less than half as much light to get a good image.

But again, this is all non-linear for now, so it's rather nebulous. I'm witholding judgement until I see what an extra two bits (four times as many gray values) can get us...

Thank you Ben.
Very usefull info.
It was just I'm too used to film terms and scales and it is the only way I can compare things :)

<<<-- Originally posted by Jason Keenan :
dealing with if I decided to have a play at a basic assembly based bayer filter. It wouldn't be very good, but hey, it's just geek fun.

-->>>

Yes, please do. Rob has had very good results (performance gains) going from straight C to include inline assembler. People are so used to C (and Windows) they don't realise how much of a ball and chain it is compared to assembler.

BTW, I've found a very fast solid-state device.

They're planning on releasing an SCSI U160 and U320 device that can sustain 230MB/s. Right now the sales person that contacted me said that it should cost around $1K per Gig, which isn't too bad if you have a couple gigs on this thing to serve as a temporary capture device and then offload to another slower SATA drive. But again, load one of these puppys up (they're expandable to around 122GB I believe) and you're definitely not going to have to worry about lugging around a hard-drive array and any associated problems with RAID 0 or 1.

check it out at http://www.bitmicro.com/products_edisk_transit.php

If you only get 1 or 2 gigs, why not just get 2 gigs of RAM and record to that? Much less expensive...

For the Altasens you're going to need a lot more than 2Gigs, especially if you want to record 12-bit linear, which the chip is capable of.

Might be slightly pricey, but then again, this is for something that could sit nicely on your shoulder.

I'll be shooting with the Altasens at 720p and probably 10bit. 1080p at 12bit is a bit much for me right now. But I understand where you're coming from.

Do people out there really want an all-in-one shoulder-mountable ENG-style camera? I sure don't, especially if it will cost more. I don't do a lot of handheld shots -- so if the camera's going to be on a tripod or dolly anyway, I don't mind having a laptop sit next to it... The Kinetta is cool, but you pay a high price for an all-in-one solution. Not to mention the fact that it's not very easily upgradable. By using cheap and standard components, you can swap things out pretty easily...

I've done more research, and I think a good alternative to high-end solid state stuff is strapping together a few 7200rpm laptop drives in 2.5" FW800 cases. Stripe them into a RAID configuration, and hook them up to two or three FW800 buses (2 CardBus FW800 ports + built-in FW800 port). Check out this page at barefeats.com giving benchmarks for this type of configuration. They were getting 67 MB/sec over CardBus with a 2 drive RAID. I'm sure you could do much better with three or four drives.

How much is 67 MB/sec? Well, 1920x1080 @ 24fps in 10bit is around 60MB/sec. So you could handle that with just two pocket-sized external drives taped together. Or you could do 1280x720 @ 48fps in 12bit, which is around 63MB/sec.

I think cheap external RAID is the direction I'm headed.

one Raptor SATA has a 72 MB/s speed and costs 199...............

Yeah, but you can't carry it with you. I'm talking about laptop solutions...

Why I cannot carry with me a normal PC Hard drive, are you kidding???

How are you going to power it? Plug it into a tree? Carry some custom battery?

If I can carry a Laptop with its batteries, I can power one little disk which just needs around 10 watts and weights 1.60 Pounds I guess, but as usual I know you'll tell me I'm wrong....


http://www.westerndigital.com/en/pro...asp?DriveID=65

No, no, no. Relax -- I'm seriously asking. How would you power it? Most laptops probably won't deliver 10watts through any of the buses (maybe over 2 USB2/FW buses combined?) so would you adapt a batter for it?

If I can't take power from the HDs conectors I guess I can take it from somewhere else, if not I can take it from the Laptops battery connectors and add a little regulator, transformer (don't know the exact english name) to power the disk..
If all this fails, I guess I'll need another laptop battery or a camera battery with a power regulator to get 12 and 5 volts from it....
Anyway it would always be smaller and less power hungry than a Firewire RAID or several disks...

A FW raid with 2 disks would only take 6W maximum during read/write operation, and it could all be bus-powered... No extra power source needed...

two laptop disks??
Are you sure?

What do you mean? Yeah -- laptop drives draw a max of 5W on spin-up (5.5 for 7200rpm), but only draw a max of 3W during normal operation. With two separate buses, you should have no trouble powering them (a single bus may not power both, depending on the laptop).

And 2 FW800 drives is enough to give you 67MB/sec, like I cited before...

can the laptop drives be used on a SATA connector? that would be a very good setup and somthing I will look at for the camera

Steve will I get a 3300 soon?

once again we used the camera for a "real" shoot today of a product on a bluescreen for comping and once again the "streaking" ruined the shot...the good side is that the streak was on the blue so it was cut out anyway...

Obin, is your software finally working?

Obin, when you get your new 3300 please could you give me an aproximate sensitivity in ASA scale ?

d'oh
 

I haven't been paying attention to the DAC offsets in my camera's settings, and I think that's why we were seeing excessive banding in previous images. I'm still experimenting with how far I can push the image once the DAC offsets are set correctly, but here's an example image with no hardware image correction, but with a software gamma applied, and my chromaPop plug-in.

I think I'm getting the hang of it. There's still a little banding in certain areas, but it's way less intense. I might be able to push the hardware gamma up a tad without affecting the banding. Software gamma adjustments from 8 bit data will definitely accentuate any banding...

- ben

I am working on two things:

• Capture app -- CameraLink- and Windows-specific (for now)
• Convert app -- cross-platform conversion/filtering app

The Capture app will probably be closed-source, but the Convert app will be developed under the GPL, so it would be a good place for your Bayer algorithm to go, if you're interested in incorporating it.

When I have some time, I'll try to work up a better road map of the software under development.

(I have also thought about working on a codec, but I have way too much on my plate already.)