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

New Compression Ratios?

Christoffer Glans said:
But the numbers don't make sense between DSMC2 and Komodo. If HQ 6K gives you 30 minutes, while Dragon 6K at 4:1 gives you 48 minutes, that would mean the HQ option on Komodo is way less compressed than any other Red at 6K?
That would mean that for anyone who shot 6:1 on Dragon 6K even MQ is higher quality?
Click to expand...

I think Komodo is DCT based and Red DSMC2 is Wavelet based .... apple and oranges... both fruit but different
 
Is there any updates on if they are going to change the compression options at all?
 
Michael Lindsay said:
I think Komodo is DCT based and Red DSMC2 is Wavelet based .... apple and oranges... both fruit but different
Click to expand...

I would like to know more on this! I thought Red's whole thing was the wavelet compression scheme? And while we are discussing compression, I have recently found that 8k can be nicely compressed 16:1 with good lighting for a 4k delivery. It is really the same or better than shooting 4k at 4:! or 6k at 8:1. Much easier files to handle. That is the magic of higher k values and wavelet compression, you can compress it more, at least that is my understanding. At the end of the day it seems silly to do very low compression if the end product is an even more compressed format.
 
I like the old / current compression ratio naming convention better. compressed file size vs uncompressed file. As its more easy to calculate with. This small, medium, large feels way less professonal.

Sure there is different compression codecs in use. So the effect of heavy komodo compression will be different from heavy monstro compression etc. But the difference between cameras is something that we had all the time. 10:1 on monstro looks very different from 10:1 on epic.
 
Michael Lindsay said:
I think Komodo is DCT based and Red DSMC2 is Wavelet based .... apple and oranges... both fruit but different
Click to expand...

But nobody knows why they had to switch? Which one is better? Which one is less efficient? Is it related to the limited processing power of Komodo? Or on the contrary, is the lower price of CFast media the reason why they where able to use less compressed technology? Is it related to apple and oranges? Is DSMC3 gonna be DCT based too?
 
Michael Lindsay said:
I think Komodo is DCT based and Red DSMC2 is Wavelet based .... apple and oranges... both fruit but different
Click to expand...

Is this confirmed? All reading I've come across points to wavelet being superior to DCT. So why switch? I see no advantage to image quality and based on the difference in recording times, it seems DCT is even worse at that as well?
What am I missing? What is the reason for this change, if it's even confirmed to have changed?
 
Christoffer Glans said:
Is this confirmed? All reading I've come across points to wavelet being superior to DCT. So why switch? I see no advantage to image quality and based on the difference in recording times, it seems DCT is even worse at that as well?
What am I missing? What is the reason for this change, if it's even confirmed to have changed?
Click to expand...

Maybe processing power required and amperage requirements for that processing power? A possible compromise made for battery life and frame rate for data?

I am just guessing, I don't even know if they did change.
 
Christoffer Glans said:
Is this confirmed? All reading I've come across points to wavelet being superior to DCT. So why switch? I see no advantage to image quality and based on the difference in recording times, it seems DCT is even worse at that as well?
What am I missing? What is the reason for this change, if it's even confirmed to have changed?
Click to expand...

Likely komodo is a built mostly on existing tech, there is a pretty big possiblity that the camera did not start as a blank paper on Jarreds desk but is a red build ontop of something developed by a third party and then possibly the same features as in previous cameras could not be implemented.

And also even if not so, the battery life etc kind of hints that it´s not really the same engine inside as before. The processor or what ever could possibly not do what DSMC1 and two does.

Still I dont know the differnces between the the komodo codecs and the dsmc2 codecs or even the data rates for Komodo. But one can only speculate that 5:1 for exampel would look different if applied to both cameras and for that reason they found it to be better to change the naming convention for compresion.


But agian, personally I like the old one. it´s easy math to understand that if I shot 5:1 my mag last half the shooting time compared to if I shoot 10:1 or if I want something in between I can kind of easily figure out what duration I will get. HQ LQ etc on the other hand does not say much, but those using komodo regularly likely figure it out quite quickly.
 
Robert Hofmeyr said:
Not sure if this has changed, but Phil said he was getting 1 hour per TB in HQ and only 10 minutes more in MQ (and LQ was not yet enabled). I agree with Bjorn above that it would be nice to have ratios that make for easy runtime calculations. Eg. HQ = 1h, MQ = 2h, LQ = 3h.
Click to expand...

Yes, so because DSMC2 gives you around 50 minutes on a 512gb card at 4:1, Komodo has much less compression or uses a worse type of compression that gives the same kind of quality with larger files.
 
Maybe it has something to do with the global shutter? Having to compress the entire frame rather than line by line? Definitely an important consideration.
 
Jon Dishler said:
Maybe it has something to do with the global shutter? Having to compress the entire frame rather than line by line? Definitely an important consideration.
Click to expand...

Could very well be the reason. I’m sure, horsepower, heating, and media write speed would be important factors.
 
Jon Dishler said:
Maybe it has something to do with the global shutter? Having to compress the entire frame rather than line by line? Definitely an important consideration.
Click to expand...

That only holds up if it was a fact that it compresses line by line. Why would it compress like that? The entire image is scanned, then put into a compressed form, otherwise, it would be compressed off the bayer sensor directly before put into r3d file format?
 
