unimpressed with build 16

[sander kamp]

Sorry to say so, but since this is the complaint department I might as well use it for that. Maybe my expectations were a bit high after all the hyping by Jim. Don't get me wrong, I admire Jim for his enthusiasm and perseverance and I am still happy with the camera, but if I could choose now I'd rather go back to build 15. Why? Because even with the flaws of build 15 my camera was highly predictable and reliable. Sure it made some errors in high contrast situations but they were very rare. Over the course of months it never gave any real problems, it would occasionally hang on start-up in the morning but never in the day and never did I have to re-load the software.

With build 16 I feel my camera has become less reliable. Whether coincidence or not, but while never over-heating on build 15 it has done so twice in the past week. First time it was clearly very hot, second time they said (I wasn't around) it wasn't. After the first time over-heating the camera locked up and I had to reload the firmware and reset all the parameters to get it working again. Build 16 has also brought me errors that were not there in build 15.

A quick break-down:

startup problems:
- I really think a camera that is used for serious productions should not have start-up problems, but if I have to choose I'd rather have them in the beginning of the day like with build 15 than randomly like with build 16

errors
- I had one occasion where on record the camera gave an internal error on recording
- some clips had a strange bleached frame in the first few frame
- last frames of the quicktime movies are white
- still double clip naming errors - the random characters at the end of the file name prevent some problems but it feels more like a hack than a solution


user interface
- the logo is unnecessarily blocking the view when the camera is starting up
- the icon for the rotary button on the viewfinder is in a weird place and blocking the look-around area
- the waveform is hardly visible now
- still huge scary warnings when something is wrong
- still general unresponsiveness when changing numbers: going to the maximum frame rate takes patience and time
- overall the UI feels just less coherent and clean than in build 15.

Anyway, the RED team is doing a great job, just wanted to give my input. Build 16 is not a bad thing, but 'an entirely new camera'? Not really. I would have loved to have a look at it and then decide to wait until it works better but not being able to go back to 15 is my biggest complaint about 16.

Sander

[Greg M]

Personally I find B16 more stable than B15, and the improvements significant. You should consider sending your camera back to Red for Eval, we have limited issues with ours and definitely don't experience your overheating and reliability issues. Actually ours is quite stable....wouldn't consider going back to 15 if it was an option.

[shashbugu]

still getting codec errors, frame rate too high, internal recording error, build 16 upddrade failed

[Greg M]

still getting codec errors, frame rate too high, internal recording error, build 16 upddrade failed

what media are you using? have you called Red?


FYI- frame rate too high is not an "error" it means your frame rate is too high for the selected media.

"build 16 upddrade failed "
sounds like you dont have build 16 installed yet...did you read ALL the instructions before upgrading to B16??

[sander kamp]

Personally I find B16 more stable than B15, and the improvements significant. You should consider sending your camera back to Red for Eval, we have limited issues with ours and definitely don't experience your overheating and reliability issues. Actually ours is quite stable....wouldn't consider going back to 15 if it was an option.

That's the thing, I didn't have those issues with build 15 either. And how do I know if sending my camera in will solve anything?

[Gunleik Groven]

The single thing that makes life harder with 16 is the low luma level of the full-frame waveform.


That's really a dealbreaker.
And a strange one too.

Also it seems to me, that the lower noise comes from a de-noising thing happening in post when the files are loaded into the developing software, not really in camera.
If that is the case, I would love to have controll over thatr de-noising. I think I actually could get less noisy and more pleasing images with 15, oddly enough :)

Of course, if you hit auto WB and shoot and develop @ your hearts content, the de-noising is neccesary, but if stuff was properly developed in 15, you could still get pretty noise-free images in low-light...

Just my 2c

Gunleik

[sander kamp]

The single thing that makes life harder with 16 is the low luma level of the full-frame waveform.

Agreed. It was my favorite tool to get proper exposure in build 15 and for many of the DP's I worked with too. In build 16 it is almost impossible to see and some of the top green dots are seemingly without reason brighter while the blue line indicating shadows is gone.


Also it seems to me, that the lower noise comes from a de-noising thing happening in post when the files are loaded into the developing software, not really in camera.
If that is the case, I would love to have controll over thatr de-noising. I think I actually could get less noisy and more pleasing images with 15, oddly enough :)


I feel somehow that build 16 footage is softer than build 15. And it is a bit strange nobody has posted examples of the dramatic jump in quality build 16 was supposed to give. But image quality is not something I worry too much about. It was good and still is good, just a bit different.

[Stuart English]

The single thing that makes life harder with 16 is the low luma level of the full-frame waveform.

I know that we did fix that, perhaps between the release Build 16 and the alpha of 17. I'll have to check.

[Stuart English]

build 16 upddrade failed

So which build is the camera reporting in the video monitors on power up shashbugu ?

[jbeale]

And it is a bit strange nobody has posted examples of the dramatic jump in quality build 16 was supposed to give.

In fact, Jim, and several other people did do just that when b16 came out. Jim's image was a closeup of a car tire, not too exciting but image was very noticeably less noisy in the blue channel, a bit better in green, about the same in red.

[Joel Kaye]

Of course, if you hit auto WB and shoot and develop @ your hearts content, the de-noising is neccesary, but if stuff was properly developed in 15, you could still get pretty noise-free images in low-light...

The build 16 blue channel noise is much nicer. The noise pattern when you underexpose or have to shoot low light looks more filmic to me. But you're right, with 15 I could make perfectly clean images when the light was good. Same with 16. 16 has been an overall benefit to me.

[Gunleik Groven]

:)

More like: I can make build 15 lowlight footy pretty noiseless even with very little contrast. With 16 I think it looks a bit more smudgy...

It looks like it is kinda harder to get sharp lowlight footy...

After a bit of tinkering, I found the b15 bluechannel... manageable...

Just to clearify :)

But who wants frames with mostly darks anyway? :)

[conrad gaunt]

I've never tried rc36 because of the lack of Red Raid supply, but rc28 is good, but not great, though sometimes it is great. I know larger images can potentially withstand more compression than smaller ones, but is that at the cost of robustness?
I sometimes feel like areas of the image have had a medium filter applied (and also purplish dithering sometimes), and I bet if I suggest it looks like noise reduction has been applied, Rob will probably pop up and point out it hasn't. But is that not actually what is happening when the wavelet compression algorithm throws away/quantizes small detail coefficients?
Anyway, I'm not too worried yet, as rc36's extra bandwidth should help quite a bit, but RC42 would sound better if we had the output speeds necessary. I care much more about the codec than any other firmware features, although pre-record was a very useful extra.

It would be good if Epic/FutureBeast had a choice of compression optimizations

eg,
1) Normal
2) One for high detail/natural scenes
3) CGI
4) Non-perceptual compression, where Blue is given extra emphasis for when channel data will be swapped about in post

A bit like how you can choose detail level before debayering, but for compression optimization.

This could also allow Red to have a stable algorithm, along side a beta and an alpha algorithm, potentially, at the same time.

There could also be an analyse button which, when pressed, looks at the sensor data (without recording) and chooses the most appropriate compression mode (with a manual override, of course). Just a thought..

[Esteban Sosnitsky]

I just changed to Build 16, improvement is there. But there are still issues with noise. I think that has always been the problem with CMOS sensors against CCDs. I really like the new Build and I cant wait for another revolutionary new build to come. Thanks RED team, keep pushing the envelope.