androidlad

In the pictures your monitor wasn't actually powered via micro USB ?

It's starting to look like it's intentional, to manage processing power.

Fuji just announced V3.0 firmware for X-T3, coming in April. It'll come with all of the above, and a few goodies I'm not allowed to say ? And here are the most requested features according to Fuji: With #8 1080/240P being the top priority and will mostly likely be introduced in a firmware update after V3.0 release.

This one's the best: https://www.lindy.ie/cables-adapters-c1/audio-video-c107/0-5m-cromo-slim-high-speed-hdmi-to-micro-hdmi-cable-with-ethernet-p7228 Full metal connector, slim profile, flexible cable.

V2.10 firmware for X-T3 released: http://www.fujifilm.com/support/digital_cameras/software/firmware/x/xt3/index.html 1. Recording over 4GB movie file as one file 　Movie files are no longer split when the file reaches 4GB file size. The file is recorded as one file providing an SD memory card greater than 32GB is used (excludes 32GB). 2. Fix of slight defects. F-log/film sim output mode 4K constant 1.18x crop issue is not fixed in this update.

4K 30p on GFX100S is derived from vertical line-skipping and horizontal pixel-binning, plus 11bit ADC. Quality won't be good at all, but it keeps the medium format FOV.

ARRI has a tiltable mattebox SMB-1/2 specifically to address filter glare

If you read the IMX294CJK full data sheet I posted earlier, you'll see the 14bit readout drive has configurable resolution and the framerate can be "overclocked" to maximum 30. Slower readout refers to precision, not bandwidth as it would have zero effect on the noise floor. 14bit ADC almost doubles the rolling shutter.

CST node is a pure technical transform and does not have any roll off.

Sony is the only brand that use 8bit for HLG. Panasonic (GH5/s), Canon, JVC all enforces 10bit, with either H.264 or HEVC.

Interesting that EM1X still offers 12bit RAW only. For 14bit RAW on a M4/3 sensor GH5S is the only option.

Because it's the same as Z6 and A7III due to shared sensor architecture. Around 24ms in FF supersampled 4K.

HLG colour is more true to life, and the blue hue in the shadow is correct while F-log is more magenta, not grey. The scene was shot 2 hours before sunset and there was very little direct sunlight (~5400K) at the time, it was all lit by the mostly clear blue sky (~10000K), which was reflected by the water. In hindsight, I should have set the white balance a bit higher.

It's a requirement in the standards: http://www.arib.or.jp/english/html/overview/doc/2-STD-B67v2_0.pdf Of course it's not enforced like everything else and it's the end-users that get all the trouble, Sony's 8bit H.264 HLG files are not directly compatible with most HDR TVs, or YouTube HDR.

The best way to shoot HLG is connect the camera to a true HDR display that supports HLG. Also, Sony's 8bit HLG implementation can't be called official HLG. As BT.2100 HLG spec stipulates either 10bit or 12bit.

Since posting this a while ago: ..I've been exploring the power of HLG picture profile introduced two months after X-T3's release. I'm pleasantly surprised by the refreshingly new colorimetry and better (not higher) dynamic range distribution. To me, X-T3 now feels like a completely new camera shooting with HLG. So long F-log! Here's a better comparison than the one from my previous post: F-log with Alexa LUT generated by LUTCalc, no grading, WB 5300K, Shift 0: HLG with Alexa LUT generated by LUTCalc, no grading, WB 5300K, Shift 0: It's clear that HLG completely removes the magenta hue in F-log and renders shades of blue in a way that's reminiscent of Alexa. Reds are deeper and richer with very little orange shift seen in F-log images. Also, HLG makes full use of 0-1024 10bit code value, while F-log throws away 0-95 which could contribute to banding. Here's a graded frame from a feature film I'm currently shooting, entirely using X-T3 outputting HLG to Ninja V. Raw HLG frame: HLG mapped to ARRI Log C Wide Gamut using LUTCalc: Observations for working with HLG on X-T3: 1. Respect the ISO1000 rating and be extra careful, do not over/under-expose more than 0.5 stop, ideally should be spot-on. HLG wasn't intended to be an acquisition format so there's very little room for error. 2. In low key scenes (like the one above), shadow area will have visible grain, with ProRes HQ 10bit 422 recording, the noise pattern is pleasing and monochromatic with a fine 35mm texture, turn in-camera noise reduction off (-4) and "interframe NR" off to preserve the texture, otherwise you get blotchy patterns. 3. An external monitor/recorder with custom 3D LUT feature is a must. X-T3's HLG implementation follows ARIB STD-B67 NHK spec which places middle grey much much lower than BBC spec. You need custom LUTs to help you preview final exposure, otherwise it's hard to see what's going on in the scene and may lead you to overexpose. 4. HLG has a slightly cooler white balance compared to F-log and film sim, so be careful setting the kelvin value. Factor this in when lighting and developing looks for your film. Another reason why a colour accurate external monitor/recorder would be extremely helpful when shooting HLG. 5. Ideally you should shoot HLG with external ProRes HQ 10bit 422 codec due to the aggressive tone curve manipulation in post. Minimum is 400Mbps in-camera HEVC. 6. In post, use a BT.2100 HLG to Alexa 709 3D LUT for grading, HLG uses BT.2020 gamut so you should map it to a BT.709 gamut first, do not grade directly and simply add saturation, the colours will be wrong. Alternatively map it to ARRI Log C gamut and use popular film print LUTs.

X-T3 crops 1.18x in 4K 60p on top of the sensor 1.5x. Compared to FF it's a 1.8x crop.

You have the option of Hawk 65 Anamorphic (1.3x) or Cooke Anamorphic Full Frame Plus (1.8x) https://www.vantagefilm.com/en/news/null/the-return-of-hawk-65-10330 https://www.cookeoptics.com/u/news.html?Open&k=cooke-anamorphic-full-frame-plus Then a PL to G adapter: https://www.adorama.com/kagfxpl.html

Remember it's 3 readout for a single exposure, even if the ADCs only operate at 10bit, it would be equivalent of a 30bit ADC.

Thanks for posting the links, it would be more sensational to post that BBC study's editorial title "H.265/HEVC vs H.264/AVC: 50% bit rate savings verified", yes but only at lower bitrate. This is exactly what I meant. For "higher bitrate" tests in the second paper, is that really how you interpret the figures and the study itself? Then please explain how HEVC manages to achieve ~33dB PSNR with a bitrate of 0?

Sensors cannot distinguish image content and adjust exposure on a per area/per subject basis. Sony has a working 1/1.55" automobile sensor IMX490 that achieves 20 stops (120dB) dynamic range in a single exposure. Basically a 3um photosite with a 0.9um subpixel. Three readout for every exposure - big pixel + high gain, big pixel + low gain and small pixel, them merged to get an 120dB signal.

It's too early to say 72Mbps is too low. It largely depends on what encoding parameters Panasonic use (CRF, GOP size etc.)

Sorry but I'm gonna correct it every time I see this. 72Mbps HEVC is identical to 72Mbps H.264. That 50% bitrate saving marketing BS only applies to extremely compressed materials for streaming. For 4K it would be around 10-20Mbps for HEVC to show its strength. The reason they offer HEVC is because BT.2100 HLG spec stipulates it.