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

EPIC HDMI output less noisy than recorded footage?

K

Karl H

Well-known member
Joined
Jan 5, 2007
Messages
612
Reaction score
0
Points
0
Seems odd but here goes.

I'm piping out footage from Epic to my 1080p HDMI monitor. To see the noise levels at different ISO's I crank it up to 5000 ISO and it looks surprisingly clean over HDMI. So I record a chunk on Epic and play it back - now it looks much noisier, lots of chroma noise in the blacks which isn't on the live signal. But I realise that the playback of footage isn't a full debayer from the camera, so I bring my footage into Premiere but it still looks noisier than the HDMI output at 1080p.

I also tried it in RCX, and again the noise is worse on the recorded image than live. I did another test at 4:1 compression thinking the chroma noise may be introduced when recorded, but no real difference from 4:1 - 9:1

Unfortunately I cannot grab a shot from the HDMI output as I have no capture device, has anyone else noticed this too? Anyone with an external recorder done a comparison with r3d files?

EDIT : for clarity, Im not comparing 1:1 to a downsampled image, I'm comparing the HDMI 1080p, to recorded r3d also downsampled to 1080p
 
I didnt make it clear but Im also comparing the noise in the recorded image at 1080p (downscaled).
 
This is not normal, and not what we see here.

Make sure you are properly decoding your Raw footage, using premium/full. Anything less as a setting will result in added noise. Premiere realtime playback is really low quality - it's just intended for editing - you can see focus and framing, but that's about it and it has a lot more noise that the final rendered output. It is also possible that your set monitor has a steep gamma that is flattening the low IRE areas, but you can replicate that effect easily with a curve.
 
yup, its a full debayer. I have tried both in RCX and Premiere. Fully debayer on both. Premiere you can view in full debayer mode but you won't get real-time playback or anything near.

The monitor I'm using is a 1080p Dell which is also used to edit from - just switch the input from HDMI to DVI - so I think the settings on the monitor are pretty much identical, no difference in curves.

Also to add, I'm talking of high ISO mainly. HDMI pretty clean in the blacks, recorded footage has dancing chroma noise. I notice this much less at lower ISO's (as the chroma noise is pretty much crushed). Wish I could capture my HDMI output and put up an example....
 
I think the SDI out simplifies the signal crushing the blacks - not sure. Some monitors clip below 9 IRE, but only sometimes (like when fed HDMI which they expect is video legal signal only) that would flatten all the darks down to a noise-free full black. Whatever your monitor is doing to sweeten things, it's not magic and could very easily be replicated in post.
 
Ok, I think I know what its is, and it's compression. Before I get flamed .... my thinking is simply because ISO in r3d is metadata. So what's recorded is always the RAW histogram, not the artificially boosted histogram when you crank up ISO.

At 5000 ISO my histogram looks to be about right, ETTR and all that - but if I touch the histogram on my LCD and actually switch it to RAW view - its obviously much much worse. The blacks are at the low end of the histogram, in fact most of the image is as you'd expect for a low light shot. When cranked to 5000ISO the histogram is normal - but this isn't what's recorded in R3d (to my knowledge). Only the RAW histogram is regardless of what ISO you're viewing. Obviously in the RAW signal most of the image is in the worst place for the compression system, on the left, therefore introducing more noise in the low end.

If I tried to send the RAW view out of the HDMI to a capture system, record it, and then boost the signal then I'd get tons of noise in the shadows too. I think that's exactly what Epic is doing.

However, if you boost to 5000ISO and record from the live HDMI, in theory whatever you feed that signal into is going to record the boosted histogram and so not introduce the noise into the blacks. Recording this signal in RGB in these conditions would actually be better because you're correcting the image before sending it to the compression system.

Just a thought, more than happy to be told I'm talking out of my ass.... but if this is anywhere near true then having an RGB recording option would be a godsend for very low light shots
 
