CDNG is the most obvious choice since that’s the other Raw format the UMP can encode directly.

I guess the obvious choices are things that might cover: resolution, noise, colour resolution - and anything that might throw up debayering errors. Some people have suggested BRAW is a YCRCB codec as there is some ghosting in the red channel at high contrast edges.

CDNG is the most obvious choice since that’s the other Raw format the UMP can encode directly.

I guess the obvious choices are things that might cover: resolution, noise, colour resolution - and anything that might throw up debayering errors. Some people have suggested BRAW is a YCRCB codec as there is some ghosting in the red channel at high contrast edges.

CDNG is the most obvious choice since that’s the other Raw format the UMP can encode directly.

I guess the obvious choices are things that might cover: resolution, noise, colour resolution - and anything that might throw up debayering errors. Some people have suggested BRAW is a YCRCB codec as there is some ghosting in the red channel at high contrast edges.

Leaves swaying in the breeze and gurgling water have always been my go-tos for testing compression.

If the compression is inter-frame like h.264, sure. But I had assumed (although I don't know if this is confirmed) that BRAW is an intra-frame compression scheme, in which case movement is not relevant, except insofar as it may add motion blur to the images, which actually helps compression.

Leaves swaying in the breeze and gurgling water have always been my go-tos for testing compression.

If the compression is inter-frame like h.264, sure. But I had assumed (although I don't know if this is confirmed) that BRAW is an intra-frame compression scheme, in which case

I would still say Leaves are better than water. High shutterspeed and you'd be able to easily see the compression artefacts inside a frame. There are some great examples with R3D showing the way increasing compression changes the image (using distant leaves).

If you shoot with uncompressed DNG (Is that possible) and then some compressed variants of BRAW then that would be a great control/baseline for checking compression but also debayer sharpness. You can take a single DNG as a master and process that to see what kind of flexibility you loose with BRAW, if any.

The rest is colour stuff and that's usually eyeballing and feeling. You could shoot way off on white balance to see whether you can fix that afterwards like RAW. The question is what are you missing with BRAW.

There was an interesting interview in the latest F&D times where Jarred @ Red implied they licensed some aspects of compressed RAW to Apple. Wasn't *directly* said but that was the implication. I presume BRAW hasn't licensed anything hence this approach.

CDNG is the most obvious choice since that’s the other Raw format the UMP can encode directly.

I guess the obvious choices are things that might cover: resolution, noise, colour resolution - and anything that might throw up debayering errors. Some people have suggested BRAW is a YCRCB codec as there is some ghosting in the red channel at high contrast edges.

first of all, BRAW is surely an i-frame only codec, which means it
should be absolutely irrelevant if you have a fast moving scene or
not when it comes to the result of each single frames compression.
Each frame is compressed individually without any relation to
previous or following frames. That makes it fast on decoding, as
you can jump anywhere in the timeline and do not need to wait for
decoding previous or later frames to decode the actual image
(which is the case with any GOP based codecs like MPEG1/2/4, H265
etc.). As Nick & Paul already pointed out, motion blur will
actually help compression, as its a natural low frequency
smoothing smear over otherwise high frequency detail. So it might
be interesting to use a typical 180° shutter and - only additional
if you find it useful - forcefully a very short shutter for
ultra-sharp images (we know you don't like them anyway).

To me the typical 180° shutter is way more interesting than the
hypothetical ultra sharp short shutter, because if the tests tells
us later that THIS is going to be a bad combination with
compression, we just learn that we should shoot this in CDNG or
uncompressed then...

What might show off codec compression artefacts is usually high
noise/frequency content, i.e. grass, leaves, gravel, windy water,
moire-effect forcing "check patterns" or "pin stripe suit" silks.
Then of course green sceen or blue screen with fine contour
details like single hair, wavy curtains with embroidery, or fine
grass in front of it. Even a not to close close up to really gray
hair (should be available...) on a "hair thickness is not much
more than 1-3 photosites" is often good to reveal color
interpolation (demosaic) issues. Thats the stuff where we see it
in post. The finer the detail, the more likely its hard to
reproduce with compression. Each compression scheme tries to
reduce high frequency noise - thats where the details go...

CDNG is very interesting in that context, as is ProRes444 highest
settings (at least).

A stable calm set might seem better than a highly changing set, as
you can not 100% compare the frames. But I agree, we are
interested in motion artefacts visible due to compression. As the
compression is frame by frame, it might hit each frame a bit
differently and might show off artefacts that are less visible in
each the stills than in motion sequence. As its obviously a DCT
codec, we should have an eye on if we can see/reveal grids at some
point (aka JPEG artefact), preferably using an excessive gain in
post.

Dynamic compression ratio (quality based, so more complex frames
will be bigger) can be expected to show off a constant quality of
artefacts (if any).
Fixed data rate settings in turn will show way more artefacts on
fine detail content than on smooth and easy content.

What I also would like to see - if you can manage it - is a clear
dark blue sky horizon. Something where the gradient in blue is
very very small and subtle. I have a clip from a RED camera (not
shot by myself) that is perfect for showing what the difference of
an 8 bit vs. a 10 bit display is like. You see color banding on 8
bit displays, while its super smooth on 10 bit displays. That is,
because there is very low noise in it. If I dither down to 8 bit
(distributing the error by "intelligently" adding the error as
kind of noise) you can make it look nearly as good on 8 bit as on
10 bit - but you file is less good compressable. Here is were you
learn that low end distribution codecs have their own set of
problems...

This e-mail may contain confidential and/or privileged
information. If you are not the intended recipient (or
have received this e-mail in
error) please notify the sender immediately and destroy
this e-mail. Any unauthorised copying, disclosure or
distribution of the material
in this e-mail is strictly forbidden.

CDNG is the most obvious choice since
that’s the other Raw format the UMP can encode directly.

I guess the obvious choices are things
that might cover: resolution, noise, colour resolution - and
anything that might throw up debayering errors. Some people
have suggested BRAW is a YCRCB codec as there is some
ghosting in the red channel at high contrast edges.

Jeff, as far as I know you can't record in Cineform with the BMD
cameras.
I could only transcode the BRAW result into a Cineform RAW. If I
know the orientation of the Bayer pattern, I can strip out all
interpolated pixels and re-create a Cineform RAW file.
However, we are then comparing the Cineform build-in RAW demosaic
(and there are 5 options...) vs. BRAW demosaic. The rest will be
the same.

What I don't get with BRAW is that it is not a codec I can use in
post and until a master export as long as its treated as RAW. On
the other hand, if its really a 444 codec inside, then that might
change by at some point burning in color and using the same
compression scheme plus a setting that is no longer the camera
sensor specs and whitepoints etc. but those of my mastering color
space like REC709, REC2020 or whatever comes to mind. No idea if
that is on the roadmap or in any way possible.

Cineform 4444 is surely made for exactly this purpose.

I am preparing my codec test for this part, and one thing that I
want to look at is iterative recompression. Here some codecs fail
quickly, others hold up fantastic. I wan't to prove that with some
sample content. Currently investigating which content might make
sense for this, like downscaled 8K RED material or scanned film or
simply BRAW files for instance. The point is that RED often
demonstrates the camera with high noise detail imagery (like night
sky large city skylines) vs. Geoff loving smoothed female skin
tones... Thats two different shows and they are very different in
post and in the context of compression etc.

This e-mail may contain confidential and/or privileged
information. If you are not the intended recipient (or
have received this e-mail in
error) please notify the sender immediately and destroy
this e-mail. Any unauthorised copying, disclosure or
distribution of the material
in this e-mail is strictly forbidden.

Sunlit Hedges or backlit leaves are great for getting high contrast / high detail that stresses a codec.

Also having smooth and detailed areas in shadow in various other parts of the frame helps see how the codec stomps on the shadow areas that most codecs affect strongly. That also helps see how the rate control does.

Proves does rate control over the whole frame so a highly detailed part of a frame who the leave another part of the frame unnecessarily starved.

Presumably braw is based off the same DCT IP as BMDs prides implementation.

What might show off codec compression artefacts is usually high
noise/frequency content, i.e. grass, leaves, gravel, windy water,
moire-effect forcing "check patterns" or "pin stripe suit" silks.
Then of course green sceen or blue screen with fine contour
details like single hair, wavy curtains with embroidery, or fine
grass in front of it. Even a not to close close up to really gray
hair (should be available...) on a "hair thickness is not much
more than 1-3 photosites" is often good to reveal color
interpolation (demosaic) issues. Thats the stuff where we see it
in post. The finer the detail, the more likely its hard to
reproduce with compression. Each compression scheme tries to
reduce high frequency noise - thats where the details go...

I would go for some sort of fabric, where we hit the resolution
limit. But you still have to count in the effect of an OLPF.

It would be great to have the same scene with multiple settings
(from totally uncompressed DNGs - please verify that the files are
of constant size.. and they are not those JPEG DNG's which BM makes
with 1:3/1:4 lossy codec to the various flavors of BRAW). Ideal
setup would be to lock the camera and change settings remotely (if
that is possible)

But then a very subtle and slow movement might help to find
compression-breaking frames more easily.

What you have to count in, is the effect of "constant bitrate" vs
"constant quality" setting difference:
- on the constant quality, the scene contents does not matter, it
will break same way whether it is half fabric and half sky
- on a constant-bitrate setup, the fabric or other high-frequency
content shall cover the whole picture, otherwise the portions where
the "sky" is, will compress well and the saved bandwidth will be
used for the other half, so your results will be not worth anything
(unless the methodology includes the ratio of different scene
contents)

Now comes the tricky part. There might be a codec which is a
multi-pass one in order to get the best compression for the image
regions while achieving a constant bit-rate per each frame frame,
under i-frame setting. But for real-time capture applications, the
encoder makers implement it with some cheats - among which an
inter-frame dependency is the easiest one to avoid the need of
full-frame recalculation (costs power and needs more powerful
hardware).

So while you think that the codec is intra frame only, actually it
is not and there might be a delay to adapt the compression. If the
camera vendor refuses to tell how their implementation works, do not
assume it is separate for each frame.

Resume:

Constant quality = same quantizer = easy for hardware, but
bit-rate will vary a lot

Constant bit-rate:

- per frame = needs different quantizer per portion of frame
- in UHD BRAW there are 240 portions, in PR/PRR its even more
finer), hardest to achieve, no single-pass perfect method exists -
either you redo the whole frame, or cheat on the initial guess from
previous frame. To get it in perfection the camera has to be
"over-equipped" with the compression hardware, so that it can redo
all the frames several times.

- per group of frames = constant quantizer within a frame,
that is adapted over longer period to meet the target bit-rate
setting - that one will be definitely dependent on how rapidly the
scene changes (e.g. revealing a fine fabric will show up perfectly
sharp on 1st frame it appears, but its quality will degrade over
consecutive frames in order to meet the bit-rate constraints)

- (combination of above approaches)

PS: the same is true for e.g. AVC / HEVC - the codec specs
definitely offer amazing features you can use for quality, but when
you encode under real-time constraint (in camera), the quality is
far from what it actually could be. This is especially true for
codecs that are part of various SoC (system on chip) devices that
target primarily low power (phones, etc.) - the easiest cuts
employed are: limited motion vector search distance, the single size
of macro-block, single quantizer over whole frame, etc.

Thanks for doing this! If BRAW is indeed using DCT compression, try something that has 'broken' DCT compression in the past: Small face in the middle of a big white cyc. Given that it's compressing RAW, artifacts might of course show up in other places. I've also had major issues with film grain on DCT based compression of HDCAM and DVCAM, so high ISO with random noise might show things? Slow gradients are also an area where the shit hits the fan quickly. I've had some filters breaking DCT compression in the past, f.ex. Black Pro Mist used to 'break' DVCAM compression. That is probably too time consuming to test, though.-- Aasulv 'Wolf' Austad, FNFDP, Altadena, Californiahttp://wolfaustad.com

Verify Delete

Are you sure you wish to delete this message from the message archives of cml-raw-log-hdr@cml.news? This cannot be undone.

Report Message

Reason

Report to Moderators
I think this message isn't appropriate for our Group. The Group moderators are responsible for maintaining their community and can address these issues.
Report to CML Support
I think this violates the Terms of Service. This includes: harm to minors, violence or threats, harassment or privacy invasion, impersonation or misrepresentation, fraud or phishing.