Actually the R5 external recording allows for 4K HQ, fully subsampled from 8K.

But I also agree that the Panasonic S1H is a fine tool as well.

I really wasn't trying to start an argument here, just point out something people who were happy with using an external recorder might be interested in, and which AFAIK was not generally available information currently.

The 4k HQ from the R5 has the advantage it has R+G+B info for every pixel in the 4k image, which downscaled lower resolutions don't. For example the S1H uses 19.5M pixels for 16:9 video. So you have half that for G pixels and a quarter that for R and B. This is good, but behind having 8M of each (especially as the data in the R5 is at the exact pixel position, the S1H is near the position). What's the difference - wait and see.

Since no-one is delivering 5.9k video to anyone it's getting scaled down to (presumably) 4k. It's an advantage over native 4k (-ish, depends how well it's scaled), but not over 8k that has been downscaled. Also there's ProRes raw (can you really not fix the white balance??) vs ProRes from CLog (but CLog3 would be nicer).

P.S. I really like my GH5 (downscales 5k to make 4k) but comparing it with my GH4 (uses a sensor pixel per video pixel) you do get a few very minor colour issues with the GH5 due to the scaling. Nothing to get excited about, but if you know where to look you can see them. (Frankly the public is happy with totally moire-ed chain-link fences on TV and in major motion pictures so they aren't noticing/caring if it was 10x worse. Content is King.)

While the 1080p on the GH3 and GH4 are very poor compared to the GH5, that's not due to scaling but that they skip pixels in a poorly designed way - Canon do that a lot better in my experience.

(But IBIS and 10-bit video rules - I no longer have my GH3 or GH4.)

SteveV4D - note you posted while I was writing this (above this point) and it wasn't written as a response to your comment.

I think comparing the R5 and S1H could go on for ever, but are people shooting major movies on the S1H or are "Professional Editors" not going to be happy with CLog in ProRes? Like I said, let's wait and see - I wanted DPReview TV to do a comparison to provide some answers. (Without knowing you could shoot 4 hours of 4k HQ on the R5 to an external recorder people wouldn't be considering it.)

Well, provided you don't want AF... (Remember I'm a Panasonic video shooter...)

Plus I'd like to see a comparison, as the 4k HQ files look amazing... I can't see why many people would shoot 8k unless they want to crop it...

Its like comparing my Pocket 4K to my GH5s, same sensor, but GH5s is sharper and more video like in look. Many use promist to soften the image even on the Pocket. So sharper isn't always better. Whereas 12bit gives you a stronger image to work with than 10bit. I agree 8K isn't for delivering. Cropping and downsampling. But 8K RAW external would give you that 12 bit. And the advantages of RAW.
Oh and speaking also as a Panasonic user myself, AF is pretty bad. Its why I never got the S1H. I'm hoping the next model will rectify it. Its the last thing Panasonic need to give their cameras the top spot for hybrids.

I really wanted to like the Tiffen Black Pro-Mist 1/4 Filter, but just didn't make it...

Hmm, what I remember I saw I cannot find now! Anyway, it seems that the 5th–4th line from the bottom (p.20) support what I said.

⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜

And: this page you recommend, what do you think is interesting there? I did not find anything which is not applicable to stills there — and I know compression of stills very well!

beatbox, check out this article:

https://www.dpreview.com/articles/4653441881/bit-depth-is-about-dynamic-range-not-the-number-of-colors-you-get-to-capture

There is definitely a big difference between 12bit and 14 bit, at least from a theoratical point of view. Now if you would see the difference easily when the captured footage is transformed in to the display format, that is a different discussion.

@RubenS89, I am familiar with how bit depths and DR work, but it seems you didn't actually understand that article or the point Richard was trying to make:
https://www.dpreview.com/forums/post/62149634

The sensor doesn't have theoretical extra stops, because it is a single sensor. It is 12-bit ADC in video modes. And it is not 100% noiseless (and often won't have 100% perfect exposure). So there isn't a practical difference between 12-bit and 14-bit. Even in theory: it just depends on how deep your theoretical model will get. Because the "theory" only applies to a limited, purely numerical (as opposed to physical or photographic) theoretical model.

