rawshooter

ffmpeg is multiplatform and only uses its own, included codec library (here is a complete list of all encoders). Performance is practically the same on Windows, Linux and MacOS, although the program is chiefly developed under Linux. Hardware acceleration indeed degrades the export quality to h.264 or h.265 if you use the (very fast) on-chip encoders of Nvidia and AMD GPUs. The CPU-only x264 and x265 codecs of ffmpeg yield much better image quality, especially if you use the "slow" or "very slow" encoding preset and the "film" tuning parameter. (They are also available in the Handbrake GUI.) You pay with much longer encoding time. Optionally/alternatively, ffmpeg can also use the Nvidia on-chip encoder (nvenc, which you can select in Handbrake as well). For me, as a commandline person, it's easier to just type "ffmpeg -i myvideo.mxf -vcodec libx264 -b:v 18000k -tune film -preset veryslow -b:a 192k myvideo.mp4" than clicking through Handbrake's menus, but your mileage may vary...

No, it's correct - the lenses of the old SLR system were called "X-Fujinon": The lenses of the current mirrorless system are only called "Fujinon":

This refers to the older, 1980s/1990s Fujica X-mount film SLR camera system, not to the Fujifilm X mirrorless system: https://en.wikipedia.org/wiki/Fujica_X-mount (This was a good manual-focus system, btw., with some really good lenses, which do a fine job adapted to the Sony A7 system.)

In the end, all the free/Open Source conversion programs - including Handbrake and Staxrip - are just graphical user interfaces for ffmpeg, and will thus yield the same results and performance. So one can simply stick with the tool whose user interface one prefers - or use ffmpeg directly on the command line. (Which provides more advanced functions such as ProRes and DNxHR encoding...)

@Andrew Reid, maybe what has been noted in this collaborative Google sheet should be included in your bug report to Sigma: https://docs.google.com/spreadsheets/d/1FUt1bfhWYftUhlABkO91goSNEYuPZzlrxmOVGDJnQ7E/edit?usp=sharing general (both stills & video) Touch screen to move zoom centre Touch for QS video specific audio level adjustment is deeply buried in a submenu audio levels cannot be set to a low level RAW clipping indicators 12bit linear RAW at 25p 12bit as 10bit + curve 24fps not supported DCI aspect ratios not supported Black level changes during recording at certain ISOs on firmware 1.01 support USB Audio DAC video recording unresponsive after using UVC still photo specific exposure compensation not easily available in M mode no DOF preview. lens always preview and focus at wide open. Manual focus exposure preview is not correct Magnifier location select with touch 2 - Feature requests Operation allow af-on button when in manual focus mode allow 2 second timer for movies. To disable shake at the beginning of the shot when on tripod allow manual focus override when in autofocus mode allow change of focus direction linear mode for focussing Ability to assign functions to left and right side of function wheel. Allow the record button to be used for custom functions Display magnify during movie recording magnify time after touching lens 0.5 seconds zebra and focus peaking at the same time Proper RAW histogram option, like RED cameras have Ability to vertically flip the screen, for use with a mirror to shoot twin-lens reflex camera-style. Color LUT support / bake LUT in-camera Recording formats: 10 bit non linear raw internal 10 bit non linear raw external 12 bit raw at 25 frames per second lossless compressed raw 10 bit MOV recording, HEVC True 24 frames per sesond option

Unfortunately not - while the RED codec is lossy, the RED patent much more broadly covers any kind of compression of raw/undebayered moving images.

