How about extending CinemaDNG?

The place for questions about shooting with Blackmagic Cameras.
  • Author
  • Message
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

How about extending CinemaDNG?

PostSat Sep 22, 2018 8:08 pm

Okay so I think it's pretty safe to say that people will definitely be making use of Blackmagic RAW but it's clear that it's not a complete replacement to CDNG so why not extend what it can do?

Before hearing about Blackmagic RAW, one of my hopes was that a firmware update would add the ability to record in MXF-wrapped CinemaDNG and maybe the option of 5:1 compression. However, as programs like SlimRAW demonstrate, the format is also capable of being variable bit rate just like BRAW so why not add those options, too? The higher compression levels and VBR wouldn't even need an update to Resolve.
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostSat Sep 22, 2018 8:18 pm

Pointless- it's poor performance codec. Waste of time.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostSat Sep 22, 2018 8:23 pm

Andrew Kolakowski wrote:Pointless- it's poor performance codec. Waste of time.


It's not a waste of time at all. It really doesn't perform that poorly as I've been editing CDNG just fine for years. And even at 4:1, Cinema DNG has more detail than 3:1 or Q0 BRAW. Not to mention that by wrapping CDNG in MXF files, it would reduce file system storage and performance overhead to some degree and improve performance.

I would also suggest that they store directional gradient data along side each frame order to off-load a lot of the debayering into the camera and further improve performance on the NLE side but I'm pretty sure that's far outside of what CDNG would allow.
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 1:56 am