And no, the topic isn't a "different discussion" because the discussion is regarding a practical sense (as clearly noted by my earlier phrases "in a practical sense," "minor," "noticeable" above). Did you miss that?

Now if you want to talk in theoretical numbers with no bearing on reality, then that is really the different discussion.

@beatboxa I didn't mean to hurt your feelings.. I was not disagreeing with anything you said...

You are right, when the on-sensor A/D converters are 12 bit then there is nothing to gain if you store in bit depths higher than that.

If your on sensor A/D converters do output in higher bit depths than that, than you can have higher DR ranges than the standard 12 stops of most camera's that have 12bit A/D converters in video-mode.

You didn't hurt my feelings.

And you are again not correct. DR is not the same thing as bit depth; and increasing bit depth does not automatically increase DR.

Claiming that increasing bit depth also increases DR is like claiming that increasing the number of comments also increases the amount of useful information in this thread. This is clearly not the case, since some of the comments appear to be noise. It's not clear if this comment will hurt your feelings or not.

I'm not claiming that increasing bit depth will increase DR? I am claiming that decreasing bit depth will decrease DR.

So if your sensor is capable of outputting more DR than 12 stops you will also need to output more than 12bit from the on sensor A/D converters (since it is linear data).

Exemplary comment.

I'm not a native English speaker so I had to google translate 'exemplary'.

Meaning:
'serving as a desirable model; very good.'

Thanks!!

You're welcome!!

@beatboxa: > “ Log vs linear are tradeoffs, not "better vs worse." ”

There is no trade-off in 10-bit storage with γ=2! (Well, at least if your full well is below 250K electrons.) So it is going to BE better than any linear format which involves shadow-loss!

Likewise, with about 50K full well, even 10-bit log can be made trade-off-free. (Although I have no clue why one would use log when γ=2 is always better!)

 (Of course, when camera is capable only of 12-bit readout, all this is moot! Thanks for pointing out this data-point!)

@beatboxa: “for a similar relative improvement from 2-bit to 4-bit (which is significant), you'd need to go from 12-bit to 24-bit. 12 to 14 is really minor…”

This is complete bоllocks.

Every step of extra DR corresponds to an extra bit in the storage (unless one uses γ=2 [which is the optimal storage-wise], when it is ½ extra bit in the storage). And every step of extra DR is a significant revolution in how photos can be made (and WHICH photos can be made).

What you are right is that the current technology of sensors saturates at about 13-bit readout (requiring about 8-bit RAW storage, with optimal compression). (I do not know how α7sIII behaves — it may be better than this…)

Still, this is a big difference with 12-bit!

@ilza: There is a tradeoff. You lose precision in highlights for shadows. That is how log works. You don't have unlimited values where you improve shadow tonality without any consequences.

Also, no, every step of extra DR does not correspond to an extra bit in storage. What you wrote shows why you are "completely confused," because you misunderstand basics and methods. DR and bit-depth are not the same thing; and if you have a single sensor in two different modes, they still have the same FWC. All you are doing at that point is often changing the ADC, which changes the tonality while keeping the same DR. Raw tonality is linear while stops are logarithmic. This is why we have log profiles in the first place. And so you would need to double bit depth to have the same double effect on tonality. This is why there is a much bigger difference between a 1-bit (black & white only) vs 3-bit than there is between 12-bit vs 14-bit.

@beatboxa: “There is a tradeoff. You lose precision in highlights…”

BS. Read the theory of quantization of data (developed in ’70s and ’80s). You forgot about dithering! The discussion of quantization cannot be separated from the discussion of noise — and the fact that you do not mention noise (correlated with full well) shows that you do not know what you are talking about.

I repeat: 10-bit γ=2 storage IS LOSSLESS (for any measurable/detectable purpose) for anything less than 250Ke⁻ full-well. (And, in fact, for much more than this!)

> “Raw tonality is linear”

I hope this is just a slip of your pen. RAW has no tonality. Tonality comes only in post. (Not even mentioning that this is completely wrong. Sony RAWs have, more-or-less, γ=2.)

⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜⁜

For the rest of your answer, you seem to be utterly confused by what I wrote. (It assumed knowledge of basics of quantization, sorry!) Time permitting, I’ll try to locate the place where you got lost — and report,)