For 16mm lenses (non-Super 16, 2/3" sensor equivalent, which is actually the vast majority of 16mm lenses produced), the Pocket 4K is an excellent camera, because its 1080p crop recording is exactly at 16mm film-equivalent sensor size.

With 44 x 33 mm sensor size, Fuji's GFX "medium format" is, in reality, more a plus-size full frame 35mm (36x24mm) format than what is known as medium format in film photography (60x90mm, 60x70mm, 60x45mm - i.e. twice to four times the sensor size of GFX). So arguably, they already have full frame, but only smartly market it as medium format.

"camera: EOS-M with MagicLantern, lens: Angenieux 8-64mm Super 8 zoom, recording format: MagicLantern 14bit raw" :

I can also warmly recommend the Tokina 28-70mm/2.8 which is a bought-up and continued Angenieux design: https://cameragx.com/2018/04/11/the-truth-about-the-angenieux-28-70-af-zoom/

What is also funny with the shutter lag: The picture shown first on the viewfinder after pressing the shutter button is taken with a different (shorter) shutter speed than the eventual picture recorded. You can test that when shooting fast-moving subjects with a long shutter speed. (Again, an indication that most camera reviews are worthless today, because no reviewer has spotted/described this issue yet.)

You're right, it's darker. Well, this is a buggy piece of a camera...

But the problem still is, as far as I can wrap my head around it, that any edge of two different colors in the image, we can't really properly interpolate and scale the single red, green and blue matrices, because their correct scaling would imply knowledge of the full color spectrum they are part of. To give an example, we might have an edge of a red object against a grey object. In the Bayer pixels representing the red object, red values would be high, green and blue values would be low; in the Bayer pixels representing the grey object, red, green and blue values would be about the same. But if we isolate the red matrix and only take the edge, then we'd see a high red value for the red object against a lower red value for the grey object. If we interpolate and scale, we'd average the two red values, which would be visually wrong - because we're (a) blurry the edge and (b) in the mix with the other blue and green values and their processing, create false colors. This is exactly what's happening in the test sample images I uploaded where the silver synthetic fabric with its fine, pixel-level white-vs.-black pattern provoked (a) blurry edges and (b) false (violet) color in the downscaled 4K CinemaDNG image. In order to avoid such artifacts, the scaling algorithm would actually need to know context - that is, which full-spectrum colors the single color matrices are part of. And that would require debayering the image... So, in other words, if we don't debayer, we'll never get a clean downscale. In theory, we could debayer and then algorithmically reconstruct a 4K Bayer matrix - but then, IMHO, it makes much more sense to encode debayered 12bit Log video right away. I'm talking about stills, too, and can't reproduce the behavior of your camera on mine...

I just checked, with an adapted manual focus lens as well. 1/50 in M mode yields 1/50 in the picture, both on the camera review display and in the DNG meta data. Are you sure that you were actually in M (and not, for example, in A or P) mode?

IMHO not even a firmware update can fix this, because there may be no clean way of scaling undebayered 6K to undebayered 4K. The elephant in the room is RED's patent on compressed raw video recording. Recording the full 12bit 6K raw sensor data uncompressed would require 864 MB/s (=7 Gbit/s), hit the limits of USB 3.1 and exceed the speed of most external SSD drives. So Sigma went for downscaling instead of compression as a way to reduce data throughput, almost like in the old days of interlaced video... The camera would be able to record 6K compressed RAW (since 1:2 compression is rather trivial - simple zip/lzw compression would do the job) if RED didn't have the patent stranglehold on this option.

Actually not... ? When the Sigma fp records CinemaDNG, it doesn't debayer the image, since a raw image is undebayered. But at the same time, I doesn't record the actual raw sensor image, but downscales the 6K undebayered sensor data to a 4K undebayered image - whose pixels no longer correspond to the sensor pixels and are a fake sensor pattern. Or, in less abstract language: the camera downscales the 6K raw sensor data into simulated raw sensor data of a virtual, software-made 4K sensor. Which creates all kinds of weird artifacts, as demonstrated above in the visual comparisons of the camera's 6K stills with the camera's 4K video.

The Super 16 crop mode on the Pocket 4K is IMHO superior to the original Pocket, because it is in 2.7K which yields very clean downsampled 2K/1080p, as opposed to the moiré-plagued and IR pollution-prone image of the original Pocket, and because of the camera's dual gain sensor and dramatically better low light performance. Plus better codec (IMHO), much better battery life and much better display.

sorry, I meant: as you would do in a debayered image (can no longer edit my posting above) @paulinventome, you wrote: The point is that a Bayer sensor doesn't have RGB layers (a Foveon sensor does!), but RGGB pixel patterns, as posted above.

Just to make the matter less abstract, the problem of scaling a 6K Bayer pattern into a 4K Bayer pattern is that this... ...needs to be turned into this: Which is only possible with weird interpolations. Or, on a larger scale, if you have 3x3 of the above four pixel groups.... ....how to scale them into 2x2: However you do it, it will result in weirdness, since you're not actually interpolating adjacent color values (as you would do in an undebayered image).

Why scaled down to 3000x2000/3K Bayer (i.e. exactly 50%)? The issue of the Sigma fp is that it scales 6K Bayer to 4K Bayer, i.e. onto a non-matching matrix (simulating a smaller Bayer sensor that doesn't actually exist), which by definition must involve some weird interpolation/shifting of RGGB values. Which IMHO also explains the artifacts in 4K CinemaDNG.

Since the forum won't me let upload it, here's an external link.

I did. It's the 24MP still above (24MP = 6K, just edited the captions to clarify).

So I just did that - but I had no resolution chart at hand, but used a fine-pattern silver synthetic fabric to provoke moiré in the camera. With the Sigma 45mm/2.8, I did two shots, both at f8 and 11 degree shutter: - one UltraHD CinemaDNG shot; - one 24MP still DNG shot. I processed both in RawTherapee (but without False Color suppression filter): 6K (24MP) still DNG 4K (12MP) CinemaDNG The difference becomes already visible here, but for 1:1 comparison, I opened the 24MP still in The Gimp, scaled it to 3840 horizontal pixel (using cubic scale) and cropped it from 3:2 to 16:9 aspect ratio: still DNG, scaled & cropped to 4K 3840x2160 Now let's compare the 4K still DNG and the 4K CinemaDNG in a 1:1 center crop: CinemaDNG still DNG, downsampled to 4K While there's visible moiré also on the still DNG, the result in 4K CinemaDNG is much worse, very obviously because of a problematic scaling method. (Scaling an undebayered 6K/24MP Bayer matrix into an undebayerd 4K/12MP Bayer matrix, and probably not using the best algorithm for that.) The result is both an excessive pronunciation of moiré and (compared to the downscaled 6K) a blurry image - much like in the good' old Canon video DSLR times... One more test: center crop from the still DNG, this time downscaled in the Gimp from 6K to 4K without any pixel downsampling, but with line skipping ("Interpolation off") - still DNG, line-skipped from 6K to 4K Moiré is more pronounced than in the downsampled still, but still not as bad as in the CinemaDNG. So I really suspect the culprit in the transformation of the undebayered 6K to undebayered 4K, probably through crude line skipping/heuristics.

I processed the first frame with Resolve and with Rawtherapee (which includes very fine-grained, expert debayering controls). When tuning the debayering in Rawtherapee, choosing AMaZE as the demosaicing algorithm with 'border' set to 4 and 'False color suppression steps' set to 5, the result is visibly better than from Resolve, but still far from perfect - see the attached frame grabs: Rawtherapee Resolve

The German video site Slashcam just ran a new test for using run-of-the-mill SATA SSDs in USB 3.1 enclosures as recording media with the fp: https://www.slashcam.de/artikel/Kurztest/slashCHECK---Nachgereicht---Guenstige-SATA-SSDs-an-der-Sigma-fp-Teil-2.html A test they had conducted earlier did fail, but it turns out that you need an enclosure that supports USB-C 3.1 Gen 2 with, most importantly, the USAP protocol (USB Attached SCSI Protocol). The enclosure they tested, and which meets these standards, is the UGREEN 2.5" USB-C 3.1 Gen 2: Turns out that an older Sandisk SanDisk Ultra II 960GB, while performing slightly worse in that housing than the Samsung T5, recorded 4K RAW with the Sigma fp without any trouble or disruption. So this might be a budget tip for the camera.