Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

"numerically honest 4k", Sony backhanded slap at Red

Read the patent before you cough... Cineform is listed in the application. Patent granted. I just love it when people comment... and have no idea what they are talking about. No offense.

Jim

Gavin Greenwalt said:
*cough* cineform *cough*

Not unless he bought it off of one of dozens of other companies that were already offering it. Wavelet + Bayer Pattern wasn't exactly a new concept.
Click to expand...
 
Jim and Graeme most definitely hold a patent on compressed RAW for video. Im not sure how broad the patent is, or how Cineform fits in.

Edit: sorry, did not see Jim's post right before mine.
 
Andrew M. said:
There were two announcements, one saying that sensor is 17MP at 45 deg with more than 20% extra pixels in both, vertical and horizontal axis.
Second announcement was that there will be 8K x 2K sensor.

I still can’t get it why only 2K pixels they choose for vertical resollution?

This will give only about 1.6K “honest” resolution in vertical axis for 2:1 format and for 16:9 format it will limit the resolution to only 2.8K of “honest resolution” horizontally, since you can’t use any more horizontal pixels if you limit yourself to 1.6K vertically.

I don’t think Sony would do it and all these reports are not accurate.
Click to expand...

17MP at 45degrees is correct. It's not 16bit, it's 14 up to 60fps and 12 beyond that (according to Sony's sensor papers).

The reason it's only 2k vertically is 2k x 8k is 17MP. And although the 17MP is correct, the 8k is not. They're measuring their rotated pixels in a way that suits their marketing "k" figure, rather than one which properly describes what they're doing. As they're bayer, they have enough MP for 5.7k and that is all. They chose to arrange those pixels differently by rotating them, but it doesn't really alter things, other than to give them a magically unreal 8k figure to throw around and the lack of a need to demosaic, just extract, so no oversampling will be going on at all at their 4k.

Graeme
 
Look what I just found:

New specs on pro sony com shows that F65 sensor have 4096x2160 green pixels so for 16:9 format you can use only 3840x2160 pixels so it is not very “honest” 4k but good enough.

“The F65 imager contains a total of 20 Mega-pixels. Half are sensitive to GREEN, and the other half are equally shared by RED and BLUE pixels. The sensor will provide pristine super-sampled HD and 2K images, and this is the first sensor in the industry that provides a dedicated green photosite for each pixel in the 4K (4096 x 2160) output image.”

Maybe that is why they are very careful and does not mention that sensor will provide HD and 2K and 4K images but they say that sensor will provide only “HD and 2K” images?


attachment.php


Andrew
 
Graeme Nattress said:
17MP at 45degrees is correct. It's not 16bit, it's 14 up to 60fps and 12 beyond that (according to Sony's sensor papers).

The reason it's only 2k vertically is 2k x 8k is 17MP. And although the 17MP is correct, the 8k is not. They're measuring their rotated pixels in a way that suits their marketing "k" figure, rather than one which properly describes what they're doing. As they're bayer, they have enough MP for 5.7k and that is all. They chose to arrange those pixels differently by rotating them, but it doesn't really alter things, other than to give them a magically unreal 8k figure to throw around and the lack of a need to demosaic, just extract, so no oversampling will be going on at all at their 4k.

Graeme
Click to expand...

The other confusing spec they claim is 16bit RAW yet they're also saying the sensor is 14bit and 12bit in high speed mode. So it sounds like they're just putting 12or 14 in a 16 bit container.
 
That would be odd, obviously, if they were putting 12- or 14-bit footage into a 16-bit container.
 
Deanan said:
Dalsa did the same thing. Convenient but not efficient.
Click to expand...

As I recall, the MX sensor is also 12 bits, although the debayer process promotes it to 16 bit precision. So if Red, at least prior to Epic, were to have offered an uncompressed RAW output in a standard container like, say, TIFF, it would have been the same as well. Am I wrong about that?
 
M Most said:
As I recall, the MX sensor is also 12 bits, although the debayer process promotes it to 16 bit precision. So if Red, at least prior to Epic, were to have offered an uncompressed RAW output in a standard container like, say, TIFF, it would have been the same as well. Am I wrong about that?
Click to expand...

If we had offered an uncompressed 12bit raw output, we would be saved as 12bit output. There's no
benefit to 4 bits of 0's especially since affects everything downstream for storage.
DPX supports 12bit packing and I believe Tiff/DNG also do.
We'll have to wait and see...
 
Deanan said:
If we had offered an uncompressed 12bit raw output, we would be saved as 12bit output. There's no
benefit to 4 bits of 0's especially since affects everything downstream for storage.
DPX supports 12bit packing and I believe Tiff/DNG also do.
We'll have to wait and see...
Click to expand...

While TIFF might support 12 bit packing, I haven't seen any vendors that do in that format, including the DCI's specification for DCDM, which as I recall is 12 bits in a 16 bit TIFF container, or at least is commonly delivered that way.
 
Craig W. Bickerstaff said:
Well I found some other websites talking about this and it sounds like the camera just doesn't have the bandwidth to deliver 16 bit raw at 60p and above.
I'm sure at 24 fps - whatever is pure 16 bit RAW motion picture.

I even found website which had this handy image which explains how Sony's 8k sensor looks different then those other 4k sensors.

http://translate.google.com/transla...04/11-045/index.html&sl=ja&tl=en&hl=&ie=UTF-8
Click to expand...

Thanks. It's not clear but it sounds like everything below 60p is 14bit and everything above is 12bit.
The 16bit seems to come from SR codec/recorder side of things.
 
So what is the deal with their high framerate? Is this 2K? Or just decreased bit depth?
 
Tom Lowe said:
So what is the deal with their high framerate? Is this 2K? Or just decreased bit depth?
Click to expand...

I think i remember watching a interview saying that 120 fps is going to be at 2k. don't know if it's windows or a full down rez.
 
Craig W. Bickerstaff said:
Well I found some other websites talking about this and it sounds like the camera just doesn't have the bandwidth to deliver 16 bit raw at 60p and above.
I'm sure at 24 fps - whatever is pure 16 bit RAW motion picture.

I even found website which had this handy image which explains how Sony's 8k sensor looks different then those other 4k sensors.

http://translate.google.com/transla...04/11-045/index.html&sl=ja&tl=en&hl=&ie=UTF-8
Click to expand...

From the Japanese translation we have bit more clear picture.
So, to simplify it is 6K x 3.16K equivalent sensor and I will not call it 8K.

Using the same logic as they are using to describe this sensor RED EPIC is 7.6K sensor.

I don't like the suggestion though that other sensors have 1/2 resolution and they show more sparse spacing or fill-in factor. The fill in factor is actually lower on the f65 since the pixel size is smaller.
This will also give them a challenge for dynamic range.

My estimation is that this thing will go up to 4.8K for 2:1 screen on res charts.
For 16:9 screen it will be 4.5K on res chart.

attachment.php


Andrew
 
Andrew M. said:
From the Japanese translation we have bit more clear picture.
So, to simplify it is 6K x 3.16K equivalent sensor and I will not call it 8K.

Using the same logic as they are using to describe this sensor RED EPIC is 7.6K sensor.

I don't like the suggestion though that other sensors have 1/2 resolution and they show more sparse spacing or fill-in factor. The fill in factor is actually lower on the f65 since the pixel size is smaller.
This will also give them a challenge for dynamic range.

My estimation is that this thing will go up to 4.8K for 2:1 screen on res charts.
For 16:9 screen it will be 4.5K on res chart.

attachment.php


Andrew
Click to expand...

My guess puts it around ~5700 x ~3000 if it were rotated 45deg back into normally oriented bayer pattern.
 
Jannard said:
Read the patent before you cough... Cineform is listed in the application. Patent granted. I just love it when people comment... and have no idea what they are talking about. No offense.

Jim
Click to expand...

So you're saying that RED holds an exclusive patent on 'wavelet encoded bayer pattern video'? And that if I created a Jpeg2k based codec for ArriRaw I would be sued?

If so I'll happily concede I have no idea what I'm talking about. If not then the statement 'nobody can use wavelets to encode RAW video' is inaccurate as I said and I don't see which part of my post you're disagreeing with. No offense.

Embodiments provide a video camera that can be configured to highly compress video data in a visually lossless manner. The camera can be configured to transform blue and red image data in a manner that enhances the compressibility of the data. The data can then be compressed and stored in this form. This allows a user to reconstruct the red and blue data to obtain the original raw data for a modified version of the original raw data that is visually lossless when demosacied. Additionally, the data can be processed in a manner in which the green image elements are demosaiced first and then the red and blue elements are reconstructed based on values of the demosaiced green image elements.
Click to expand...

Unless I know absolutely nothing and have no reading comprehension. The patent is for a unique means of preparing the data *for* compression. Not the part which I disagreed with which was the idea that 'nobody can use wavelet compression to compress RAW video'.
The word "Wavelet" doesn't even appear anywhere in the patent. Assuming we're discussing the same one. (7,830,967)

I feel like the only reason there seems to be any disagreement is because you think I'm saying something that I'm not. And I'm not sure what that is.
 
Erich Ocean said:
It may very well be intraframe only, and adding trimming was simple. But I'm certain the version in RedRay is interframe (that's the only way I can think of to get data rates that low), and it doesn't seem at all unreasonable that REDCODE would be interframe as well.
Click to expand...

Not unreasonable, but intra-frame compression was used as a bullet point on REDCode's feature list for some time. I haven't heard it brought up recently one way or another. It's entirely possible things have changed ('Count on it" :P) but I've never heard anyone from RED change their position on intraframe compression being an advantage of REDCode.
 
You must log in or register to reply here.
Back
Top