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 :)

The next 4K digital mag for Aäton Penelope described by JP Beauviala! [english subt.]

I think it is terrific that Aaton is doing this... more options for the customer.

Jim
 
hunterrichards said:
beautiful- get that cat on my shoulder..
Click to expand...

When I first heard that expression, I put my cat on my shoulder and though, wow, it would be great if a betacam felt like this. I hear Aaton's are great on the shoulder but I have never actually seen or held one.
 
Jannard said:
I think it is terrific that Aaton is doing this... more options for the customer.

Jim
Click to expand...

Yes. The industry seems to be headed for a very healthy and very critical period of serious competitive development. Panavision, Arri, Aaton, Red, Phantom, Sony, Canon -- this is starting to look like a real horse race. Having all the players finally focused on serious digital acquisition will drive huge innovations in sensor design, workflow, post options and the long awaited propagation of digital exhibition.

And the credit for this accelerated pace rests squarely on your shoulders, Jim. No doubt about that.
 
Why not view the uncompressed 4k as a digital negative, as in we don't edit
with physical negative, we edit with a workprint.....so take the
uncompressed 4k and make a Compressed workcopy of it to edit with...
then conform the uncompressed for final output.

Of course even this would be very time consuming.

And having said this, yes, I know this is all very obvious.

Also, I LOVE Redcode!
 
Some of the numbers being floated about here are way off. Here's an example: The Phantom 65 is a 14-bit linear 4K (4096x2440) camera. The Phantom CineMags are very fancy internally raided SSDs, with a 1GB/second throughput (think about that for a moment). The file structure is stacked on the CineMags in 10-bit Log so a 512GB CineMag actually holds about 800GB of linear files once they are unpacked again. When one records the full resolution of the Phantom 65 to a 512GB CineMag it holds 32 minutes worth of Uncompressed RAW material.

This is a working system that has been in place for a few years now and we rent and sell this gear actively. It can only get better and easier for Aaton to do it in the future. This stuff works, and believe me when I tell you it is a beautiful thing.

Penelope may not be the choice for some, perhaps many REDusers. But for others it certainly will be an excellent answer. And it does not have to be an us v. them who is better sort of thing. There's room for everybody as long as they put out worthwhile product.
 
Hi,

I agree with Mitch, some numbers here are simply blown out of proportion!

On the video, when I titled that uncompressed 4K 10bit 444 @ 24im/sec represents a 750MB/sec bandwidth (actually, I should have been more accurate, the precise number is 759.375MB/sec), here is how I calculated it: 3*4096*2160*10*24/8/1024/1024 = 759.375MB/sec
3 for 4:4:4
4096 and 2160 for the official 4K format
10 for 10bit
24 for 24 im/sec
/8 to get Bytes
/1024 to get kBytes
/1024 to get MBytes
So, I may be wrong in my calculation way but to me,
uncompressed 8bit 4K 444 @ 24im/sec is 607.5MB/sec not 875.25MB/sec
and uncompressed 12bit 4K 444 @ 24im/sec is 911.25MB/sec not 1.3GB/sec
...I agree: that's still gigantic! Even with a few technical 'tricks' to reduce the flow. And knowing that JP Beauviala wants to propose a 50im/sec maximum frame rate for his digimag, meaning 1.545GB/sec of 10bit bandwidth, I understand why the SSDs will be 0 raided.
Gigantic, indeed, but not unreachable anymore.

SSDs have been making huge progresses last past few years and now make it possible to build a handheld and ergonomic recording solution.
In my view, the maine issue of 4K workflow has always been 'how to record such a flow in an ergonomic way on the set?' much more than 'how to manipulate it in post?'.
And who talks about editing uncompressed 4K on-line?
We definitely learned something about the way we've been editing 16 and 35mm film with computers for more than 25 years, right? So, do we need 4K dailies in the editing-room? I guess not. 1K proxy dailies are good enough for editing.
And, even if you want to edit uncompressed 4K, solutions are on their way.

By the way, I asked JP about the ISO of the sensor but his answer was pretty vague and off the record... Too soon to talk about it. So, it's not in the video. But he definitely has a little plan for that part, a good one I guess.
 
I appreciate the clarifications.

I also stand by my statement that I believe it will be more than a couple of years before this is an accessible solution.

Can it be done at an extremely high cost before then? Yes, okay. I'll concede that point.

Will that high cost be justified in terms of visual improvement? I guess time will tell. Frankly, I'm skeptical.

I can't argue that low-res off-line with a late-stage conform is the current standard. So does accessible 4k on-line matter?

