amateurmike

I personnally find it quite good on my S1H. I feel it's the best focus peaking i've ever used on any camera i owned (several sony a7, several Panasonic GH, BMP 4k...).
I thought it would be hard to nail focus but with use it's actually very possible. 

At least you don’t have to explain to your wife that you are about to spend thousands and thousands of dollars on audio equipment in this current economic environment.
Its good but not great. It tends to be slightly off, much better when you use the zoom function and peaking enabled but we can’t do that when live recording ;-(

Personally I'd rather DPAF than PDAF, I can't stand those weird lines you get at higher ISO on PDAF sensors
Yeah it's good peaking. I can't really focus pull that well on Ninja V due to the high HDMI delay. You need to rehearse pulls so live pulling i HAVE to do on the screen

I think it's great. I find that I have more trouble with my own vision than I did with focus peaking accuracy. When I use the EVF, nailing focus is quite easy. When I run on a tripod or gimbal, the internal screen, as good as it is, is simply too small, so I'm almost always using my Ninja V then anyways.

+1
I've already got rid of numerous accounts to save our eyeballs and sanity, but apparently even more need to go.

My brain cells are crying in agony reading some of these posts. Can't you just ban these people coming here to argue in bad faith just to obfuscate progress?

Basically the timer kicks in whenever 8K or 4K HQ is enabled in the menus and there is a live-view feed on the LCD or EVF (even if it is hidden behind a menu overlay).
That's probably just how they implemented the cripple clock in firmware.
When the screen is off it probably disables the mechanism they are using to calculate run times... either by error, or on purpose to satisfy Atomos.
That the scorching hot ambient temps and black alloy casing absorbing so much external heat don't impact the timer, has to tell you something!

So I just tried recording externally with R5 screen off.  (Using the R5 battery, with no cards in camera)
This was indoors in a cool room.
I started the recording on the Ninja at 09:14
I stopped the recording at 10:15
Recorded 4K HQ continuously for 1hr and 1 minute with no overheat warning on the R5 screen, and no overheat shutdown through the duration of that hour.
I immediately shut camera down, then unplugged the HDMI cable, and removed battery.
I then reinserted the battery and put in the CFexpress card, turned camera on and overheat counter said I could record 15 minutes.
 

Camera control board shouldn't report 65c in 8k recording. 

The temperature reported by the EXIF data more-or-less corresponds with the Chinese heat gun thermometer tests out there as well and it closely resembles the ambient temp of my room at the moment, I am sweltering in 30 degrees heat!
I suppose the easy test would be to cool the camera right down in a freezer, quickly take 1 shot then analyse that EXIF data.
It is very unlikely the camera is reporting wrong data in the EXIF. It is very basic to get right, even for Canon.

If there is indeed a hardware problem such as the LSI running too hot or certain parts of the chip not turning off when idle, then Canon may have originally developed this kind of temperature monitoring system to keep things in check.
But the fake element of it is that the actual temps my camera is reporting are nowhere near problematic and the recovery timer is completely out of whack with both ambient temps and the actual cool down temps of the electronics.
So it is likely they found a convenient outlet in the temp management system for a classic Cripple Hammer.
I want answers from Canon and I will be seeking them starting tomorrow.

Hi, as I wrote in my blog article, field tests are missing and I am interested to learn about the practical impact myself.
OTOH, external 10 bit N-Log may be just as good and may have less risk of flickering (between frames) at lines, edges or fine regular structures like roof tiles or fashion texture. That would be the real-world test I am most interested in.
@gingercat
That's absolutely not the case here. The topic has been dealt with in replies above.

This looks like a sincere question to me. I withdraw my claim you‘re trolling and apologize.
I for myself have a professionally printed A2 version of my test chart. However, for a zone plate chart, even that shows signs of remaining printing artifacts. And Marc doesn‘t have any usable printed version.
However and because we only needed a small fraction of the test pattern, there is an established alternative in the testing scene: monitors! As odd as it may seem at first glance, they can be put to good use if a number of rules are respected. I know about at least one professional lens calibration company which is using monitors to display test charts. The most important rule is that monitor subpixels (their projection when photographed or filmed) must be MUCH smaller than a sensor pixel. Other rules are that the test pattern must be resolved with no aliasing, and that there is no flicker. We obeyed these rules. Which is also why we know to have no extra moiré effects from the pixel grid.
It is also the reason why:
1. the monitor shows a small fraction of the test chart only, such that the remaining part is fully resolved by the 3840px wide monitor. The original test chart is 8400px wide and 9.6MB large. It‘s pixels are displayed at 100% or 1:1. There is no moiré in the screen display to the naked eye. The test chart file was carefully created to avoid aliasing as much as possible, by myself. Which is no easy task for a zone plate chart.
2. the monitor appears so small in the video, as it is far away. This makes the monitor pixels and subpixels disappear completely, there are more than 10 monitor pixels per camera pixel ... Hard to beat with any printed chart! It also ensures that we have spatial frequencies beyond 4k to test for. This is crucial for the test and any attempt to reproduce our results!
3. minor sources of blur (lens, focus, motion) destroy results as we depend on high spatial frequencies being resolved.
Btw, the article DOES contain a link to a test video before cropping.

14,000 views.
Oops. See what happens when you take the sexy KPOP girls out a Youtube vid?!
You take the sexy ass wiggling out and what have you got... just a nerd with a new camera
Nothing against the guy, but I have no clue what Blackmagic are expecting from this strategy.
How many KPOP fans are there for the girls and music, and how many of his subscribers are interested in a Pocket 4K Camera?!

What's the point of giving the first cameras to pros then?
Everyone will have their own personal opinion but I think the footage just shows that lacking IBIS hurts handheld shooting.
Until I have shot a great variety of Cinema DNG clips to grade, I am not able to judge the camera. In this video, the footage looks no better or worse than a GH5S, A7 III, etc.
LOL.
Was that not already obvious to you from any everyday shoot with any camera? You suddenly learnt that useful info from this clip did you... Oh.. Ok.
The rolling shutter should be ok as it is the same sensor as the GH5S, 13ms readout.
Yes, important not to be personal. One can critique a video, without being personal about the artist. I am just saying he did not put his best foot forward with this work, and it's a very primitive test video shot like stills. I think, if you're going to have the privilege of one of the first demo cameras you should be doing a lot better stuff than that, that's all.
So this is his best work, a load of tits and ass.
3m views though, which gives you an idea of why he has a demo camera!
 

The nature of the 'inner circle' has a lot of variety.
You can be in an inner circle of "yes men" who only write advertising disguised as reviews.
You can be in an inner circle of professional shooters who are biased towards a particular company, because the relationship with the company helps their work get noticed.
You can be in an inner circle of high profile users offering feedback on a camera, like I am with Panasonic and the GH series.
Or you can be in an inner circle for no other reason to promote your blog about cameras, which is the game Cinema5D is playing.
I don't actually desperately want to be in an 'inner circle' with the big brands, because in the long run it hurts the content on the site. If I were too close to the camera companies I would even start having to censor negative opinions on the forum about particular products, if they doesn't align with being on-message. Why would I want this? Why would I turn my passion and hobby of writing blog posts about my filmmaking and equipment, into unpaid work for the PR agencies and camera companies?
I want only to have the most basic and respectful relationship with a few core companies I respect and use the products of like Panasonic and Blackmagic. I want to be able to review the cameras early and at a cost which is acceptable for me, because I can't go around spending $10,000 a month on new gear just to review it.
In addition, if a company is getting an absolute ton of attention on my blog, it is only right that they recognise it and help me out a bit.
Good. Close the door after you, there's a very chilly draft!

Footage with the default settings on this camera looks great, if a little clinical. 
I have been toying around with the settings whilst comparing it to the nikon d5500. It seems to me that the best way to get a slightly more filmic and nicer look is to use the following:
Natural 0 / -5 / -5 / -2 (cont, sharp, nr, sat). -2 highlights. No iDynamic. And whitebalance adjustment set to A3 G3.
With this setting, greenery looks less digital green and has more of a warm tint to it like film. And skin tones veer less towards the red and again has a warmer appearance (without looking yellowy like with GH4 stuff). 
 

Stacking adapters works just fine as long as you keep to the prescribed flange distance for that lens. If you have a Canon EF speedbooster on your micro four thirds mount, it is for all intents and purposes an EF mount and will work fine with any adapter that promises infinity focus on a Canon camera. 

As for the Roxsen Speedbooster, you're in luck! I actually own that exact Speedbooster for my FD glass. It's definitely not useless on an APS-C camera; in fact, I like using Speedboosters to get double the focal length choices from the same number of lenses. For example, if I have a 24mm and a 50mm, that gives me a 24mm (24 on the SB), a 35mm (24 with straight adapter), 50mm (50 on the SB), and 75mm (50 with straight adapter). More flexibility, less weight. It also just gives you another aesthetic choice with your lenses--do you want the S35 look, or the VistaVision/FF look? 

The Roxsen has performed fine in every situation I've used it in thus far. No issues with weird flare, strange bokeh, or softness on the edges. Just brighter, sharper, wider images. Then again, mine is for M4/3. You may get different results on the Sony. 

Ok this is going to be fun.
BTW in case you wonder why I have time and state of mind to write this long post, see here :-(.
So all you have so far is two contradicting claims coming from me and KS, and you cannot be sure which of us is right.
Let us rectify that. I attach the spreadsheet I used to calculate the bitrate values - you will need to keep it open in Excel because otherwise you will not be able to properly follow the rest of my post. NB. you will need Excel 2013 or later because it uses some Excel functions that were unavailable before Excel 2013.
I also attach a print screen for those of you who would rather not download it and instead look at a picture :-), or do not have Excel 2013.
Unfortunately the machine I am writing this from does not have Excel 2013 either so I cannot plug in the 40Mbit value - but you will see that the spreadsheet calculation gives the exact value I used and KS quoted - see cell E48 (If you want, tonight I will post an updated picture).
BTW if you have not heard of hexadecimal (base 16) numbering which is used in computing because it is easier :-) just remember that instead of numbers containing 0-9 you will see in the spreadsheet many numbers using 0-9 and A-F (coz base 16). If you are unfamiliar with this, do not be discouraged - I will not ask you to make any calculations.
So, if you are ready to invest 10 minutes in understanding where do the rates come from, here we go:
When I looked into the newly broken-in NX500 it was obvious that the di-camera-app was the program to look into - the name makes it so. So my initial objective was to see where the bitrates are set - well, to cut a long story short, I identified the place in a certain function call, and I saw that the bitrates were loaded into a CPU register via a couple of ARM instructions (different for each bitrate slot).
These instructions are called mov.w and movt. The end result of running them one after the other is that a 32-bit value is loaded into a target CPU register. For the bitrates, the target register needs to be R3 (except for nx500 pro bitrates which need to be put in R0 - note that KS did not say what is the cause of this exception).
Now we go in really deep.
Basically we need to re-encode these instructions such that instead of loading into R3 whatever bit rates Samsung marketing decided, they should load whatever __I__ wanted.
From now on I will start each paragraph with the cell you need to look at.
Cell D9 - So let us pick the target value - in this case 85Mbps.
Cell D10 - to keep things easy let us convert it in a 32-bit hexadecimal
Cell D11 - let us not forget the target register (for nx500 pro bitrates we would change this to r0)
Cell H5 After thoroughly reading the relevant section of the ARMv7 reference manual, I built the tables H5-AM9 and B13-AM23. Let us discuss then a bit.
The two ARM instructions I am trying to assemble are each 4 bytes = 32 bits. Since this is little-endian ARM, the values are stored in memory as shown in table H5-AM9. that is, a bit scrambled :-). If you read the ARM reference manual, you will see that these two instructions are very similar, the only difference is that one loads a 16-bit value in the lower half of the target register (mow.w) and the other of into the upper half of the target register (movt). They are encoded with some fixed bits (background white in the tables) and some variable bits which contain the 16 bits that make up the value to be uploaded into the register (yellow background).
So now all we have to do is split the 32 bits of the target value into two sets of 16 bits, and spread these 16 bits into the dedicated yellow spaces reserved for them.
Cell B13 Let us start with mov.w  (cell B13). The mov.w neds to contain the lower 16 bits of the target value - see cells E14 and E15. These 16 bits I then manually (ok through formulae) sprinkle into the proper yellow places in the encoded ARM instruction.
I then do the same for the movt instruction. The upper 16 bits from the target bitrate I "sprinkle" into the necessary places within the encoded instruction - see cells B19-AM23.
So now we have the ARM instructions codes, exactly how they look if we dump the memory: see cells AB16 and AB22.
BUT, since I am going to use gdb to patch the memory, they are inconvenient, because gdb would require four set statements if I tried to patch byte by byte the memory. So what I decided was to make out of these 4 bytes an integer (which can be patched with one gdb set statement). How to do it? Well, because ARM is little-endian, I needed to reverse the memory byte order to arrive to an integer that gdb will use for patching. Hence cells AB17 and AB23 - notice that the bytes are in reverse order compared to what you see in the memory. This is because gdb, when putting an integer into memory, will know ARM stores them in reverse order and therefore will do the same. The net result is that we end up with the proper value in the memory.
Finally, again to make my gdb task easier, I decided to concatenate these two ARM instructions together so I do not mismatch them and because they are easily split again in gdb. I did that in cell AD25.
So now all we need is to add the surrounding text to make it simply a copy/paste in the gdb script and thus avoid re-typing errors. This I did in cell Q27.
But this calculates only ONE bitrate value, and I am lazy so how can I force Excel to calculate all of them without me having to replace each value in cell D9? Well, Microsoft was kind enough to provide for array operations (I think they are called so) and I took advantage by telling Excel to basically replace D9, successively, with the values I wanted, and store the result in a table. You will find the table in cells D46 to G82.
From there I simply copied the result into the gdb script I publicly released.
Now if you have gdb, go to the memory addresses that change the bitrates and compare my spreadsheet results with the original SAMSUNG values, you will see that they match perfectly: the instructions generated by my spreadsheet are CORRECT - every instance of original Samsung bitrate set instructions, read from memory, matches the corresponding value calculated by my spreadsheet. This proves that the elaborate construction I put together in this spreadsheet is correct.
Finally, for those who open the file, there's a second section of the worksheet that I did not discuss, and which is basically the development of the algorithm used by my current nx-patch and which calculates on the fly the bitrate allowing you to set it to whatever value you want. This development I integrated ad-literam in my nx-patch - see bitRateOpCodes function in nx-patch.cpp.
NB. This is a very very short explanation of my thought process how I went from zero ARM assembly knowledge to encoding these instructions, by using the ARM reference manual.
I hope this post will clear any lingering doubts about the correctness of my calculations.
 

NX wip v18.xlsx

Hallo all,
I had a holiday in  Greece, and right before I left I could pic up a GX80 in my camera store. I really like the small form factor for travelling. That's al so the reason why I use mainly 4/3 lenses with it.
So for my kind of use its a great little camera.
In the link is a little piece I made with it, no colour grading are post stabilisation.