I have been contemplating why not use DNG at video speed on a phone but put frames into a virtual file space inside a single file per recording (Android file handeling doesn't seem the best. So this takes it away from the sluggish file system). Then you need post software that understands how to look for frames in the file, or use software to extract them. In file blocks you also would be able to introduce blocks in the chains, and skip to next block (defrag to compact), when you edit, or even insert). It might actually work a lot better on a phone like that.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 2:01 am

Actually, is it possible to group all frame files In a continuous space, grant access to all the frame files, make up a pointer links to the start storage block of each file frame and directly access it bypassing the file system on PC (a programming question)? This would make it very much like processing a single file codec in performance terms
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline
User avatar

Uli Plank

  • Posts: 21291
  • Joined: Fri Feb 08, 2013 2:48 am
  • Location: Germany and Indonesia

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 6:36 am

Even if technically possible the question remains, if anybody is really interested in doing that. How long has DNG been in the open format domain without anybody doing that? Now it seems, that even BM, who introduced the only compressed variants, is moving away from it.
Others may follow if BRAW catches on.
No, an iGPU is not enough, and you can't use HEVC 10 bit 4:2:2 in the free version.

Studio 18.6.5, MacOS 13.6.5
MacBook M1 Pro, 16 GPU cores, 32 GB RAM and iPhone 15 Pro
Speed Editor, UltraStudio Monitor 3G, iMac 2017, eGPU
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 10:37 am

You can take a horse to water ...And there seems to not be too few horses.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 11:45 am

It is a matter of the mechanics of programming. A lot of programming is bad in this respect, the design is bad. Look at the variance in processing speeds accross different applications for the same data, if they were all "great" they would almost be the same processing speeds accross packages. Look how long it took for packages to pick up GPU processing at all. There is a wide variance.

Now, a simple reason, if technical possible???, is it breaks the standard, but you can process such a file to extract the files to.the standard. When dealing with data to maximise performances this is the sort of thing you need to do to make things faster. Frankly, I wouldn't trust android to handle things. It would be very handy to record to single contiguous file under android.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 1:59 pm

Wayne Steven wrote:I have been contemplating why not use DNG at video speed on a phone but put frames into a virtual file space inside a single file per recording


I had actually thought of something like this but for Resolve and not Android. The idea would just be for Resolve to support image sequences that have been stored in a tarball file or uncompressed Zip file. Each sort of is it's own virtual file space so the OS treats it like accessing one file.

Uli Plank wrote:Even if technically possible the question remains, if anybody is really interested in doing that. How long has DNG been in the open format domain without anybody doing that? Now it seems, that even BM, who introduced the only compressed variants, is moving away from it.
Others may follow if BRAW catches on.


I mean the MXF thing is completely possible. CinemaDNG was made with the intention to be either stored in folder structures OR wrapped in MXF.
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 2:11 pm

Uli Plank wrote:Even if technically possible the question remains, if anybody is really interested in doing that. How long has DNG been in the open format domain without anybody doing that? Now it seems, that even BM, who introduced the only compressed variants, is moving away from it.
Others may follow if BRAW catches on.


No one is interested in DNG. It's outdated technology, used in video cameras basically just by BM. Adobe abandoned it long time ago. You can find their statement about it. No on is interested in writing good DNG decoder either. You can't polish a "xxxx".

You can wrap DNG into MXF- this is not sorting much at all, though.
Last edited by Andrew Kolakowski on Sun Sep 23, 2018 2:20 pm, edited 2 times in total.
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 2:17 pm

Mark Grgurev wrote:It's not a waste of time at all. It really doesn't perform that poorly as I've been editing CDNG just fine for years. And even at 4:1, Cinema DNG has more detail than 3:1 or Q0 BRAW. Not to mention that by wrapping CDNG in MXF files, it would reduce file system storage and performance overhead to some degree and improve performance.


Well- this just show how poor BM RAW is, not how great DNG :D
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 2:24 pm

Andrew Kolakowski wrote:
Uli Plank wrote:Even if technically possible the question remains, if anybody is really interested in doing that. How long has DNG been in the open format domain without anybody doing that? Now it seems, that even BM, who introduced the only compressed variants, is moving away from it.
Others may follow if BRAW catches on.


No one is interested in DNG. It's outdated technology, used in video cameras basically just by BM. Adobe. No on his interested in writing good DNG decoder either. You can't polish a "xxxx".

You can wrap DNG into MXF- this is not sorting much at all, though.


We know you like cineform..we hear the crickets, I do to, and see your posts out there (at least I hope I'm talking to the right guy). But life is life, I would like to do my own codec that dies lossless 10:1-100:1 on a denoused image, but I can't afford the patent costs to defend such a thing (costly court battles). But DNG is there, is open source, is practical, and apparently is much better than BRaw 3:1 at 4:1 as far as detail. The only real issue people go on about is processing speed, which we are talking about, but a .... Otherwise, where Andrew? Now, yes, I probably would like to license BRaw to put in a phone, but that may not happen for years, DNG is now, and I have been thinking of approaching DNG groups, and mobile chipset manufacturers to find the fastest DNG processing software and hardware for DNG on phones.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 2:32 pm

I don't think it's that difficult to write codec which is at DNG/BM Raw quality level without breaking patents. Those codes are very simple at the end.
If it would be that difficult then how ProRes, DNxHD, DNxHR, GV HQ/HQX, NewTek Speed HQ, were written?
I may be wrong though.
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 5:18 pm

Andrew Kolakowski wrote:I don't think it's that difficult to write codec which is at DNG/BM Raw quality level without breaking patents. Those codes are very simple at the end.
If it would be that difficult then how ProRes, DNxHD, DNxHR, GV HQ/HQX, NewTek Speed HQ, were written?
I may be wrong though.

Writing a codec is not hard, it is hard to write a codec that produces smaller files and decodes/debayers faster than existing solutions without sacrificing quality. It is similar to writing a pathtracer render engine, students do it for their semester work but writing something that is actually usable in production is very hard.

Do you happen to know what exactly is patented by RED for example, regarding redcode raw? Wavelet encoding wasn't exactly new at that time, neither was the idea of compressed raw.
I do stuff.
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostSun Sep 23, 2018 7:31 pm

No, it looks like they have patent for actual "encoding RAW in camera", which is very generic patent. Normally it's not easy to get one like this.

https://patents.google.com/patent/US8872933B2/en

RED suing Sony for RAW in camera encoding:

https://nofilmschool.com/2013/02/red-ce ... ompression
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostMon Sep 24, 2018 12:16 am

It's rather like patenting rubbing my head slightly offsetted left from centered compared to directly on top. It should have never been granted. I hadn't heard of that one. I heard they had at least attempted to patent using raw above FullHD or something. I feel granting patents on such things as disgraceful.

As far as I know, the revision of the codec uses cineform related technology.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostMon Sep 24, 2018 12:27 am

Andrew Kolakowski wrote:I don't think it's that difficult to write codec which is at DNG/BM Raw quality level without breaking patents. Those codes are very simple at the end.
If it would be that difficult then how ProRes, DNxHD, DNxHR, GV HQ/HQX, NewTek Speed HQ, were written?
I may be wrong though.


As Hendrik says. If you want to write a codec for better performance and smaller files it's harder. The tricks they have to stack on to consumer codecs to get smaller files is rather large.

If BRaw is a modern codec, I expect it to be more complex than DNG. But it is not even getting the detail performance of DNG. It can be said that noise removal causes this, but at 3:1 you would expect a more modern codec to be better than 4:1. I got an idea how to track movement in sensor or software to better do temporal noise removal in detail. Got another idea again.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostMon Sep 24, 2018 3:58 am

Andrew Kolakowski wrote:No one is interested in DNG. It's outdated technology, used in video cameras basically just by BM. Adobe abandoned it long time ago. You can find their statement about it. No on is interested in writing good DNG decoder either. You can't polish a "xxxx".


This is probably the worst place on the internet to make that claim. Every Blackmagic cinema camera has marketed being able to shoot RAW internally to CinemaDNG for 6 years. Nearly everybody on this forum has used CinemaDNG extensively and many never even had the discussion about replacing it with anything until ProRes RAW was announced...

Andrew Kolakowski wrote:You can wrap DNG into MXF- this is not sorting much at all, though.


… and one of the reasons that people were all over ProRes RAW before they even knew what it was capable of was because it was stored as a single file. So that alone was viewed as being a hugely positive feature to a lot of people. And like I had previously mentioned, storing it as one file removes some degree of file system overhead both in processing and storage. As a list of files, Windows, Mac OS, and Linux need to access each DNG in the folder individually which is more calls to the file systems driver and more short, potentially-fragmented reads from the hard drive. This alone could knock at least a few percent off CDNG's CPU usage.

There's also some smaller advantages. As an file sequence, CinemaDNG has to store things like file name, camera name, slate data, frame rate, timecode, compression type, bit-depth, resolution, mosaiced/3 sensor, black level, white level, and linearization tables to be stored per-frame. As a single clip, these can be stored once, or in the case of things like time-code, not at all. Sure this info might realistically only take up a couple hundred KBs for a 30 second clip and anything in the decoder that would account for all this info being different per-frame likely wasn't slowing down CDNG much to begin with but it's an example of how there's little things you can do improve CDNG's usability.

Btw, I do think it would be worth it for Blackmagic to add support for Resolve to treat tarballs or uncompressed Zips as folders if only just for the fact that this would help prevent fragmentation of any image sequence be it TIFF, DPX, JPEG, or EXR.
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostMon Sep 24, 2018 7:11 am

DNG allows MXF, wouldn't that archieve as much as Tar? As long as you can track the start block of each frame, you can directly send the dusk there without additional file system involvement.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostMon Sep 24, 2018 7:28 am

I think I have cracked what how BRaw is breaking up processing leading to the results you see on the samples.

You seperate out the luma and chroma from the Bayer pattern. This leaves the whole Bayer pattern as continuous Luma data to be compressed as waveform. Chroma tends to be area based which is easier to compress, so you compress the three colour channels seperately. The maximum discernable colour is yellow with something like 27 grades, so the chroma data can be low bit depth. Both should get more compressible, but maybe the sum of the two isn't as compressible. More aggressive compression to compensate will reduce the accuracy which might account for the less sharp detail we see. This is basically a form of Bayered 4:4:4 which might account fur the light fring around colour tiles people are seeing. It is displayable.

On the other end it basically uses this data to complete debayering to ahigh standard. But I think the compression process is more aggressive, you may loose quality compared to DNG. But in reality, you get speed at the sacrifice of file size and quality. If you were to match it a d DNG in quality would it be much faster, and would it be even larger? Let's just hope it is niose removal cauaing much of this, and that they can further further tune this. Pretty interesting way of doing it.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostMon Sep 24, 2018 12:18 pm

Wayne Steven wrote:I think I have cracked what how BRaw is breaking up processing leading to the results you see in the samples.

You seperate out the luma and chroma from the Bayer pattern. This leaves the whole Bayer pattern as continuous Luma data to be compressed as waveform. Chroma tends to be area based which is easier to compress, so you compress the three colour channels seperately. The maximum discernable colour is yellow with something like 27 grades, so the chroma data can be low bit depth. Both should get more compressible, but maybe the sum of the two isn't as small as DNG. More aggressive compression to compensate will reduce the accuracy which might account for the less sharp detail we see. This is basically a form of Bayered 4:4:4 which might account for the light fringe around colour tiles people are seeing. It is displayable.

On the other end, it basically uses this data to complete debayering to a high standard. But I think the compression process is more aggressive, you may loose quality compared to DNG. But in reality, you get speed at the sacrifice of file size and quality. If you were to match it and DNG in quality would it be much faster, and would it be even larger? Let's just hope it is niose removal causing much of this, and that they can further tune this. Pretty interesting way of doing it.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostMon Sep 24, 2018 8:43 pm

Wayne Steven wrote:DNG allows MXF, wouldn't that archieve as much as Tar? As long as you can track the start block of each frame, you can directly send the dusk there without additional file system involvement.


It would achieve more actually because Resolve could assume more about the MXF then it could with a generic folder structure. I simply mentioned Tar as a quicker and dirtier option to group image sequences not for Resolve's sake but for the sake of the user who wants to make sure that an image sequence stays sequential on the drive.
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 1:59 am

Thanks Mark.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 2:08 am

Still, couldn't much of what has been achieved in BRaw be done in CDNG inside the MXF wrapper? Anybody out there could do it, and put a low hanging fruit image restoration temporal noise removal feature in (where, when it can safely do so, replaces noise with an estimated real value). This would increase the accuracy of CDNG images and maybe solve a few issues, and make it more compressible. Any noise not safe to replace goes into a higher noise removal setting, if at all.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 5:26 am

Removing noise won't make the image more accurate because you can't really know if values you produce from noise reduction were really there. It is just a guesswork that has to constrain itself to some kind of temporal and spatial coherence.

A few ideas, just to roll the ball on future mega-advanced codec front :D
- I'd envision a codec that does a pretty heavy-handed noise reduction but hides the fact in restored noise generated in decoder based on original noise profile. Voila, magically small files with super-detail. Just don't reveal any details about regenerating noise 8-)
- Downscaled raw. In Reduser forum some people discussed the technical possibility of downscaled (not windowed) raw and most of them stated it is not possible. Have a bit more imagination! Nothing prevents from skipping every other RGGB photosite quadruple to instantly get 2x downscaling. Or one could average photosite data, it is technically practically the same as having a photosite with larger dimensions, plus it reduces noise. The upside of downscaled vs windowed is not changing the field of view.
- Allow a pure raw mode in decoder (not sure any of current codecs have this, maybe cineform has, don't remember) where decoder outputs Bayer data directly for user to poke around and build their own debayer or whatnot.
I do stuff.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 7:12 am

Wayne Steven wrote:Still, couldn't much of what has been achieved in BRaw be done in CDNG inside the MXF wrapper?


Well it's really just a container so to a large degree it just kind of stores what you tell it to so yes I guess it could. As for the kind of CDNG compression currently used, it can and has been used with variable compression ratios and with ratios that Blackmagic's cameras don't shoot in but they're all a limitation of the camera and can be used in anything that supports those format. However, I have done much to test 5:1 and 7:1 CDNG compression scheme yet so I don't know what kind of quality they would have.

Hendrik Proosa wrote:A few ideas, just to roll the ball on future mega-advanced codec front :D


I'm the type that thinks about stuff like that too even though I know I'm unlikely to come up with something superior to what Blackmagic or somebody else could come up. In my case I focus on ideas for lossless compression since it's easier for me to wrap my head around lol

I was thinking about something today that would take into account the bayer pattern and spatial and color difference between red, green, and blue photosites within a pixel group. The idea would be to look at the image in 5x5 pixel groups and instead of saving whole values for every pixel, it would save a different amount of "key" pixels and the rest as the differences from those key pixels. The idea is that, within such a small group, values usually won't vary dramatically. Within the green channel, the value of one pixel may only differ from the 4 or even 12 surrounding green pixels by plus or minus 256. In this case you can store the center green pixel as it's actual 12-bit value and the surrounding green pixels as 9-bit values and a decoder would be able to get back it's original values with simple addition.

Of course, if there's particularly little contrast in that area, you might be able to get away with 7-bit or 6-bit offsets instead and save more space and different modes can store values differently depending on the groups needs. If the area is nearly grey scale then you might be able to store just one key pixel and all other pixels as low precision (7? 6? 5 bit?) offsets of that since there would be very little contrast between color channels. Another example would be if the area has a lot of green or magenta. Green and magenta are opposites so the abundance of one means the absence of the other so you can have the green represented as one green key and the rest as offsets while magenta can be represented as one red key with all the other reds and blues as low-precision offsets of that.

I had previously thought that Blackmagic RAW was doing the gradient directional analysis and saving it as gradient direction map in the file so that the decoder could use it to do the final interpolation so I would try implementing that, too, for performance reasons. I know at least one debayering algorithm that looks at whether or not neighboring pixels have values greater than or less than a certain pixel in order to determine whether or not there is a slope, ridge, or valley. I think saving things as offsets could potentially speed up that process since it would only have to check the first bit of most neighboring pixels to determine whether their values are greater or lesser.

I don't have any idea how much that can be pushed or how efficient that would be compared to current lossless CDNG compression but I can imagine myself attempting it in the future using data from an uncompressed DNG just for kicks.

If I wind up trying it, I'd likely run some analysis code to determine how frequently each group mode is used and whether or not new group modes with lesser-precision offsets can be used. I'd also be curious to see how strong of a correlation there is between the offsets and the gradient map.
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 9:32 am

Hendrik Proosa wrote:Removing noise won't make the image more accurate because you can't really know if values you produce from noise reduction were really there. It is just a guesswork that has to constrain itself to some kind of temporal and spatial coherence.

A few ideas, just to roll the ball on future mega-advanced codec front :D
- I'd envision a codec that does a pretty heavy-handed noise reduction but hides the fact in restored noise generated in decoder based on original noise profile. Voila, magically small files with super-detail. Just don't reveal any details about regenerating noise 8-)


It has been done, it's part of h264 spec. Quite complex process and basically never used.

Hendrik Proosa wrote: - Downscaled raw. In Reduser forum some people discussed the technical possibility of downscaled (not windowed) raw and most of them stated it is not possible. Have a bit more imagination! Nothing prevents from skipping every other RGGB photosite quadruple to instantly get 2x downscaling. Or one could average photosite data, it is technically practically the same as having a photosite with larger dimensions, plus it reduces noise. The upside of downscaled vs windowed is not changing the field of view.


This is probably possible.

Hendrik Proosa wrote:- Allow a pure raw mode in decoder (not sure any of current codecs have this, maybe cineform has, don't remember) where decoder outputs Bayer data directly for user to poke around and build their own debayer or whatnot.


Yes, any "open" RAW codec should allow to access RAW data and Cineform does it. VirtualDub2 allows for exporting RAW Bayer data out of Cineform RAW files or encoding to Cineform RAW out of RAW Bayer data.
RED SDK doesn't allow for it as they use encryption to try hide fact that RED coded is jpeg2000 and want to have full control over format.
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 9:40 am

Mark Grgurev wrote:
Andrew Kolakowski wrote:No one is interested in DNG. It's outdated technology, used in video cameras basically just by BM. Adobe abandoned it long time ago. You can find their statement about it. No on is interested in writing good DNG decoder either. You can't polish a "xxxx".


This is probably the worst place on the internet to make that claim. Every Blackmagic cinema camera has marketed being able to shoot RAW internally to CinemaDNG for 6 years. Nearly everybody on this forum has used CinemaDNG extensively and many never even had the discussion about replacing it with anything until ProRes RAW was announced...



Because there was nothing else. People take DNG as part of "cheap BM camera" system. In the same time they pay for 2x more powerful machines just to be ale to decode it. It taxes CPU badly for not much of a reason as it's simple codec. It was easy for BM to adopt it, but they should never done it. There is a reason why there is now BM RAW and it's not because DNG is a "great" format for sure.
Offline
User avatar

Rakesh Malik

  • Posts: 3236
  • Joined: Fri Dec 07, 2012 1:01 am
  • Location: Vancouver, BC

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 3:14 pm

Andrew Kolakowski wrote: It was easy for BM to adopt it, but they should never done it. There is a reason why there is now BM RAW and it's not because DNG is a "great" format for sure.


BMD didn't choose cDNG only because it was easy. What other options were available at the time?

Cineform is a great codec, but when BMD started using cDNG, it wasn't open or free, which is why hardly anyone else used it, either.
Rakesh Malik
Cinematographer, photographer, adventurer, martial artist
http://WinterLight.studio
System:
Asus Flow X13, Octacore Zen3/32GB + XG Mobile nVidia RTX 3080/16GB
Apple M1 Mini/16GB
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 4:31 pm

They did- it was an "easy" option, but not very good one (nothing else free was there- this is exactly why they chosen it). They could make own format like they did now.
Offline
User avatar

Rakesh Malik

  • Posts: 3236
  • Joined: Fri Dec 07, 2012 1:01 am
  • Location: Vancouver, BC

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 5:11 pm

Andrew Kolakowski wrote:They did- it was an "easy" option, but not very good one (nothing else free was there- this is exactly why they chosen it). They could make own format like they did now.


BMD didn't make braw just now. It's been in development for years.

That USING it is as simple as selecting a box on the UI and integrating an SDK with a fairly straightforward API doesn't imply that developing it was easy.
Rakesh Malik
Cinematographer, photographer, adventurer, martial artist
http://WinterLight.studio
System:
Asus Flow X13, Octacore Zen3/32GB + XG Mobile nVidia RTX 3080/16GB
Apple M1 Mini/16GB
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 5:22 pm

Andrew Kolakowski wrote:They did- it was an "easy" option, but not very good one (nothing else free was there- this is exactly why they chosen it). They could make own format like they did now.


In general, there weren't very many codecs that supported lossless RAW Bayer data at the time and that's still the case now. Sure they could have made their own but that probably would have been similar to Blackmagic RAW which you also don't like. Plus this might seem daft but it isn't altogether a bad thing to use a "dumb" codec especially when it's reliable and high quality. With CinemaDNG, BMD was able to offer something that nobody could argue wasn't RAW. It also seemed like widespread adoption was inevitable since DNG was already widely used.

As for performance, I actually never really knew CDNG was taxing on anything other than a hard drives until I tried editing it on my brother's Surface Pro 2. My desktop was never exactly bleeding edge either.
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 6:00 pm

Rakesh Malik wrote:
Andrew Kolakowski wrote:They did- it was an "easy" option, but not very good one (nothing else free was there- this is exactly why they chosen it). They could make own format like they did now.


BMD didn't make braw just now. It's been in development for years.

That USING it is as simple as selecting a box on the UI and integrating an SDK with a fairly straightforward API doesn't imply that developing it was easy.


Yep, since they realised DNG wasn't very very good choice. Developing such a SDK (if you have many programmers in-house) can be done fairly quickly. It all depends how much of their time you can shift or this task. You to much believe in pr talks :)
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 7:37 pm

Andrew Kolakowski wrote:Yep, since they realised DNG wasn't very very good choice. Developing such a SDK (if you have many programmers in-house) can be done fairly quickly. It all depends how much of their time you can shift or this task. You to much believe in pr talks :)


What about CinemaDNG makes it a bad choice? Yes, files are big but that doesn't make it inherently a bad choice.
Offline

Justin Jackson

  • Posts: 670
  • Joined: Thu Apr 28, 2016 3:50 am

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 10:44 pm

I am a little blown away by the concept that BRAW isnt so good after all. I am looking at the video test of 12:1 (which is using a beta version.. thus could change for the better) and it looks outstanding.

I see from a few threads regarding 400:1 zoom and macroblocks, etc.. but I am a little lost why this is enough that some people (Andrew in particular) are saying BRAW is not good at all now? Is this purely a color grading thing that is stirring the pot?

To me.. I have been stuck in h.264 land. Being able to record 12-bit 444 RAW in a somewhat lossy format that blows away h.264 and h.265, with full on post production meta info/tweaking capabilities, is a dream come true. Especially if I can fit more than 15 minutes of 4K 60 on a 500GB SSD. I was hoping to be able to record a good hour or so.. though not sure now if Q0 or what not would fit that much in a 500GB SSD or not.

Still.. color me.. "wow". Like.. this seems like such a huge advancement in terms of being able to store a lot more 12-bit video in what CDNG barely fits in.

What am I missing?
Custom DIY AMD1950x 16-core/32-thread, liquid cooled, 64GB 3600Mhz RAM, 950Pro-512GB NVMe os/apps, 2x500GB 850 Evo RAID 0 SATA3, Zotac 1070 8GB video, USB 3.1Gen2 RAID0 2x4TB, 2x2TB Crucial MX500 SSD SATA3.
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 11:01 pm

Justin Jackson wrote:What am I missing?


You're not really missing much. BRAW is excellent and I'll definitely be using it extensively. It's just that when you juxtapose footage in CDNG and BRAW, the CDNG retains more detail. So depending on the scenario, I'll probably opt to still use CDNG on occasion so I figured why not still extend the CDNG recording options? After all, some of the stuff that BRAW can do can also be done with CDNG and I don't think that any artificial differences should exist between the two when that doesn't have to be the case.

I don't get Andrew's take on all this. He seems to think both and CDNG and BRAW are terrible when both are excellent and have their own strengths and weaknesses.
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostTue Sep 25, 2018 11:05 pm

Some things are good some not or not so obvious.
I'm sure people will be happy with it (more than with DNG).
When I look at BM RAW from codec/technical point (after 15 years looking at different ones), I'm not crazy impressed. If I look from user point (moving from DNG) then it's way more 'impressive'.
Offline

Justin Jackson

  • Posts: 670
  • Joined: Thu Apr 28, 2016 3:50 am

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 2:38 am

Andrew.. what about it is not so impressive? I mean.. unless I mis-read the file sizes, it appears that you can get better detail than ProRes HQ in a much smaller file size, with 12-bit video instead of 10, and additional meta info about the camera (e.g. lens, settings, etc?).

Is it that you feel when you zoom in to 400x it has too many issues compared to DNxHR/ProRes and thus feel it isnt any better?

So I am guessing that if I were to do green screen, I would want to shoot CinemaDNG with no compression, and for anything else BRAW (once it is available)?

Will BRAW capture the full dynamic range of the camera, or will that still need CDNG?
Custom DIY AMD1950x 16-core/32-thread, liquid cooled, 64GB 3600Mhz RAM, 950Pro-512GB NVMe os/apps, 2x500GB 850 Evo RAID 0 SATA3, Zotac 1070 8GB video, USB 3.1Gen2 RAID0 2x4TB, 2x2TB Crucial MX500 SSD SATA3.
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 6:36 am

From the current tests, I think BRaw is complementary to CDNG and maybe ProRes (if you can't just use it instead on handoffs). BRaw does not look superior. It has advantages that dissapear with a decent system with new"est" descent NVIDIA GPU and if you just did the same thing to CDNG, and disadvantages to current CDNG. It's a codec who's time was years ago, when systems really struggled to process footage. But frankly, more detail, more exactness with CDNG, which BRaw should match. So, BRaw is something you use instead of CDNG when those things don't matter and you want something better than ProRes. I'm pretty incredulous at ProRes too, that BRaw can beat it on detail. At it's highest settings, they all should have pretty much the same amount of detail at the same ratios.

Who's thinking that BRaw might become as detailed as CDNG by April? It could be just some bug, we don't know yet. I mean they should have BRaw Hard, Medium and soft settings, as fast as detail goes. With hard like DNG and soft like we see now. Frankly, if you are going to direct to broadcast TV, streaming, or Bluray, you probably don't need anything else but soft, those codecs are going smooth things anyway. But if you are going to reframe etc, then hard is better.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 6:58 am

Mark Grgurev wrote:
Wayne Steven wrote:Still, couldn't much of what has been achieved in BRaw be done in CDNG inside the MXF wrapper?


Well it's really just a container so to a large degree it just kind of stores what you tell it to so yes I guess it could. As for the kind of CDNG compression currently used, it can and has been used with variable compression ratios and with ratios that Blackmagic's cameras don't shoot in but they're all a limitation of the camera and can be used in anything that supports those format. However, I have done much to test 5:1 and 7:1 CDNG compression scheme yet so I don't know what kind of quality they would have.


For me this is very interesting for phone use, as it means maybe a big performance leap in encoding. Theoretically, I have come up with another way to speed up encoding on the phone now aswell. I probably shouldn't just tell the world how they can do things better as somebody might just patent it and I won't be able to use it. But in my head, a while back, I had the thought of how to use cineform to compress mosaics without using the Raw version. That would be better, and instant third party support.

Hendrik Proosa wrote:A few ideas, just to roll the ball on future mega-advanced codec front :D


I'm the type that thinks about stuff like that too even though I know I'm unlikely to come up with something superior to what Blackmagic or somebody else could come up.
Lol
In my case I focus on ideas for lossless compression since it's easier for me to wrap my head around lol

I was thinking about something today that would take into account the bayer pattern and spatial and color difference between red, green, and blue photosites within a pixel group. The idea would be to look at the image in 5x5 pixel groups and instead of saving whole values for every pixel, it would save a different amount of "key" pixels and the rest as the differences from those key pixels. The idea is that, within such a small group, values usually won't vary dramatically.
. I came up with a similar ideas for the Elphel camera 12 years ago maybe, turns out the original lossless version of jpeg used an average echeeme thing too). The one you should look at, which I write up a number of ideas on, is how gpu's were compressing texture patterns. Designed for high speed on hardware and using reference values to average local values down in value. Had some interesting ideas into how much you could do with this.

Within the green channel, the value of one pixel may only differ from the 4 or even 12 surrounding green pixels by plus or minus 256. In this case you can store the center green pixel as it's actual 12-bit value and the surrounding green pixels as 9-bit values and a decoder would be able to get back it's original values with simple addition.

Of course, if there's particularly little contrast in that area, you might be able to get away with 7-bit or 6-bit offsets instead and save more space and different modes can store values differently depending on the groups needs. If the area is nearly grey scale then you might be able to store just one key pixel and all other pixels as low precision (7? 6? 5 bit?) offsets of that since there would be very little contrast between color channels. Another example would be if the area has a lot of green or magenta. Green and magenta are opposites so the abundance of one means the absence of the other so you can have the green represented as one green key and the rest as offsets while magenta can be represented as one red key with all the other reds and blues as low-precision offsets of that.

I had previously thought that Blackmagic RAW was doing the gradient directional analysis and saving it as gradient direction map in the file so that the decoder could use it to do the final interpolation so I would try implementing that, too, for performance reasons. I know at least one debayering algorithm that looks at whether or not neighboring pixels have values greater than or less than a certain pixel in order to determine whether or not there is a slope, ridge, or valley. I think saving things as offsets could potentially speed up that process since it would only have to check the first bit of most neighboring pixels to determine whether their values are greater or lesser.


Yes, very much my proposal. But a waveform is a directional map, simple over and done with, except what we are describing might get five with simpler hardware etc, but now we have better hardware.

I don't have any idea how much that can be pushed or how efficient that would be compared to current lossless CDNG compression but I can imagine myself attempting it in the future using data from an uncompressed DNG just for kicks.

If I wind up trying it, I'd likely run some analysis code to determine how frequently each group mode is used and whether or not new group modes with lesser-precision offsets can be used. I'd also be curious to see how strong of a correlation there is between the offsets and the gradient map.



So, what have you done? I need a programmer, and you and Hendrik are about the only ones talking the real sense.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Hendrik Proosa

  • Posts: 3015
  • Joined: Wed Aug 22, 2012 6:53 am
  • Location: Estonia

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 7:43 am

Isn't gradient analysis what DCT and wavelet encoding are basically doing? They calculate coefficients for horizontal and vertical direction only ofcourse, but it is based on gradients/waves and frequencies with small contributions are discarded and remaining coefficients are compressed using rle or huffman encoding or something like that...

Storing stuff with different variable bit lengths is interesting, but in this case you need a way to signal how long certain element is, this "tail" might practically eliminate your gains. Plus you must still accommodate values that have potentially maximum possible difference, so can't just truncate differences to some set bit length either.

I just had a simple thought about why braw possibly is like it is. Processing raw data in camera in a way that allows a very simple debayer method is one of the keys to speed. CDNG is slow not because it has big files (just use faster disks), it is slow because debayering is very compute-intensive. But if debayer were as simple as lerp from adjascent elements, it will become a non-issue. But this needs some processing to produce such values that give reasonable image when debayered. And to get this, there still might be the shady thing going on where image is debayered in camera and then "rebayered". I started looking into that cuda kernel code that was so nicely catered in those dll-s, will see how debayering is actually done (it should be part of gpu path). Some food for thought anyway...
I do stuff.
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 8:08 am

Hendrik Proosa wrote:Removing noise won't make the image more accurate because you can't really know if values you produce from noise reduction were really there. It is just a guesswork that has to constrain itself to some kind of temporal and spatial coherence.


No. So if you track all points, or if the scene is static, or for static parts of the scene, the points in the frame contain the same value over frames until they change. So, on average, you have a much better idea of what the true value of these points are. But if you track the true value you can track and figure out true changes as well. Say if an event, a beam of light on an object
flutters from leaves blow in the wind, you not only can figure out the colour of the point, but also accommodate for lighting changes. I'll stop there, because I've got ideas on this stuff I came up with long ago. Anything that is not the original, and not a change, is likely some event or noise. Now profiling noise and the events you can be aware of, you can greatly increase accuracy of of the denoised pixel. I think I came up with an idea of noise profiles with the last 14 years. Notice I never say spatial noise removal, became see that's a trick, which may help a little. There is further spatial analysis I've come up with which may help more, but combining it with a noise profile helps. The vertical noise profile image sensor another thing I identified where you may restore info, as if the point value isn't completely overwhelmed, there maybe a ghost value left there worth restoring, and in using averaging on. The average between the adjoining pixels is maybe more correct, and the ghost value can help. But simply averaging a downscale out (shoot 4.6k render FullHD) will likely still result in noise but at a lower magnitude, as you guys will know. Been thinking of these things for 20 years.

Notice I said accuracy rather than accurate. While it might be likely to get a high degree of accuracy, it is likely to be inaccuracies, but it's better than what we started with.

I'm starting to remember things I wrote a long time back. Thanks.

A few ideas, just to roll the ball on future mega-advanced codec front :D
- I'd envision a codec that does a pretty heavy-handed noise reduction but hides the fact in restored noise generated in decoder based on original noise profile. Voila, magically small files with super-detail. Just don't reveal any details about regenerating noise 8-)
- Downscaled raw. In Reduser forum some people discussed the technical possibility of downscaled (not windowed) raw and most of them stated it is not possible. Have a bit more imagination! Nothing prevents from skipping every other RGGB photosite quadruple to instantly get 2x downscaling. Or one could average photosite data, it is technically practically the same as having a photosite with larger dimensions, plus it reduces noise. The upside of downscaled vs windowed is not changing the field of view.
- Allow a pure raw mode in decoder (not sure any of current codecs have this, maybe cineform has, don't remember) where decoder outputs Bayer data directly for user to poke around and build their own debayer or whatnot.


The Bayer pattern group skipping, will give you alaising issues. You van debayer the local group used, but then you have to do a process to try to guess the missing groups around it, and good debayers are known to use neighbouring groups to debayer the central group. In Bayer, it is very bad, and olpf can spread light far and wide trying to eliminate Bayer pattern deficiencies and pixel pad fill factor issues. On another site, I have posted about doing a bayer version of a down scaled image, and debayering that to restore the diwnscaked image. So, you go from 4k to 2k etc, resulting in 4:4:4 2k etc, chuck away primaries to get a Bayer of the downscaled image, compress that, then debayer that to produce a 4:4:4 of the downscale. Of course, it's not likely to be as good as the original downscale, but there is one step I am leaving out which can make it better. Now, you might be tempted to just pick the red green and blues out of neighbouring groups, as the value of a downscaled Bayer pattern, but a good debayer works out the proportion of a primary colour in pixels of other primary colour (like Arrii does) resulting in better calculation of the average of each primary in the group which you can use for a downsampled Bayer pattern. The using a primary from each 4k pixel instead, gives you samples at shifted positions within the downsampled 2k pixels, likely giving weird strobing anti-alaising etfects. But, when putting all factors into the equation, you could produce a pretty nifty way of doing it.

I don't know why people haven't just looked at data in BRaw files to determine what was going on, it wasn't encrypted.

Who ever said that Red was Jpeg2k, from discussions I have had, it used to be. From discussions I have had, they got a cineform technology license, and that's when it greatly improved. I was once offered a cineform licensed myself, at great terms, but notice that since Red upgraded it's codec, GoPro (owns cineform) didn't do a pro camera, and no other camera company has gotten a license as far as I know of.

However, cineform has gone free, except the Bayer version, as they have a newer standardised codec, which BM could have licensed cheaply. But still, you could record Bayer in Cineform as I've described BRaw as doing it elsewhere. Think about it. However, I'd rather not use Bayer in a phone, and use cineform to compress 4:4:4, or a Linux 4:4:4 ProRes alternative. If only I could get hold of those foveon based mobile chips.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Wayne Steven

  • Posts: 3362
  • Joined: Thu Aug 01, 2013 3:58 am
  • Location: Earth

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 8:19 am

That's my point Hendrik. While the gradient thing was a brilliant idea which could use resources better, now you have heaps of resources and DCT specific hardware to do model gradients, it's not really needed. So, I dont give it much easier thought. Even if I got a very small/cheap FPGA which could use it instead of dct/wavelet, we are still talking here about say 2:1+ compression (I think the guy that tried my idea got less than that, but it was hard to find out if he did it correctly or not), but when you apply it with simple inter frame comparison difference (on data), you might get something lossless worth doing.

Ok, I'm re-editing this. First there is no tail if you are heading from one know reference value to another, just differences. If the difference is outside the range, you have an exception and a way to register the exception. In real life, this is not such a good model, but over short distances it maybe better. This is because the rise and fall of lighting on an scene may be overwhelmingly often non linear. But on shorter distances it looks more linear. But, the established codecs use technogies more complex which maps much better to non linear (or am I wrong). So, if you wanted to use this as described for 10:1 low quality compression you would be wishful, but the normal codecs can easily do that. It's something that has obscure use in its day, in that form. As I said, it turned out Jpeg had a codec a little like that.

About simple debayer. Bayer is very deficient, that's why quality Bayer takes time to get better results.
Last edited by Wayne Steven on Thu Sep 27, 2018 5:39 am, edited 2 times in total.
aIf you are not truthfully progressive, maybe you shouldn't say anything
bTruthful side topics in-line with or related to, the discussion accepted
cOften people deceive themselves so much they do not understand, even when the truth is explained to them
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 9:57 am

Justin Jackson wrote:Andrew.. what about it is not so impressive? I mean.. unless I mis-read the file sizes, it appears that you can get better detail than ProRes HQ in a much smaller file size, with 12-bit video instead of 10, and additional meta info about the camera (e.g. lens, settings, etc?).

Is it that you feel when you zoom in to 400x it has too many issues compared to DNxHR/ProRes and thus feel it isnt any better?

So I am guessing that if I were to do green screen, I would want to shoot CinemaDNG with no compression, and for anything else BRAW (once it is available)?

Will BRAW capture the full dynamic range of the camera, or will that still need CDNG?


You can't compare debayered ProRes data rates to BM RAW- this is not fair as 1 has way more data than other. Compare it to ProRes RAW, Cineform RAW etc. Real test it recording uncompressed RAW, BM RAW, ProRes RAW and then comparing RAW data of each codec to uncompressed DNG RAW. You can also compare debayered one, but in all cases debayering has to be the same, so you can see how every compression "translates" to final image. This is test from technical point of view. From user point you can compare each final debayered data buy eye, how big, fast it's, etc.
If 2 codecs look about the same at same ratio then they have about the same efficiency. If BM RAW does show some macroblocking at 3:1 then this is not very good as at this level it should not bee there. Does DNG at 3:1 show macroblocking? If not then from technical point it's hard to call BM RAW impressive as it can't match DNG.
Metadata is easy part- BM can add it to any recording (again- should bee there from day 1), so this is not impressive either. 12bit is not impressive either as other codes also do it if needed.
90% people on the forum look at BM RAW from user point- how much they can record, how well it decodes etc. They also have nothing "good" to compare it against (they use DNG s reference), so their conclusion is that BM RAW is amazing. Well- in this case it's. Now if we had ProRes RAW or Cineform RAW recording in BM camera (+ proper support in Resolve) and you started comparing BM RAW against them suddenly it would not be that amazing (I "know it" based on my knowledge/experience) - this is the "technical" point.
We are at beta stage, so I hope BM will sort heavy/non-controlable de-noising and other bits.
Offline
User avatar

Frank Glencairn

  • Posts: 1801
  • Joined: Wed Aug 22, 2012 7:07 am
  • Location: Germany

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 10:33 am

Andrew Kolakowski wrote:People take DNG as part of "cheap BM camera" system. In the same time they pay for 2x more powerful machines just to be ale to decode it. It taxes CPU badly for not much of a reason as it's simple codec.


Not sure what sort of CPU you are running, but on all of my workstations here, the CPU is bored to death, while running CDNGs. The CPU is so bored, that it starts playing cards with the RAM, or watches p-o-r-n in the background.

DNG is way more easy on the CPU, than any other codec.

Andrew Kolakowski wrote:
Real test it recording uncompressed RAW, BM RAW, ProRes RAW and then comparing RAW data of each codec to uncompressed DNG RAW.


And than encode it into your delivery codec and check again, how much of a difference is actually left ;)
http://frankglencairn.wordpress.com/

I told you so :-)
Offline