Rob Ruffo said:
I think the SDI out simplifies the signal crushing the blacks - not sure. Some monitors clip below 9 IRE, but only sometimes (like when fed HDMI which they expect is video legal signal only) that would flatten all the darks down to a noise-free full black. Whatever your monitor is doing to sweeten things, it's not magic and could very easily be replicated in post.
Click to expand...


Hi Rob, really you couldn't get the same result in post. The blacks are much noisier, but I realise now this is only for low light shots.

Simply put, EPIC always records RAW which in low light shots is a very poor histogram for any compression system. It applies ISO after it's recorded, not before, which is a problem for compression in low light. The HDMI output is cleaner because it hasn't yet been compressed.

So on playback, boosting to 5000 ISO will therefore be amplifying any compression in the dark areas. The higher the ISO the more you'll see large compression artifacts because you're digigng more into the lower end of the signal - which you wont see on the live output. It's quite a significant difference. In that respect its no different to underexposing on a regular camera, recording underexposed, and then trying to boost the image in post. You'd never do that, you'd apply gain first then record, but Epic doesn't work this way. Ideally we'd need an option to record in RGB - so the signal on your histogram is what's actually sent to the compression engine and not the one thats x stops under.
 
This could be very useful for low light - to bypass the compression entirely.

When RED fixes the HDMI 24p output, I'll test some low light recording to 1080p24 4:4:4 (can I call debayered output 4:4:4?)
 
I think it is the same beetwen what you see on the computer screen in RCX an what you see using the HDSDI output from the RedRocket inside the same RCX : the image seems less noisy. I think you are trying to compare 2 images that are not really matchable.


Olivier
 
best way for comparison is to render out 1080p uncompressed dpx and play that out of an I/O card back into your reference monitor, and compare that to what's coming out of the camera. if what is coming out of the camera is still cleaner than this might be an issue. but the method as you are trying it now doesn't stack up at the moment because a hdmi signal is full 10 bit uncompressed, and what's coming out of the camera is in a legal space. while the dvi is limited to 8 bit, and probably attempting a full range space in a 8 bit stream so the results will look different. have to keep it one singular signal to know for sure.
 
Les C. said:
This could be very useful for low light - to bypass the compression entirely.

When RED fixes the HDMI 24p output, I'll test some low light recording to 1080p24 4:4:4 (can I call debayered output 4:4:4?)
Click to expand...

please do as I cant presently record the HDMI signal from mine. I don't think you'd need to bypass the compression, just have an option to process the ISO/gain before the signal is recorded (I'm sure the wizards at Red can add this)- of course I think that means you're out of RAW space, but in high ISO situations RGB may actually be a better option. I'm no tech expert tho :/

Olivier Madar said:
I think it is the same beetwen what you see on the computer screen in RCX an what you see using the HDSDI output from the RedRocket inside the same RCX : the image seems less noisy. I think you are trying to compare 2 images that are not really matchable.


Olivier
Click to expand...

But you're talking about a signal which in both your instances are coming from a compressed r3d file, so I don't think it really applies to this situation. But I hear what you're saying about a different 'look' coming out of different ports compared to a monitor display. I don't think that's what I'm seeing here.

Tom.Wong said:
best way for comparison is to render out 1080p uncompressed dpx and play that out of an I/O card back into your reference monitor, and compare that to what's coming out of the camera..
Click to expand...

agreed, but I don't have that equipment. I am using the same monitor for both editing and on set monitoring, so that helps a bit. I can view RCX fullscreen and then switch the input to HDMI (it's the best I can do here for comparison). The HDMI signal needs to be recorded first before anything concrete is established tho.

Dan Kanes said:
Four things:

Downsampling

Gamma

Levels Clamping on the monitor via HDMI stream

What is your Redcode
Click to expand...

2 of these points I've already covered, but I'll restate : I'm comparing downsampled output (1080p) to downsampled r3d files (1080p), comparing the chroma noise on both, on the same monitor - so I don't know what you're trying to say about downsampling?