There are definite advantages to a pure on-line workflow, which RedCode facilitates at a very low price-point. Off-line versus on-line is a tangential debate however, so let's save that one for another day/another thread. :)

Cheers,
Tim

PS - I just clicked your "solutions are on the way" link, and it underscores my point: "This product aims for the super demanding enterprise market and 2TB will probably land at $7000 price, but this is just preliminary price. " That's for an SSD that's fast enough to handle ONE STREAM.
 
Thomas Chatelet said:
Hi,
3*4096*2160*10*24/8/1024/1024 = 759.375MB/sec
3 for 4:4:4
Click to expand...

If you're recording RAW data, it's not "*3". It's simply 4096x2160x12x24/8/1024/1024, or a little over 300MB/sec, and that would be for 12 bit data. In a RAW record, each pixel has only one value, i.e., it's basically treated as a monochrome image. The RGB image is reconstructed using demosaic techniques. Only after that step does the image contain R, G, and B values for each pixel.
 
M Most said:
If you're recording RAW data, it's not "*3". It's simply 4096x2160x12x24/8/1024/1024, or a little over 300MB/sec, and that would be for 12 bit data. In a RAW record, each pixel has only one value, i.e., it's basically treated as a monochrome image. The RGB image is reconstructed using demosaic techniques. Only after that step does the image contain R, G, and B values for each pixel.
Click to expand...

Aaton's project will record in a dpx based file format.
It means if they do use a bayer sensor that the digimag will extract RGB data before recording, maybe with some 5-6K -> 4K dpx downsampling... thus the "*3" needed for the recording datarate.
 
Well, Mikeal was faster than I with a far more precise answer than I could have given. ;)
 
Last edited:
You can do a monochrome DPX with the bayer pattern in it, but at that point, what is the point of it being a DPX as no compositing system that works with DPX can make sense of Bayer Pattern data. SO all those people who think "Yippee" for DPX thinking it will run straight into their system could be very mistaken.

In the end, the data given was very vague.... But we'll wait and see how it comes out. I have great respect for anyone who can make a working 4K digital cinema camera.

Graeme
 
Graeme Nattress said:
You can do a monochrome DPX with the bayer pattern in it, but at that point, what is the point of it being a DPX as no compositing system that works with DPX can make sense of Bayer Pattern data. SO all those people who think "Yippee" for DPX thinking it will run straight into their system could be very mistaken.

In the end, the data given was very vague.... But we'll wait and see how it comes out. I have great respect for anyone who can make a working 4K digital cinema camera.
Click to expand...

S.two has been using a DPX wrapper for Arri Raw files ever since the T-Link interface was introduced. And a number of systems can unwrap and use it directly. In fact, in Arri's own Image Booster software you can select whether the files are Arri's .ari files or DPX, depending on what you used to record them.

As for compositing systems, I would say that until very recently, none of them understood R3d files, either. If the marketplace demands something, it usually gets done. File format support is usually based on need, not on whether it can technically be done.
 
Jeff Coatney said:
Yes. The industry seems to be headed for a very healthy and very critical period of serious competitive development. Panavision, Arri, Aaton, Red, Phantom, Sony, Canon -- this is starting to look like a real horse race. Having all the players finally focused on serious digital acquisition will drive huge innovations in sensor design, workflow, post options and the long awaited propagation of digital exhibition.
Click to expand...

Great. :001_cool:
 
M Most said:
S.two has been using a DPX wrapper for Arri Raw files ever since the T-Link interface was introduced. And a number of systems can unwrap and use it directly. In fact, in Arri's own Image Booster software you can select whether the files are Arri's .ari files or DPX, depending on what you used to record them.

As for compositing systems, I would say that until very recently, none of them understood R3d files, either. If the marketplace demands something, it usually gets done. File format support is usually based on need, not on whether it can technically be done.
Click to expand...

Which is fair enough, but when you say "DPX" file, people think of it as something completely different than a wrapped bayer pattern file.

Graeme
 
Graeme Nattress said:
Which is fair enough, but when you say "DPX" file, people think of it as something completely different than a wrapped bayer pattern file.
Click to expand...

Yes, they do. But that doesn't necessarily mean you can't use it in a different way, especially if there is no other file format that is particularly suited for the particular need. DPX as a format has a lot of room for both essence and metadata, and it is a file that by definition defines one frame, as opposed to a wrapped movie file. It is also recognized by a lot of copy, backup, and SAN software on various platforms as a format that implies an image sequence, allowing sequence aware utilities to do their work efficiently. So rather than invent a completely new file format, using an existing one as a container has some advantages.
 
You must log in or register to reply here.
Back
Top