Asit Jain

  • Posts: 27
  • Joined: Sat Dec 23, 2017 6:47 am
  • Location: Bhopal, India

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 10:55 am

Mark Grgurev wrote:Okay so I think it's pretty safe to say that people will definitely be making use of Blackmagic RAW but it's clear that it's not a complete replacement to CDNG so why not extend what it can do?

Before hearing about Blackmagic RAW, one of my hopes was that a firmware update would add the ability to record in MXF-wrapped CinemaDNG and maybe the option of 5:1 compression. However, as programs like SlimRAW demonstrate, the format is also capable of being variable bit rate just like BRAW so why not add those options, too? The higher compression levels and VBR wouldn't even need an update to Resolve.


I was also hoping for a MXF Wrapped CDNG for my UM4.6k, which will make file management a lot easier and copying faster.
- Asit
__________________________
Dell Precision 3640, Core i9-10900k
32GB RAM, RTX 3070FE
Window 10
Offline

Andrew Kolakowski

  • Posts: 9209
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 11:21 am

Frank Glencairn wrote:
Andrew Kolakowski wrote:People take DNG as part of "cheap BM camera" system. In the same time they pay for 2x more powerful machines just to be ale to decode it. It taxes CPU badly for not much of a reason as it's simple codec.


Not sure what sort of CPU you are running, but on all of my workstations here, the CPU is bored to death, while running CDNGs. The CPU is so bored, that it starts playing cards with the RAM, or watches p-o-r-n in the background.