Also I've already said I tested as low compression as my Epic will allow (4:1) and the noise is still worse on that R3D file at 1080P full debayer, than on the live HDMI feed.

Re : the levels and gamma over HDMI v R3D file - there may be a slight difference. Agreed I need to record the HDMI signal first to do a proper comparison side by side. However, all things being equal they look about the same contrast wise and thats all I can do with the tech I have to hand. I'm viewing redgamma 3 over HDMI and redgamme 3 from the R3D, on the same monitor too.

Would love to hear from anyone else who's actually tested this scenario and compared, then I'll know if Im talking crap or not. My brain tells me it's kinda logical that if the ISO is applied after signal has been recorded, and not before, then you're going to boost any problems with that compressed signal - especially as the shadows get less 'attention' in any compressed system. The higher the ISO boost in post, the bigger the artifacts will be. Think of any pro-res file recorded unexposed and then boosted in edit - it would look much worse than applying gain in-camera and then recording to pro-res. Any non-raw camera would get round this because the image is processed before it's recorded to disk but RAW doesn't work that way on Epic AFAIK.
 
I posted this question a few weeks ago: which downscaling algorithm is used by the camera internally to downrez to 1920x1080 (who knows?) and what algorithm did you use for your downscaling? There are 6 or 7 algorithms to choose from and each one gives a slightly different look; some give a sharper image and more noise, others are softer and/or handle noise in a different way. So, i'd like to know what algorithm is used inside the Epic (and scarlet) before the image arrives at the HDMI or SDI output!

Martin
 
Karl H said:
Hi Rob, really you couldn't get the same result in post. The blacks are much noisier, but I realise now this is only for low light shots.

Simply put, EPIC always records RAW which in low light shots is a very poor histogram for any compression system. It applies ISO after it's recorded, not before, which is a problem for compression in low light. The HDMI output is cleaner because it hasn't yet been compressed.

So on playback, boosting to 5000 ISO will therefore be amplifying any compression in the dark areas. The higher the ISO the more you'll see large compression artifacts because you're digigng more into the lower end of the signal - which you wont see on the live output. It's quite a significant difference. In that respect its no different to underexposing on a regular camera, recording underexposed, and then trying to boost the image in post. You'd never do that, you'd apply gain first then record, but Epic doesn't work this way. Ideally we'd need an option to record in RGB - so the signal on your histogram is what's actually sent to the compression engine and not the one thats x stops under.
Click to expand...

Very interesting. Does 3:1 help? Maybe I'll pick up one of those cheapie BM recorders and do some tests. Here is yet another area where Red One never caused big problems. I have mine for sale here. Maybe I shouldn't sell her after all.
 
Martin Beek said:
I posted this question a few weeks ago: which downscaling algorithm is used by the camera internally to downrez to 1920x1080 (who knows?) and what algorithm did you use for your downscaling? There are 6 or 7 algorithms to choose from and each one gives a slightly different look; some give a sharper image and more noise, others are softer and/or handle noise in a different way. So, i'd like to know what algorithm is used inside the Epic (and scarlet) before the image arrives at the HDMI or SDI output!

Martin
Click to expand...

My guess is Bilinear, but I don't really know. They may have coded their own take on it.
 
Last post for tonight.

I've done some more tests and I think I can pretty much confirm that this is the compression of the R3D. I recorded high ISO footage from 4:1 up to 18:1 and indeed the artifacting is worse as the compression is increased. So I think that eliminates debayering and downsampling methods. Anyone else care to test?

I stress that this is for very high ISO settings, so most of the time you're not going to notice this. But for anyone shooting low light, you probably will. The live feed is superior to the recorded file. It can be confusing because if you have your LCD set to view 5000ISO or are piping out 1080p to a monitor, you might think it looks fine until you play it back.

Every camera has a noise floor and I'm not trying to pretend Epic is the perfect camera, but if there's a way to record high ISO cleanly then hopefully Red will find a way to do it.They normally do.
 
You must log in or register to reply here.
Back
Top