Re: F3 BBC Report
 

You basically say that in the post below, and perhaps other places:
http://www.dvinfo.net/forum/sony-avc...ml#post1639132

Re: F3 BBC Report
 

I'm not trying to start a fight so I'll stay out of this...

Someone did find this about the sensor. It mentions gross pixel count vs effective. It is talking about the FS100 but still they both use the same sensor.

page 4.
http://www.sony.co.uk/res/attachment...7480643259.pdf

Re: F3 BBC Report
 

There is just too much confusion surrounding this sensor to know for sure.

What are "effective pixels?" Why is the pixel count "approx.?" Are "pixels" the same as photosites?

This sensor could be anything, and convincing arguments have been made which run the gamut.

Re: F3 BBC Report
 

Gross pixels Approx. 3,530,000 pixels
Effective pixels of moving pictures in 16:9 Approx. 3,370,000 pixels
Effective pixels of moving pictures in 4:3 Approx. 2,530,000 pixels

While many have assumed pixels are photosites, there are reasons to think this is not true:

Juan say's the image is "grossly" over-sampled. There's nothing grossly over sampeled with 3.37MPixels if the photosite count is only 3.53 million.

PS: from the same PDF:

The sensor also features an optimum number of effective pixels for shooting HD
moving images. At a high 50fps in >>> all-pixel scan mode <<<, this allows images to be
captured with less color aliasing, jaggedness and rolling shutter than DSLR
cameras, while providing the sensitivity to shoot at a minimum illumination of
0.28lux.

Re: F3 BBC Report
 

With regard to sensitivity, I don't think we can draw any meaning full conclusions over pixel size from sensitivity alone. There are far too many other factors that can skew any conclusions, Q-factor, gain settings and noise reduction, microlense size and usage, binning etc etc.

The F3's effective resolution does seem to tie in quite well with what I would expect from a 3.3MP Bayer sensor. If it really was using 4800 x 2700 I would have expected higher measured resolution.

Bottom line: It does produce a good image in the real world.

Re: F3 BBC Report
 

I was at a talk on HD tapeless workflow at the BBC yesterday. Seemly they have a spectrum analyser which all the delivered programmes are put through. Problems are not just caused by the camera codec, but how the post workflow itself is handled.

Apparently, about 60% of delivered programmes have an issue of some sort. The reasons vary from not having the right paperwork to needing to re-shoot material because they used the wrong codec for more than 25% of the programme or post workflow issues. Any variation from the 25% needs to be discussed and to be justified eg the use of archival material.

That's how it stands for HD at the present time. Perhaps they may reduce the quality standards in the future, but the impression was they weren't going to let these standards slip..

Re: F3 BBC Report
 

I'd like to hear more about this...in this context, "spectrum analyzer" is a pretty unscientific term. Not saying I don't believe you, just wary of that term.

I've had a lot of my deliverables go through an outfit in Burbank called DVS, which does QC, encoding and vaulting for a lot of content producers, and the reports I've seen (i.e., the jobs that got rejected) are definitely machine generated with a human running it (human written notes in the comments beside each line item violation).

But nothing that sounded like "spectrum analyzer" that could somehow divine what codecs were used before a master was made.

Re: F3 BBC Report
 

That's the term the BBC guru used. I suspect it's a similar device to the one that I linked to earlier in the thread.

http://www.cnrood.com/PHP/files/vide...nix-PQA500.pdf

There was a mixed range of people at the talk, so I guess it was just a catch all term for a piece of test equipment. They sounded confident about being able to spot non spec video content, which may or may not be the case 100% of the time in practise. Certainly, he said HD programmes have been failed. It could be also be due to issues somewhere else in the chain, because post workflow was also mentioned in connection to this.

Of course, it could just be a virtual transmission chain that pushes the master to the limits, so that the compression errors in the workflow start to show up.