DNG is way more easy on the CPU, than any other codec.

Andrew Kolakowski wrote:
Real test it recording uncompressed RAW, BM RAW, ProRes RAW and then comparing RAW data of each codec to uncompressed DNG RAW.


And than encode it into your delivery codec and check again, how much of a difference is actually left ;)


It's 2-3x more CPU demanding than Cineform RAW (and probably compared to ProRes RAW). Look at BM RAW- DNG RAW should be about the same, but it's way more CPU demanding.

End delivery is another story. You may as well shot on iPhone :)
Offline
User avatar

Rakesh Malik

  • Posts: 3236
  • Joined: Fri Dec 07, 2012 1:01 am
  • Location: Vancouver, BC

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 3:58 pm

Justin Jackson wrote:I am a little blown away by the concept that BRAW isnt so good after all. I am looking at the video test of 12:1 (which is using a beta version.. thus could change for the better) and it looks outstanding.

...

What am I missing?


Some people are resistant to change. That's what you're missing: their resistance.

Don't worry about it, just enjoy braw.
Rakesh Malik
Cinematographer, photographer, adventurer, martial artist
http://WinterLight.studio
System:
Asus Flow X13, Octacore Zen3/32GB + XG Mobile nVidia RTX 3080/16GB
Apple M1 Mini/16GB
Offline
User avatar

