Welcome to our community

Be a part of something great, join today!

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

Fixed + X = 1080p heaven

Steve Wake

Well-known member
Joined
Dec 7, 2009
Messages
386
Reaction score
0
Points
0
Location
SF Bay Area
I think a lot of potential Scarlet Fixed users have nothing more than 1080p output in mind (and in a lot of cases the final product may only be SD DVD's). A lot of us probably would like to not have to add a lot of hardware, too.

So, after rolling around some specs and features and unknowns (like #21) in my head, I've come up with a list of possibilities for 1080p output that I'd like the RED team to consider. The items I've been musing about include: raw output; 3K has about 2.5 times as many pixels as 1080p; lookaround; 3 gyros that tag each frame with their data; software designed by the camera manufacturer.

Combine these in different ways and I think it's realistic to ask for:

  1. Software-based steadicam. Take the gyro info and use it to stabilize the path the camera took during its handheld move. Allow the editor to adjust the path. Greater flexibility in adjusting the path if cropping/downrezzing to 1080p. Could also record the lookaround area and keep the original framing to maintain 3K. (This is separate from any in-camera image stabilization that I hope is the missing feature #21, but if the two were combined there might be an incredible synergy).
  2. Wide angle enhancement. Record the lookaround area, downrez to 3K in-camera. Probably would restrict the framerate to allow for the additional processing, but shouldn't be a problem in most cases.
  3. Simulated Zoom enhancement in Post. Software based, but could give superior results compared to Motion-generated Frames given we're starting with raw files.
  4. Noise reduction through downrezzing to 1080p in post. Again, take advantage of raw processing. I would love to get downrezzed 1080p iso 1600 footage that was as clean as 3k shot at native iso (320?).
Anyway, that's a start. I have no idea how realistic any of this is, nor whether it's already covered in existing RED software. When I have time I'll follow the advice of others, download some clips and software, and start getting familiar with processing RED raw files.

When considering the possibilities of opening up an entirely new customer base of lower-end filmmakers, including prosumers, I think these suggestions would make the Scarlet fixed a lot more appealing.
 
I'm sure noise reduction can be applied, but 3K RAW to 1.92K RGB (1080P) is not a big resolution reduction/downsampling step that can hide a lot of noise.

Also, remember that RAW-to-RAW downsampling isn't going to happen so you aren't going to get some sort of full sensor RAW to 3K RAW (assuming 3K is not full sensor) conversion -- if the RAW signal is being converted to anything, it's going to become RGB. And 3K RGB is three-times the data of 3K RAW. In fact, I wouldn't be surprised if 1080P RGB was about the same data burden as 3K RAW.

People here keep confusing RAW with RGB. 3K RAW and 1080P RGB are not all that different in resolution. Essentially 1080P RGB is 1.92K each for red, green, and blue, or about 6.6MP total. 3K RAW, if 3072 x 1728, is about 5.3MP.

You have to figure that 3K RAW will end up measuring around 2.5K hopefully when converted to RGB. That's not a huge leap over 1.92K.

Think of 3K RAW as being the "RAW" equivalent of 1080P RGB.
 
Last edited:
As i understand scarlet going to use the full sensor and be able to downsample to 1080p raw.
 
The RED team is going to give us what they want and can give us. Nothing more nothing less. Is useless to ask for anything at this time. The Scarlet is still very far away. Farther than many think it is. Wait and see.
 
Thanks Deanan I tried finding the post with this info to backup my memory. Good to get that straight./Joel
 
I think you're missing my point, that people have to stop thinking it's just a direct downsample from 3K to 1.9K, when it's also a conversion from RAW to RGB as well. 2.5K to 3K RAW is what you need to make a good 1080P RGB conversion. It's not really a lot of oversampling.
 
I think you're missing my point, that people have to stop thinking it's just a direct downsample from 3K to 1.9K, when it's also a conversion from RAW to RGB as well. 2.5K to 3K RAW is what you need to make a good 1080P RGB conversion. It's not really a lot of oversampling.

I got the point, and I vaguely remember reading that somewhere before, but now I think it will stick. So most of what I thought would be possible won't be, at least not at any extreme level. Still, #1 would be nice. Those gyros in feature #22 must have some kind of interesting use! And while the view around the edges of the frame provided by "lookaround" is nice, it seems more like a waste of pixels that I would rather see recorded - at least some of the time. I can always look up and look around.

Though I've done some video work, I haven't bothered to learn the inner workings of video signal processing to the same extent as I have with still photography. Having had the experience of processing raw stills, the possibility of manipulating raw video files is very intriguing. One thing I think I learned from another post (that degenerated into a pissing contest) is that ISO is simply carried as metadata in the Red RAW format. So Red RAW is apparently even more raw than any still photo RAW format I know of. This also tells me there is no gain ever applied to the signal in camera, which I've always assumed is done with most other cameras, still or video, at some point in the process of increasing ISO.

This interests me because I assume the 1080p output would have ISO baked in and maybe some noise reduction and maybe some compression in addition to the small amount of downsampling already done in camera. When you say it's also converted to RGB, does that mean a colorspace (I don't know the video term) and maybe color temperature has been locked in so grading won't have the same flexbility as the 3K totally RAW file? Is there anything still raw about the 1080p output, or are all the references to 1080p raw simply incorrect?

And bottom line, what would be the advantage of recording 1080p RGB (raw?) over 3K RAW? If this is all written up elsewhere, just point me in the right direction.

Thanks. I know we noob's can be frustrating, but get used to it. Scarlet is expanding your customer base exponentially. Hope that means more $$ to those that deserve it.
 
Last edited:
I don't understand the appeal for a 1080p RGB recording format on the Scarlet or Epic. Being the RAW format will provide a much more flexible post-production format that you can then "bake" or lock in all of the other metadata, iso, color, exposure, etc., that you would like.
 
Well, it's certainly possible for the 1080P RGB conversion to contain all the dynamic range and color information in the RAW file, possibly as a LOG image.

I think the reasons for offering such a feature are for people doing a 1080P workflow who don't want to deal with the conversion step in post.
 
I think the reasons for offering such a feature are for people doing a 1080P workflow who don't want to deal with the conversion step in post.

Yes, that is what many are hoping for, but.... What conversion step are they hoping to eliminate?

3K 12bit RAW equates to 6.75MB per frame (uncompressed).

1920x1080 RGB 10bit (30bits/pixel) equates to 7.42MB per frame (uncompressed).

So, given that, assuming both formats use a similar form of "REDCODE" wavelet compression, what is it that everyone hopes to achieve by recording to 1080p RGB within the camera? Of course, it eliminates the debayer processing as a step in post... But with computers continuously getting more powerful and 3K being pretty manageable now on current hardware, I'm not sure I see the appeal of restricting oneself to recording in RGB over RAW. Conversion in post is still necessary at some point for finishing and delivery.
 
So the hvx should be 1.44k since it not full raster. I wonder if it been such a sucess if they went on market with that as slogan. I wish for more pixels to push in near future!!
 
Yes, 1080P is 1920 x 1080 pixels, therefore can be expressed as "1.92K" if you wanted to.

My point was that in the digital cinema resolutions, one K is 1024 pixels, not 1000. If it were 1000, 1080p would be 1.92K but to make it directly comparable to 2K and 4K it should be 1.875K (that is, 1920/1024 = 1.875).

1.92K would be 1966.08 pixels if we take 1K as 1024 px.
 
I think you are confusing yourself. "2K" is generally 2048 and "4K" is 4096, but that doesn't mean 1920 isn't 1.92K, it doesn't become 1875 pixels (which makes no sense) just because the terms "2K" and "4K" are approximations for 2048 and 4096.

The point is that 1080P is 1920 pixels across and 2K is 2046 pixels across, i.e. very similar.

No one would ever call 1920 pixels "1.875K" -- you would never use a specific number that is outright wrong or different than the actual number, unlike "2K" which is considered a generalization in the industry, not specifically 2000 pixels. It would be like saying "2.43K = 2791 pixels" or some such nonsense. It would be more accurate to say that 1080P is also "2K" -- given that it is a generalized term -- rather than to give it a wrong value like "1.875K" so that 2000 = 2048.

Unless someone failed to send me the memo that 1000 pixels is officially equal to 1024 pixels.

Just looking at the DCI white paper, for example, "2K" projection is 2048 x 858 pixels for scope movies and 1998 x 1080 pixels for 1.85 movies. So "2K" doesn't always refer only to 2048. Same goes for getting a 2K or 4K scan of 35mm -- depending on if they are scanning Full or Academy Aperture, the horizontal resolution may be different; 2K is 2048 and 4K is 4096 for Full Aperture only.
 
Last edited:
I see. I was under the impression (from the more common resolutions of 4096 and 2048 pixels being 4K and 2K respectively) that the system used 'K' as a binary prefix, similar to kilobytes (where 1KB = 1024 bytes, so a 2048 byte file is 2KB and a 1920 byte file would 1.875KB for example). I guess it doesn't really matter since the resolutions are so arbitrary though...
 
Back
Top