@ilza: You're the one who clearly doesn't understand how quantization works. Did you read the links? Can you read them? And if you struggle with that, some even have pictures.
Regarding noise, this is one of the reasons DR does not equal bit depth (even though you've incorrectly stated several times that DR and bit depth are the same). How come you didn't mention noise before? The fact that you do not mention noise (correlated with full well) shows that you do not know what you are talking about.
Raw tonality is simply the linear values correlated to the pixels. They may not be rendered or mapped, but a value of 5 is different from a value of 6, for example. Basic and so simple that even you might be able to understand this concept that numbers are different from other numbers.
I'm not confused by what you wrote. I can clearly see that you are learning this stuff (or trying to) as you go, since your responses constantly change scope.
You seem to have time. "Ignore user" time.

I'm sure the calculations within fcp are done with at least full 32bit precision? It seems unlikely that there would be any loss in order of operations, since the precision one is starting with is so much lower.

I know next to nothing about video editing but this makes sense, similar to how you wouldn't convert a raw photo to jpeg, then adjust WB on the jpeg file after that. Do the biggest latitude adjustments early on when you have the most file latitude to work with, compress afterword.

"Don't need to be" or "aren't"?

The entire purpose of a log is to compress data into a smaller bit-depth; and the entire purpose of a LUT is to decompress (map) these values into a lower-bit-depth output (because the logs & LUTs are specific to a bit-depth that is almost always less than 32-bits).

So whether it's a file or not, the log & LUT will ultimately have a lower bit-depth and be destructive. Doesn't matter about the processing, unless you're saying that they are using a 32-bit log and 32-bit LUT?

Good luck starting the grade from linear raw. Do you know how the image looks like in that stage? All the drama of online forums in a nutshell. People who have no idea about a specific problem offer unfounded opinions hiw to solve it. Bravo!

Look, if a video mastering program is not working with floats within itself, I would be surprised. Math should at least be done in this space as desktop processors are built to do math in this space. This means the order of operations does not matter because the representation in the video editing program is orders of magnitude more precise than anything coming off the camera.

This isn't about ability to do floats in general. It's about precision and steps. If the log and LUT definitions aren't at least the same bit depth as the raw, you'll lose precision (and for log, you might lose some precision in some ranges even if it is at least as precise).

In other words, suppose I define pi but then I immediately store it in 2-bit (like a log & LUT). The value is now stored is 3 when I recall it. So it doesn't matter if I do 16-bit, or 32-bit, or 64-bit processing, because these will just change 3 to 3.0(0000....).

So the log & LUT would have to be defined at a more precise level. But these are not 32-bit float logs or 32-bit float LUTs. Further, the assumption is that the application is pre-combining all steps and not writing to memory in-between.

Alternatively, if you mulitply by float pi and then round the resultant value to 2-bit, you may come up with a completely different answer. Order of operations and precision of the log&LUT step matters.

ProRes RAW gives you a 12-bit log file, instead of a 10-bit log file in a normal stream, with more headroom for grading. Log gamma is old stuff by now, at least if you've done more than dip your toes into video (or just read about it).

I mean, it boils down to: in raw, is Panasonic outputting raw or log? Because these are different things. Log is designed to trade away highlight precision for shadow precision, while raw is designed for a linear read of the sensor. In other words, a 12-bit log derived from a 12-bit raw should be better for shadows and worse for highlights--and in any event would be a destructive operation. Because 12-bit defines the number of storing values, and linear (raw) vs log should define how the input values map to those storing values. See the links above for context.

Regarding destructive vs. non. In my experience with DaVinci Resolve and Premiere, LUTs are like adjustment layers in Photoshop—obviously they're not identical. But they are non-destructive and it's possible to reduce or increase their intensity just like you do with adjustment layers. I assume it's the same in FinalCut.

Regardless, you don't add your LUT when ingesting raw footage. You do it in the grade which is several steps later.

@beatboxa you're welcome.

You are mixing video and stills nomenclatura. Load up your z6s linear raw in fcp and look what you see before converting it to log.

Converting linear raw to log space in post is not the same as recording a compressed format with a logarithmic gamma curve. 12 bit linear raw is 12 bit log after conversion.

If you recorded raw, converted it to log and then graded from there with or without a lut you are always working nondestructively on the raw data and everything you do happens in 32bit float. Obviously the you cant enhance the precision of your raw, but as long as you dont create lower bit proxies all your information is there.

@misspiggy: no I'm not. A raw feed is a raw feed. A log curve is log curve. And a codec (like ProRes raw) is just a codec. That's why Jordan compared the stills to video conversion here. I'm well aware of how the Z6 works (and how while it's recorded in ProRes raw, it's not really close to raw, since the Z6 has a 6K sensor): https://www.dpreview.com/forums/post/63609656
But we're not talking about the Z6. We're talking about the S1H.

If you record ProRes raw and convert it to log (for ease of correction), you are not "always working nondestructively on the raw data," as evidenced above. Might be theoretical, or might be in encoding. But if you were, you wouldn't have this WB issue. In fact, if you want to work on the raw data, you even have to set up this conversion completely differently in FCP, completely negating your statement "you are always working nondestructively on the raw data." Because that's not how the word "always" works.

Poor Kermit, having to deal with this.

It doesn't matter how a LUT is represented. It only matters the space you are doing the calculations in. A 2bit LUT applied with floating point math has 32 bits of precision. Again, it doesn't matter how it is stored.

@beatboxa you are confusing the poor prores raw implementation in fcp with a proper raw workflow of proper raw codecs. The white balance issues in this case are due to the implementation. You might want to try assimilate scratch where you have acess to traditional raw wb and iso adjustment.
Converting linear to log in an able nle just changes the way your values are displayed not the quality of your data.

I suspect you have not worked with raw video yet. Hence the confusion.

No, I am not. The ProRes raw implementation in FCP is exactly what I am reinforcing as potentially being the root cause. The implementation. Order of operations, processing, and actual conversion methods are implementation. Raw, ProRes Raw, and log profiles, and their relationships are standards or theories.

You are the one who is mixing both concepts, like when you write things like: "If you recorded raw, converted it to log and then graded from there with or without a lut you are always working nondestructively on the raw data and everything you do happens in 32bit float."

@ beatboxa rereading your posts it is clear that you speculate that jordans workflow is flawed. Now you pretend that you never said that?

Anyhow, you offer an opinion without any firsthand experience in a video raw workflow, putting out nothing but unfounded speculation. That was exactly what i was saying in my OP. Thanks for corroborating it. I'm done here.

Thanks for the explanation.
Is the 4k 60 external from the R5 the subsampled 8k or the lower quality lineskipped.
It will be intersting to see if an update comes from Atomos to allow 4K 120p from the R5, I think they have done that for the Sony A7Siii.
I'm not aware of an external recorder from anyone that can record 8k as yet, so it may be that Canon is waiting for the Atomos recorder that is planned for later this year.
BTW I think the S1H is the better camera for video, it just seems to be a better all round package.

Its the 8K downsampled to 4K, so the good one. Getting even 120fps externally will require Canon to update the firmware. I'm also not sure if there are any limitations of micro HDMI vs the full HDMI port, which could restrict output.

Thanks for the info. Firmware updates should be easy enough but if there is a limitation on the HDMI output that is a different issue. I am surprised that they didn't go with the HDMI type A like Sony and Panasonic.

beatboxa

It’s not that the S1H HAS TC, many cameras can run timecode. The S1H can accept TC from an external device. In a production, when you have several cameras and sound on set you want to have 1 clock for all devices and each device needs to at a minimum be able to accept TC from that device (jam). The S1H can do this and it uses an industry standard interface. The Nikon (and most other photo-styled cameras) cannot accept TC.

@robertel I agree that it's not necessarily performant or reliable timecode, and that it's generally pretty crappy. But it hits the spec sheet, just like how the R5 does 8K and 4K, or how the Z6 and Z7 do "raw" video. ;)

Checks the box. Whether it does so well and usably wasn't what I was responding to. :)

By that definition, Home Depot should carry the camera in the tool section under hammers since I can pound a nail with it.
I'm very happy with the Z6 into the Ninja V, I picked up the timecode module for the Ninja as well.