Rakesh Malik

  • Posts: 3236
  • Joined: Fri Dec 07, 2012 1:01 am
  • Location: Vancouver, BC

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 4:06 pm

Andrew Kolakowski wrote:Yep, since they realised DNG wasn't very very good choice. Developing such a SDK (if you have many programmers in-house) can be done fairly quickly. It all depends how much of their time you can shift or this task. You to much believe in pr talks :)


No... I understand software development and R&D based on prior experience.
Rakesh Malik
Cinematographer, photographer, adventurer, martial artist
http://WinterLight.studio
System:
Asus Flow X13, Octacore Zen3/32GB + XG Mobile nVidia RTX 3080/16GB
Apple M1 Mini/16GB
Offline

Mark Grgurev

  • Posts: 802
  • Joined: Fri Nov 03, 2017 7:22 am

Re: How about extending CinemaDNG?

PostWed Sep 26, 2018 5:43 pm

Andrew Kolakowski wrote:It's 2-3x more CPU demanding than Cineform RAW (and probably compared to ProRes RAW). Look at BM RAW- DNG RAW should be about the same, but it's way more CPU demanding.


I can't say I can judge Cineform RAW as I've never seen comparison between it, CDNG, PRR, or BRAW. In fact I've rarely seen a worthwhile, pixel peeping comparison of PRR and CDNG at all. Also we have no idea how much of CDNG's additional CPU usage is the result of file system having to access a bunch of small files instead of just one and the NLE having to read separate file headers for each one to ensure that it's interpreting it correctly. If we had an MXF-wrapped CDNG option then we could judge that better.

Andrew Kolakowski wrote:End delivery is another story. You may as well shot on iPhone :)


This is exactly why intelligent conversations about these things so rarely happen.
Next

Return to Cinematography

Who is online

Users browsing this forum: Akantha and 88 guests