I have no idea, really, just trying to think why they would use a different method of compression, if in fact that is done. Line by line there would be a stream of data coming off the sensor continuously, whereas with a global compression it could be in large blocks? But again, I have no idea and would be perplexed since Red has just won a patent battle on their wavelet compression patent challenge against Apple, why would they do anything else if not needed? I apologize for making this guess which has no basis in fact, please disregard. I am in line for a white Komodo, and have a couple of DSMC2 cameras, so am keenly interested in any differences but should not speculate.
 
Jon Dishler said:
I have no idea, really, just trying to think why they would use a different method of compression, if in fact that is done. Line by line there would be a stream of data coming off the sensor continuously, whereas with a global compression it could be in large blocks? But again, I have no idea and would be perplexed since Red has just won a patent battle on their wavelet compression patent challenge against Apple, why would they do anything else if not needed? I apologize for making this guess which has no basis in fact, please disregard. I am in line for a white Komodo, and have a couple of DSMC2 cameras, so am keenly interested in any differences but should not speculate.
Click to expand...

I think you are onto something. It is well beyond my full understanding but I found this technical paper (Link at bottom.) From my layman's understanding is, that it is like HDRx from the same time period read out going into two different memory caches. One memory slot is fired for the long exposure (the full time period), and the other is fired taking data samples through out the frame to prevent ghosting/double imaging. Then the two images are combine like HDRx. (It could explain why the low-ish frame rate limitation, the more data there is during compression and lack of an HDRx mode.)

So the data heavy compression might be two different video streams rolled into one package. Each maybe compressed at two different levels themselves, if so the HQ, MQ, and LQ could be just affecting one of the streams, or both of them in different ways. (<<< All that is my imagination running wild with no real basis in fact.) Could you imagine trying to get the best quality picture by selecting two different compression ratios of what the camera could handle? So a factory preset at HQ, MQ and LQ makes a lot more sense. And Jarred's statement about "dialing" in the compression levels makes sense.

Then again, we don't know RED is using this method, but it explains away the limitations of the Komodo.

Link:
https://iopscience.iop.org/article/10.7567/1347-4065/ab00f3
 
I don't think Red compresses any version of R3D line by line. It compresses the R, G, and B pixel patterns of a whole Bayer frame discretely so that higher compressions can be applied to the red and blue channels compared to green. Wavelet compression can be done in blocks or fractions of the whole frame up to the whole frame as a unit. Whole frame compression delivers highest quality results but requires the highest processing power per unit of time. Given the massive increases in available processing power vs power consumption and thermal envelopes with latest gen hardware, I would think it more likely that they are compressing larger block patterns or maybe even the whole frame pixel pattern for each primary at once. Whole frame compression could limit frame rates compared to small block compression schemes. Not a major change from past wavelet processes, but one that would require updated software to decode.
 
David Rasberry said:
I don't think Red compresses any version of R3D line by line. It compresses the R, G, and B pixel patterns of a whole Bayer frame discretely so that higher compressions can be applied to the red and blue channels compared to green. Wavelet compression can be done in blocks or fractions of the whole frame up to the whole frame as a unit. Whole frame compression delivers highest quality results but requires the highest processing power per unit of time. Given the massive increases in available processing power vs power consumption and thermal envelopes with latest gen hardware, I would think it more likely that they are compressing larger block patterns or maybe even the whole frame pixel pattern for each primary at once. Whole frame compression could limit frame rates compared to small block compression schemes. Not a major change from past wavelet processes, but one that would require updated software to decode.
Click to expand...

There was a mention of DCT based compression being used in the Komodo. That would explain the higher data rate for the same quality since Wavelet is more efficient. It would also explain the lower power consumption and lower price tag since DCT is much easier to do in hardware.
 
Christoffer Glans said:
Yes, so because DSMC2 gives you around 50 minutes on a 512gb card at 4:1, Komodo has much less compression or uses a worse type of compression that gives the same kind of quality with larger files.
Click to expand...

Just reviving this. Do we have a definitive answer on why this is happening? Or if it will change to match DSMC2 compression ratio > file sizes?
 
Yes I would like an update on this as well.... I thought the whole point of utilizing cheaper CFAST media in Komodo was not to require (2-4) times as much of it to get the same compression ratios as a DSMC2 cam. I currently have been getting by with 2 x 480gb mini mags on my Gemini and I do shoot 2:1 compression sometimes but there are times during long interviews that I borderline need more media and I have been having to offload my mags during long jobs. I am thankful minimags have finally come down in price but I was holding off on getting more as I was hoping Komodo would be at the very worst "on par" with DSMC2 data rates or hopefully better in which I could pick up more CFAST (2 x 512gb cards for Komodo to start) and just use Komodo intercut with my Gemini as B-CAM rather than investing in more DSCM2 mags at this time as they will probably be obsolete once DSMC3 comes around. Obviously, there are still a slew of many benefits to Komodo (form factor, global shutter, REDcode at an affordable B-Cam price point, etc.) that make it really worthwhile for my workflow but this definitely is a concern if I am going to need double the media storage for Komodo compared to an already data hungry DSMC2 cam. Not to mention such an increase in data rates affects requirements for longterm external storage and the required volumes for SSD editing drives as well as I already max out 1-2TB SSD editing drives fairly easily on certain projects just with my Gemini footage alone. So I cannot imagine adding Komodo into the mix if it has double the rates of my Gemini.

Can anyone lock down data rates for sure on Komodo and how that translates into available storage / recording time on a 512gb CFAST card?
 
Last edited:
You must log in or register to reply here.
Back
Top