# Magic Lantern Forum

## Using Magic Lantern => Post-processing Workflow => Topic started by: katrikura on February 22, 2017, 12:17:51 PM

Post by: katrikura on February 22, 2017, 12:17:51 PM
Hello:
Any member of the magic lantern community has used Fast CinemaDNG?

On the website of the manufacturer says: The software is also compatible with Canon 5D Mark III camera with Magic Lantern firmware after MLV to CinemaDNG transform.
Post by: viikossi on February 22, 2017, 02:31:34 PM
Working well with canon 7d using cDNG

Sent from my Xperia SP using Tapatalk

Post by: Walter Schulz on February 22, 2017, 04:22:02 PM
Post by: reddeercity on February 23, 2017, 05:26:58 AM
Quote
Fast CinemaDNG Processor application allows to view DNG image series recorded with video and photo cameras.
The software can do standard image processing of RAW DNG and CinemaDNG files on NVIDIA GPU in realtime.
We currently support the following DNG (RAW) formats and compression options:
 Uncompressed DNG.
 DNG with lossless compression. It has zero loss of detail, but quite small compression, just around
35% file size reduction for very blurry / underexposed / overexposed images ranging to around 25%
file size reduction for well focused, well exposed, detailed images.
 BMD RAW 3:1 compressed lossy DNG. Some image detail are lost, but not much. The compression is
usually rate controlled to 3:1, so recording capacities of media are very predictable.
 BMD RAW 4:1 compressed lossy DNG. This is the same as 3:1, but with better compression. The
quality is still good, but not as good as 3:1.

The following 3 modes (three DNG formats) are currently offered with BlackMagic URSA:
 Losslessly Compressed RAW
 Visually Lossless 3:1 RAW (lossy)
 Visually Lossless 4:1 RAW (lossy)

Very interesting App , Wins only looks like and in beta so free , Like Beer  :P
It's basically a Grading app for dallies or what ever on Raw Cdng Uses Cuda real time noise reduction !
Very nice   8)  you can grade your MLV Raw and export as Cdng's !!

Quote
DNG export tab contains parameter, used to render project into DNG. Currently only compression and crop are supported.
Supported compression algorythms are:program directory.
Use original. In this mode project files are simply copyed despite of crop settings
Lossless JPEG. In this mode raw data are compressed with losseless jpeg algorythm.
BMD RAW 3:1. In this mode raw data are compressed with lossy BMD RAW 3:1 algorythm, designed byBlackmagic Design.
BMD RAW 4:1. In this mode raw data are compressed with lossy BMD RAW 4:1 algorythm, designed byBlackmagic Design
BMD RAW 5:1. In this mode raw data are compressed with lossy BMD RAW 5:1 algorythm, designed byBlackmagic Design

I did a quick test with 12 bit mlv+audio from MLVFS quick mount with fuse . Seem to work OK and debayed correctly.
Lots of camera raw adjusts to work with , Does take a fairly beefy machine to run
Tested on my over clock FX8350 (4.9 ghz) on dual GTX 580 cards 3GB Vram with 8TB Raid "0" OS on SSD
It seems to labour a little thou my Vid card are really out dated , there recommend at least "GTX 980TI, 1080 or Tesla K40 GPU memory 4-12 GB"
You also have a option for Working Color Space , e.g. sRGB , Adobe , etc... lots of professional stuff
So it seems it's was intended for Blackmagic Camera up to 8K , I highly recommend trying this out even if it's to convert your ML Cdng's to BDM raw3:1 to save space
plus you can have a grade applied or just leave in film log space , exports with FFmpeg , Cdng's , Tiff  . I Can see this app costing big  later down the road .
So don't loose out .

Edit:
I tested the compressed .dng export , original cdng from mlvfs was 1856x1044 3.75MB & the compressed dng is 1.29MB used the lossless jpeg compression
I can't tell the difference , here a link to each dng frame from my dropbox .
lossless_jpeg.dng (https://www.dropbox.com/s/09a1wif0oymfc25/M18-0120_000000_lossless_jpeg.dng?dl=0)    original ml dng (https://www.dropbox.com/s/1fmwdz8k500mlcl/M18-0120_000000.dng?dl=0)
Also tried 3:1 which gave me a frame size of 133KB
The only thing I see there's no frame rate tag but all other tag are pass though ,
exiftool tell me the 3:1 is 12bit with jpeg compression and the lossless is 16bits with jpeg compression and there again no frame rate tag .
Post by: megapolis on February 23, 2017, 09:05:19 AM
Quote
So it seems it's was intended for Blackmagic Camera up to 8K, I highly recommend trying this out even if it's to convert your ML Cdng's to BDM raw 3:1 to save space
We don't have any 8K source CinemaDNG images yet, currently it's working well with 4.6K BMD. The software is intended to work not only with image series from Blackmagic cameras but also with any CinemaDNG images. If something goes wrong with your CinemaDNG, please send these images to me.
It's not correct that the software is always converting your ML CDNG images to BMD RAW 3:1. You can choose lossless compression for any data source, even if it was originally BMD RAW 3:1 or 4:1.

NVIDIA GeForce GTX 580 is ok for image resolutions up to Full HD. For higher resolutions you will need more powerful GPU. If the player is working smoothly, it means that your CPU, GPU and SSD are ok.

There are some important issues which you have not mentioned:
1. One can play your CinemaDNG series from Windows Explorer. Just click right button on the folder and choose Fast CinemaDNG in the list. By pressing Tab you can run viewer at full screen mode.
2. Project culling by choosing starting and finishing points at the timeline.
3. One can crop and save DNG to reduce image size of RAW data.

Quote
Also tried 3:1 which gave me a frame size of 133KB
I agree that the image could be too much compressed and it could be a good idea to add a function for arbitrary compression ratio instead.

Quote
The only thing I see there's no frame rate tag
Yes, we've missed that, thanks for pointing out. This is our mistake and we will fix that soon. We are also going to add some more CDNG editing to the software. Our users are mostly asking us to add 1D LUT and denoising preprocessing features (both before debayering) with intention to save DNG for further processing.

Please have a look at Debayer options. Our latest debayer with MG algorithm is a recent improvement and we would be interested to get your feedback concerning debayer quality. You can zoom still image or video to see all details.

P.S. This year we are going to add support of MLV format to work directly with MLV files, without doing any preliminary MLV-CDNG conversion. Thanks to g3gg0, we've got necessary info.
Post by: katrikura on February 23, 2017, 11:50:49 AM
Thank you for sharing this information, proceed to test the software.

Katrikura
Post by: andy kh on February 23, 2017, 11:54:07 AM

P.S. This year we are going to add support of MLV format to work directly with MLV files, without doing any preliminary MLV-CDNG conversion. Thanks to g3gg0, we've got necessary info.
[/quote]

Wow!! Sounds great
Post by: DeafEyeJedi on February 23, 2017, 04:48:21 PM
...This year we are going to add support of MLV format to work directly with MLV files, without doing any preliminary MLV-CDNG conversion. Thanks to g3gg0, we've got necessary info.

+10 and big thanks to @g3gg0!
Post by: Lars Steenhoff on February 23, 2017, 05:52:42 PM
Cool stuff!  Mac version possible?
Post by: megapolis on February 23, 2017, 06:39:04 PM
Quote
Mac version possible?
In the core of Fast CinemaDNG software we have our own image processing SDK which is working on NVIDIA CUDA. Apart from DNG/CinemaDNG decoding we do almost everything on GPU. We believe that GPU could offer the fastest way of image processing and we do need that to insure realtime performance for 4K and higher resolutions. You can check the content of that SDK and have a look at performance benchmarks: http://www.fastcompression.com/products/sdk/sdk.htm

So we are working with NVIDIA GPUs only and unfortunately at the moment Apple doesn't manufacture any PC/laptop with NVIDIA GPUs, they install AMD/Intel only. This is the main obstacle. Our image processing SDK can work with Windows and Linux, and we can port it to MacOS as well, but our users don't have right hardware to work with. So we are waiting for good news from Apple.
Post by: Lars Steenhoff on February 23, 2017, 08:08:50 PM
My mac is quite capable :) and with CUDA
but yea I understand apple has left nvida behind.
that the main reason I don't want to upgrade to a newer mac.

I could install windows and try out the app. it seems really nice.
Post by: DeafEyeJedi on February 24, 2017, 05:57:56 AM
Tried running this on OS X 10.12.3 under Wine and got up to the point where it's 80% installed this error pops up...

(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fc1.staticflickr.com%2F3%2F2911%2F33040932516_41aa4aa730.jpg&hash=940eb14abd5f277208aba978151a012c) (https://flic.kr/p/SkHq7h)

Here are some logs in case they give out hints? Maybe I need to install one more tweak within Wine under Tools advance settings?

Code: [Select]
fixme:module:load_library unsupported flag(s) used (flags: 0x00000800)fixme:system:SetProcessDPIAware stub!fixme:ver:GetCurrentPackageId (0x33f934 0x0): stubfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshotfixme:toolhelp:Heap32ListFirst : stubfixme:nls:get_dummy_preferred_ui_language (0x8 0x33f9c0 0x33f9e4 0x33f9b8) returning a dummy value (current locale)fixme:file:FindFirstFileExW flags not implemented 0x00000002fixme:explorerframe:taskbar_list_SetProgressValue iface 0x1802cf8, hwnd 0x1006e, ullCompleted 64, ullTotal 64 stub!fixme:explorerframe:taskbar_list_SetProgressState iface 0x1802cf8, hwnd 0x1006e, flags 0 stub!fixme:explorerframe:taskbar_list_SetOverlayIcon iface 0x1802cf8, hwnd 0x1006e, hIcon 0x0, pszDescription (null) stub!fixme:nls:get_dummy_preferred_ui_language (0x8 0x33c80c 0x33c830 0x33c804) returning a dummy value (current locale)fixme:nls:get_dummy_preferred_ui_language (0x8 0x33c80c 0x33c830 0x33c804) returning a dummy value (current locale)fixme:file:FindFirstFileExW flags not implemented 0x00000002fixme:nls:get_dummy_preferred_ui_language (0x8 0x33c988 0x33c9ac 0x33c980) returning a dummy value (current locale)fixme:nls:get_dummy_preferred_ui_language (0x8 0x33c948 0x33c96c 0x33c940) returning a dummy value (current locale)fixme:commdlg:IServiceProvider_fnQueryService Interface {e07010ec-bc17-44c0-97b0-46c7c95b9edc} requested from unknown service {e07010ec-bc17-44c0-97b0-46c7c95b9edc}fixme:shell:ViewModeToListStyle ViewMode 0 not implementedfixme:shell:IShellBrowser_fnSendControlMsg stub, 0x193e2a0 (2, 1026, a003, 0, 0x33ba4c)fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x193e2a0 (2, 1026, a004, 0, 0x33ba4c)fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x193e2a0 (2, 1025, a003, 1, 0x33ba4c)fixme:shell:IShellBrowser_fnSendControlMsg stub, 0x193e2a0 (2, 1025, a004, 1, 0x33ba4c)fixme:nstc:NSTC2_fnSetControlStyle2 mask & style (0x00000004) contains unsupported style(s): 0x00000004fixme:win:FlashWindowEx 0x33b6bc - semi-stubfixme:win:FlashWindowEx 0x33c05c - semi-stubfixme:explorerframe:taskbar_list_SetOverlayIcon iface 0x1823068, hwnd 0x1006e, hIcon 0x0, pszDescription (null) stub!err:ole:CoCreateInstanceEx apartment not initialisederr:ole:CoCreateInstanceEx apartment not initialisederr:ole:CoCreateInstanceEx apartment not initialisederr:ole:CoCreateInstanceEx apartment not initialisederr:ole:CoCreateInstanceEx apartment not initialisederr:ole:CoCreateInstanceEx apartment not initialisedfixme:wscript:set_host_properties ignored L"nologo" switchfixme:vbscript:VBScript_SetScriptState unimplemented SCRIPTSTATE_INITIALIZEDfixme:scrrun:filesys_MoveFile 0x45f33cb0 L"C:\\Program Files\\FastCinemaDNG\\maintenancetool.dat.new" L"C:\\Program Files\\FastCinemaDNG\\maintenancetool.dat"fixme:wscript:set_host_properties ignored L"nologo" switchfixme:vbscript:VBScript_SetScriptState unimplemented SCRIPTSTATE_INITIALIZEDfixme:scrrun:filesys_MoveFile 0x455d4cb0 L"C:\\Program Files\\FastCinemaDNG\\maintenancetool.exe.new" L"C:\\Program Files\\FastCinemaDNG\\maintenancetool.exe"winedevice.exe(3731,0x401fb000) malloc: *** error for object 0x79be8dff: pointer being freed was not allocated*** set a breakpoint in malloc_error_break to debug
Code: [Select]
WineskinX11: main(): argc=12Waiting for startup parameters via Mach IPC.WineskinX11: do_start_x11_server(): argc=12Attempting to use pixel depth of 24[1853071.006] WineskinX11 starting:[1853071.006] X.Org X Server 1.13.0[1853071.006] Build Date: 20120921[1853071.006] _XSERVTransmkdir: ERROR: euid != 0,directory /tmp/.X11-unix will not be created.[1853071.008] Initializing built-in extension Generic Event Extension[1853071.008] Initializing built-in extension SHAPE[1853071.008] Initializing built-in extension MIT-SHM[1853071.008] Initializing built-in extension XInputExtension[1853071.008] Initializing built-in extension XTEST[1853071.008] Initializing built-in extension BIG-REQUESTS[1853071.008] Initializing built-in extension SYNC[1853071.008] Initializing built-in extension XKEYBOARD[1853071.008] Initializing built-in extension XC-MISC[1853071.008] Initializing built-in extension XINERAMA[1853071.008] Initializing built-in extension PseudoramiX[1853071.008] Initializing built-in extension XFIXES[1853071.008] Initializing built-in extension RENDER[1853071.008] Initializing built-in extension RANDR[1853071.008] Initializing built-in extension DAMAGE[1853071.008] Initializing built-in extension MIT-SCREEN-SAVER[1853071.008] Initializing built-in extension DOUBLE-BUFFER[1853071.008] Initializing built-in extension RECORD[1853071.008] Initializing built-in extension X-Resource[1853071.008] Initializing built-in extension XVideo[1853071.008] Initializing built-in extension XVideo-MotionCompensation[1853071.008] Initializing built-in extension GLX[1853071.008] x: 0, y: 0, w: 2560, h: 1417[1853071.021] (II) GLX: Initialized Core OpenGL GL provider for screen 0[1853071.021] [dix] Could not init font path element /opt/X11/share/fonts/75dpi, removing from list![1853071.021] [dix] Could not init font path element /opt/X11/share/fonts/100dpi, removing from list![1853071.021] [dix] Could not init font path element /opt/X11/share/fonts/cyrillic, removing from list![1853071.021] [dix] Could not init font path element /opt/X11/share/fonts/misc, removing from list![1853071.021] [dix] Could not init font path element /opt/X11/share/fonts/OTF, removing from list![1853071.021] [dix] Could not init font path element /opt/X11/share/fonts/Speedo, removing from list![1853071.022] [dix] Could not init font path element /opt/X11/share/fonts/TTF, removing from list![1853071.022] [dix] Could not init font path element /opt/X11/share/fonts/Type1, removing from list![1853071.022] [dix] Could not init font path element /opt/X11/share/fonts/util, removing from list![1853071.123] noPseudoramiXExtension=0, pseudoramiXNumScreens=1Engine Used: WS9Wine2.2Hardware:    Hardware Overview:      Model Name: Mac mini      Model Identifier: Macmini6,2      Processor Name: Intel Core i7      Processor Speed: 2.3 GHz      Number of Processors: 1      Total Number of Cores: 4      L2 Cache (per Core): 256 KB      L3 Cache: 6 MB      Memory: 16 GB      Boot ROM Version: MM61.0106.B0B      SMC Version (system): 2.8f1Graphics/Displays:    Intel HD Graphics 4000:      Chipset Model: Intel HD Graphics 4000      Type: GPU      Bus: Built-In      VRAM (Dynamic, Max): 1536 MB      Vendor: Intel (0x8086)      Device ID: 0x0166      Revision ID: 0x0009      Metal: Supported      Displays:        DELL U2713HM:          Resolution: 2560 x 1440 @ 59 Hz          Pixel Depth: 32-Bit Color (ARGB8888)          Display Serial Number: 7JNY5396175L          Main Display: Yes          Mirror: Off          Online: Yes          Rotation: Supported          Automatically Adjust Brightness: No          Connection Type: DisplayPort          Television: Yes
Post by: reddeercity on February 24, 2017, 07:16:27 AM
You need
Quote
NVIDIA GPU (Fermi, Kepler, Maxwell or Pascal) installed to run the software on GPU.
Post by: megapolis on February 24, 2017, 07:53:22 AM
Quote
Tried running this on OS X 10.12.3 under Wine and got up to the point where it's 80% installed this error pops up...

Unfortunately we haven't tested the setup on OS X under Wine yet. We will definitely check that soon. The message says that one can't register dll which is responsible for context menu in Windows Explorer. We've already seen such a situation and in all cases Windows was corrupted.

Haven't seen any NVIDIA GPU in your hardware. The software can't work with Intel built-in GPU (Intel HD Graphics 4000).
Post by: masc on February 24, 2017, 11:34:16 AM
@DeafEyeJedi: I also tried to run it on Wine. When did the message came up? On install? Or on run? Since the new Wine 2.0 64bit on OSX is supported (with some bugs).
I got it installed 100%. But on run I got an error which tells me about a 64bit problem... maybe some settings were wrong?!
Post by: DeafEyeJedi on February 24, 2017, 08:04:27 PM
@masc -- I ran Wineskin-2.6.2 (WS9Wine2.2) and the only tweak I added was vb6run under Winetrick within Advance settings.

The error (screenshot above) showed up as I was about 80% installed (then I clicked on ignore error) which then finished the installation but then it won't run for some reason. Did I miss a step for this particular app to work under Wine besides the 64-bit bug?
Post by: reddeercity on February 24, 2017, 10:18:55 PM
@megapolis can Fast CinemaDng use multiply GPU's ,  2 or more (I have 2 gtx580 installed)
It seem I can choice either but not both .
Also do you or will you have support for a Capture/Playback card/device for monitoring on a external calibrated Grading HDMI & or HDSDI monitor ?
Since to have already integrated some blackmagic stuff maybe have support for there USB 3.0 device "UltraStudio SDI" has HDMI & HDSDI playback/output
and or any of the  blackmagic PCIe capture cards
I use my USB 3.0 device cross platform PC/MAC would be icing on top of the cake  ;)
Post by: megapolis on February 25, 2017, 09:40:47 AM
@reddeercity
Quote
@megapolis can Fast CinemaDng use multiply GPU's, 2 or more (I have 2 gtx580 installed)
Current version of Fast CinemaDNG is working with just one GPU, though our core SDK can work with multiple NVIDIA GPUs as well. We think that for resolutions like 2K and 2.5K, one GPU should be enough for full image processing in realtime. 4K and 4.6K resolutions could be processed on just one GPU GeForce GTX 1070 or 1080. We are still working on optimization issues for CPU/GPU, and final solution should be faster.

We plan to use the second GPU for more complicated denoising or for JPEG2000 encoding and decoding (instead of ProRes or DNxHD/HR). These algorithms need a lot of computations and GPU memory, and it's difficult to incorporate them into existing pipeline on the first GPU in realtime.

Quote
Also do you or will you have support for a Capture/Playback card/device for monitoring on a external calibrated Grading HDMI & or HDSDI monitor?
At the moment we support just one monitor which is connected to the same GPU. We take into account ICC-profile of the monitor and you can define corresponding profile in the software settings. We do that color correction on CUDA and send processed data to the monitor.
You can work with multiple monitors, which are connected to the same GPU, but the software will take into account just one ICC profile.
We are also considering a task of 10-bit monitor support, but at the moment NVIDIA is offering that feature only for the latest Quadro GPUs, which are quite expensive.

Quote
Since to have already integrated some blackmagic stuff maybe have support for there USB 3.0 device "UltraStudio SDI" has HDMI & HDSDI playback/output and or any of the blackmagic PCIe capture cards
In order to support any external USB3 device, we need developer kit and API to work with such a device. At the moment we don't have that.
As far as concerns Blackmagic PCIe capture cards, we have such an experience and we can use them as input to offer realtime image acquisition and processing. That feature is not yet released and if you need it, please specify the task in more detail.
Post by: masc on February 25, 2017, 11:14:36 AM
@DeafEyeJedi: Ok, I used exactly the same. I only did not try the vb6run. But I had no error durring installation.
Bug maybe the wrong word:
https://www.winehq.org/wwn/364#Wine64%20on%20Mac%20OS%20X (https://www.winehq.org/wwn/364#Wine64%20on%20Mac%20OS%20X)
and
https://wiki.winehq.org/FAQ (https://wiki.winehq.org/FAQ), point 2.6
Post by: megapolis on March 02, 2017, 03:17:42 PM
@reddeercity: We've fixed the issue with framerate tag, now it's working. Please check that once more.

In the latest release we've added two significant improvements for CinemaDNG processing:

1. For all demosaicing algorithms we've added “Enhance level” option and this improvement removed many debayer artifacts that we used to have. To compare with our previous debayer versions, you can set “Enhance level” = 1. That value is individual for each image and it's up to you what to choose. Actually we've added some more image processing stages before and after debayering to get the result.

Please test that software and share your experience with us. We would be interested to find out your results of comparison with demosaicing algorithms from ML, Davinci Resolve, Adobe Premiere Pro, ACR, Lightroom, etc.

2. We've improved Lossless JPEG decoder on CPU. This is one of the most important bottlenecks to overcome, before we could get smooth output in Player window. As soon as we don't use proxies and do all image processing for full-frame images, this is not simple, especially for 4K and 4.6K resolutions.

With new decoder on PC with NVIDIA GeForce GTX 1080 and CPU Intel Core i7 5930 we can process CinemaDNG footage with 4.6К resolution smoothly, with full image processing pipeline, including MG debayer, denoiser and unsharp mask.
Post by: reddeercity on March 03, 2017, 02:34:32 AM
@megapolis thanks for the update , Yes I can confirm the frame rate tag is back
I did notice the compressed Cdng from fastcdng changed the exposure tag , from 1/53  to 1/50
plus the light value was changed from 7.1 to 7.0 , I don't think that would cause any problems .
I haven't had time to fully check out all the changes yet , will do a.s.a.p.
below is the orginal Cdng from MLVFS and the exiftool info
https://www.dropbox.com/s/sqmgd2sif8vwyw4/M18-0120_000000_O.dng?dl=0
Code: [Select]
ExifTool Version Number         : 10.33File Name                       : M18-0120_000000.dngDirectory                       : D:/Window7_Downloads Saves/exiftool-10.33/NewfolderFile Size                       : 3.8 MBFile Modification Date/Time     : 2017:02:18 01:19:46-07:00File Access Date/Time           : 2017:03:02 17:13:26-07:00File Creation Date/Time         : 2017:03:02 17:13:26-07:00File Permissions                : rw-rw-rw-File Type                       : DNGFile Type Extension             : dngMIME Type                       : image/x-adobe-dngExif Byte Order                 : Little-endian (Intel, II)Subfile Type                    : Full-resolution ImageImage Width                     : 1856Image Height                    : 1044Bits Per Sample                 : 16Compression                     : UncompressedPhotometric Interpretation      : Color Filter ArrayFill Order                      : NormalMake                            : CanonCamera Model Name               : Canon EOS 5D Mark IIStrip Offsets                   : 65536Orientation                     : Horizontal (normal)Samples Per Pixel               : 1Rows Per Strip                  : 1044Strip Byte Counts               : 3875328Planar Configuration            : ChunkySoftware                        : MLVFSModify Date                     : 2017:01:18 01:19:46CFA Repeat Pattern Dim          : 2 2CFA Pattern 2                   : 0 1 1 2Exposure Time                   : 1/53F Number                        : 4.5ISO                             : 800Sensitivity Type                : ISO SpeedExif Version                    : 0230Subject Distance                : 107 mFocal Length                    : 57.0 mmLens Model                      : EF24-70mm f/2.8L USMDNG Version                     : 1.4.0.0Unique Camera Model             : Canon EOS 5D Mark IILinearization Table             : (Binary data 19364 bytes, use -b option to extract)Black Level                     : 448White Level                     : 3750Default Crop Origin             : 0 0Default Crop Size               : 1856 1044Color Matrix 1                  : 0.4716 0.0603 -0.083 -0.7798 1.5474 0.248 -0.1496 0.1937 0.6651As Shot Neutral                 : 0.4642547087 1 0.5671705788Baseline Exposure               : 0Calibration Illuminant 1        : D65Active Area                     : 0 0 1044 1856Frame Rate                      : 23.976Baseline Exposure Offset        : 0Aperture                        : 4.5CFA Pattern                     : [Red,Green][Green,Blue]Image Size                      : 1856x1044Megapixels                      : 1.9Shutter Speed                   : 1/53Focal Length                    : 57.0 mmLight Value                     : 7.1
Compressed Cdng from FastCdng with exiftool info

Code: [Select]
ExifTool Version Number         : 10.33File Name                       : M18-0120_000000 (2).dngDirectory                       : D:/Window7_Downloads Saves/exiftool-10.33/NewfolderFile Size                       : 1328 kBFile Modification Date/Time     : 2017:03:02 17:24:16-07:00File Access Date/Time           : 2017:03:02 17:26:18-07:00File Creation Date/Time         : 2017:03:02 17:26:18-07:00File Permissions                : rw-rw-rw-File Type                       : DNGFile Type Extension             : dngMIME Type                       : image/x-adobe-dngExif Byte Order                 : Little-endian (Intel, II)Subfile Type                    : Full-resolution ImageImage Width                     : 1856Image Height                    : 1044Bits Per Sample                 : 16Compression                     : JPEGPhotometric Interpretation      : Color Filter ArrayMake                            : CanonCamera Model Name               : Canon EOS 5D Mark IIOrientation                     : Horizontal (normal)Samples Per Pixel               : 1Planar Configuration            : ChunkySoftware                        : MLVFSModify Date                     : 2017:01:18 01:19:46Tile Width                      : 464Tile Length                     : 522Tile Offsets                    : (Binary data 55 bytes, use -b option to extract)Tile Byte Counts                : (Binary data 55 bytes, use -b option to extract)CFA Repeat Pattern Dim          : 2 2CFA Pattern 2                   : 0 1 1 2Exposure Time                   : 1/50F Number                        : 4.5ISO                             : 800Sensitivity Type                : ISO SpeedExif Version                    : 0230Shutter Speed Value             : 1/50Aperture Value                  : 4.5Subject Distance                : 107 mFocal Length                    : 57.0 mmLens Model                      : EF24-70mm f/2.8L USMDNG Version                     : 1.4.0.0DNG Backward Version            : 1.1.0.0Unique Camera Model             : Canon EOS 5D Mark IICFA Plane Color                 : Red,Green,BlueCFA Layout                      : RectangularLinearization Table             : (Binary data 19364 bytes, use -b option to extract)Black Level Repeat Dim          : 1 1Black Level                     : 448White Level                     : 3750Default Scale                   : 1 1Default Crop Origin             : 0 0Default Crop Size               : 1856 1044Color Matrix 1                  : 0.4716 0.0603 -0.083 -0.7798 1.5474 0.248 -0.1496 0.1937 0.6651Analog Balance                  : 1 1 1As Shot Neutral                 : 0.464255 1 0.567171Baseline Exposure               : 0Baseline Noise                  : 1Baseline Sharpness              : 1Bayer Green Split               : 0Linear Response Limit           : 1Anti Alias Strength             : 1Shadow Scale                    : 1Calibration Illuminant 1        : D65Best Quality Scale              : 1Raw Data Unique ID              : 41D88194533B26B6F0D77FDC99B5C141Active Area                     : 0 0 1044 1856Profile Name                    : EmbeddedProfile Embed Policy            : Allow CopyingFrame Rate                      : 23.976New Raw Image Digest            : b2735ab08d8d3d9ead368696f0fb7d6fAperture                        : 4.5CFA Pattern                     : [Red,Green][Green,Blue]Image Size                      : 1856x1044Megapixels                      : 1.9Shutter Speed                   : 1/50Focal Length                    : 57.0 mmLight Value                     : 7.0-- press RETURN --

Post by: megapolis on March 03, 2017, 12:45:01 PM
@reddeercity: We've checked the issue with Exposure Time and have found that it's changed by a function from Adobe DNG SDK. Actually the software has found right value for Exposure Time in the original DNG and then compared it with predefined list of values. The closest one to 53 is 50, so 1/53 was switched to 1/50. Sure, we can fix that function, but there is a question. Does exist Exposure Time 1/53 s at your camera?

P.S. Please have a look at debayer quality for MG algorithm with enhance option.
Post by: hyalinejim on March 03, 2017, 07:16:30 PM
It seems good from what I briefly saw of it, "enhance" seems to reduce aliasing, but not as good as ACR with Cinelog, nor is the highlight reconstruction as good:

Sharpening and noise reduction is not working for me in the new version. I cannot change the sliders, even with the demo project. And I cannot find the export window.

(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fs17.postimg.org%2Fm4fczdl8f%2Fimage.jpg&hash=2622573ce3be83317656852e405c9586)
Post by: megapolis on March 03, 2017, 08:04:19 PM
@hyalinejim: In order to be able to work with weak GPUs with 1-1.5 GB memory, we've implemented image processing pipeline manager. This is the way to exclude some image processing stages from the pipeline. You need to run the software without loading any project (or you can close current project) and click on Options button, then go to “Output and Extensions” tab. You will see there denoising, sharpening and other options for image processing which are excluded from the pipeline. Check necessary modules and try to open new project. If you have enough GPU memory, it should work. To get the same colors as ACR, please try both RGB and HSV LUTs as well. Manual in PDF you can find at the same folder as the software.
Usually we set "Enhance level" around 2.5-3.0 or even less. I think that 5 is often too much.
Post by: hyalinejim on March 03, 2017, 10:30:10 PM
Thanks megapolis for your quick reply! Your suggestions worked to re-enable parts of the interface. Here is a link to the DNG file:

It was shot in anamorphic, so it is laterally distorted. It's an interesting image as the candle flame will show aliasing artifacts typical of the 5D as sharpness is increased. Otherwise, the sharpening is very good indeed.

However, panel docking is not working well.
Post by: megapolis on March 04, 2017, 04:07:36 PM
I agree with you, but please note that for that specific image the job was done due to Cinelog camera profile which removed the problem with highlights in red on arms and candle flame. We see the only solution here – to process red channel with a curve before debayering.

Here you can see an example of processing with Fast CinemaDNG:
Everything was set to its default value, we just reduced Red channel down (it's applied before debayer) and changed R curve to avoid highlights crashing in R channel. RGB Parade would help you in making proper settings.

We expect to release some features for solving such problems (3D LUT support, highlights recovery, DCP profiles support, LUTs for RAW data) within 2-3 months and we will check your image after that once more.

I also agree that panel docking is not working well. We got that module from QT and it seems to be not the best choice.
Post by: hyalinejim on March 04, 2017, 09:43:35 PM
That sounds awesome - particularly DCP support!
Post by: megapolis on March 16, 2017, 11:37:31 AM
@hyalinejim: Thanks again for your image and your question. I've checked your image and your solution once more and I can see the following:

You've solved the problem by applying Cinelog DCP profile for Canon 5D. Inside that profile one can see ToneCurve (log-like gamma) and HSV 3DLUT. It means that in Adobe ACR the task of Highlights Recovery was solved after debayering by applying gamma to RGB and 3D LUT to HSV. That solution makes sense and we see good result. We will be able to utilize that method, as soon as we add DCP support to our software in the near future. Anyway, there is also another possible solution.

One can do Highlights Recovery before debayering and it seems to be a better approach. If we remove highlights before debayer, then image quality after debayering will be better because this is the way to avoid interpolations with clipped pixels. We've added to Fast CinemaDNG software widget “Raw Curve” to be able to apply curves to RAW data before debayering. There is a master curve which is always applied to all three channels of RAW data, and individual curves for each color channel.

Here you can have a look at your image which is processed with curves before debayering:

What Fast CinemaDNG software is doing before demosaicing:
1. Multithreaded reading and parcing of all DNGs in the current folder
2. Multithreaded DNG decoding for compressed data
3. Data copy from CPU to GPU (host to device transfer)
4. DNG crop
5. Data linearization according to 1D LUT from DNG
6. Black and white points from DNG
7. WB coefficients for R, G, B
8. Exposure correction
9. Composite raw curve (the same curve for all three channels)
10.  Individual curve for each raw channel
11.  Raw bayer denoiser
12.  Debayer HQLI, DFPD or MG with Enhance option

All these stages from image processing pipeline one can see at Benchmarks widget to check timing on GPU for each stage. To get fast result, we need to have powerful CPU, GPU and SSD.

Post by: hyalinejim on March 16, 2017, 11:20:25 PM
@megapolis

I'm away for a few weeks but will check it out on my return looks good from the image you posted!
Post by: megapolis on April 27, 2017, 01:03:29 PM
@hyalinejim: In the latest release of Fast CinemaDNG Processor software we've implemented support for external DCP profiles. Now it's possible to utilize any DCP profile from Adobe ACR, RawTherapee, Cinelog, etc. User can create his own DCP profile with any profiler and then add it to the current project. All computations for 1D and 3D LUTs from DCP are done on GPU in real time. Timing for each stage of DNG image processing on GPU is shown in the Benchmark window.

We've also added check boxes for GUI to switch on/off  Hue/Saturation Map, LookTable and Tone Curve to see what we can really get from DCP profile. Default path for a folder with DCP profiles are defined at Options section.

Post by: Andy600 on April 27, 2017, 02:05:40 PM
@megapolis - I'm not sure where you got your Cinelog profile(s) from? - but Cinelog-C profiles don't contain HSV luts and they will only work correctly in Adobe Camera Raw.
Post by: hyalinejim on April 27, 2017, 02:27:00 PM
Hi megapolis, I've added my Cinelog DCP profile to the folder as you suggest, but all it seems to do is change the saturation:

(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fs2.postimg.org%2F8n2lpo1a1%2Fnew_01.jpg&hash=f3875dd7508f68a83501101e9fe03001)

Here is what it looks like in ACR:

(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fs2.postimg.org%2F5u9e5n0xl%2Fnew_02.jpg&hash=9fef9462da0337890730f42b3c68cf03)
Post by: Andy600 on April 27, 2017, 02:58:44 PM
Even though you can read/apply Cinelog profiles in RawTherapee or other apps they will only produce Cinelog-C colorspace in Adobe Camera Raw because the profiles contain compensation for a limitation that is unique to ACR when it is used in conjunction with After Effects. Using the profiles in any other raw app (i.e. raw apps without that limitation i.e. any raw app that isn't ACR) you will be introducing a new issue.

I'm not sure why you would even want to use a fixed colorspace management DCP anyway as your app is built on GPU accelerated shaders!?
Post by: Lars Steenhoff on April 27, 2017, 06:10:55 PM
Its free and gpu accelerated, will have to give it a try
Post by: DeafEyeJedi on April 27, 2017, 06:24:27 PM
@megapolis - I'm not sure where you got your Cinelog profile(s) from?

I question this as well?
Post by: megapolis on April 28, 2017, 09:38:18 AM
Quote
I'm not sure where you got your Cinelog profile(s) from? - but Cinelog-C profiles don't contain HSV luts and they will only work correctly in Adobe Camera Raw.
Thanks, I will check that. I tested profiles from ACR and RT. Cinelog profile was tested by our customer. If it doesn't work, I will definitely remove it from the list of supported profiles.

Quote
Even though you can read/apply Cinelog profiles in RawTherapee or other apps they will only produce Cinelog-C colorspace in Adobe Camera Raw because the profiles contain compensation for a limitation that is unique to ACR when it is used in conjunction with After Effects. Using the profiles in any other raw app (i.e. raw apps without that limitation i.e. any raw app that isn't ACR) you will be introducing a new issue.
Thanks for the info.

Quote
I'm not sure why you would even want to use a fixed colorspace management DCP anyway as your app is built on GPU accelerated shaders!?
That application is built on CUDA and we can utilize any colorspace management in realtime. Currently we are working on DCP support. What approach would you suggest to implement?
Post by: megapolis on May 31, 2017, 11:00:41 AM
Fast CinemaDNG Processor is currently used in the Aeon Motion Scanning System for 3D scanning and 4D capture with 20 MPix industrial cameras:
http://ir-ltd.net/introducing-the-aeon-motion-scanning-system/  (http://ir-ltd.net/introducing-the-aeon-motion-scanning-system/)

This is comparison with Adobe Lightroom for DNG image processing performance:
«FastVideo is lightning fast. It’s still in early development but it can process sequence data on the fly, on the GPU in real-time in ms, rather than in minutes per frame. This means we can now process a 28,800 image sequence set in under 10 minutes, instead of 10 hours. Literally a game changer.»
Post by: jankrueck on June 01, 2017, 11:10:51 PM
hey Im not home yet, but is the software suporting the "new" 4k raw?
(there where some changes on mlv_dump made to fix linedropping)

looking forward to give it a try! soundds great so far
Post by: megapolis on June 02, 2017, 12:03:35 PM
At the moment we support DNG/CinemaDNG only. MLV support is expected soon.
Post by: andy kh on June 02, 2017, 11:03:56 PM
supporting mlv would be interesting
Post by: jankrueck on June 03, 2017, 02:14:41 PM
At the moment we support DNG/CinemaDNG only. MLV support is expected soon.

Ah ok. I thought you'd allready support it. nvm. I'll wait :D
Post by: DeafEyeJedi on June 03, 2017, 11:18:08 PM
At the moment we support DNG/CinemaDNG only. MLV support is expected soon.

http://www.magiclantern.fm/forum/index.php?topic=19300.0
Post by: jankrueck on July 09, 2017, 11:22:54 PM
any news?
Post by: megapolis on August 11, 2017, 02:56:04 PM
In the latest release of Fast CinemaDNG Processor we've fully redesigned CUDA code for Histogram/Parade module and Denoiser (which is working before debayer). We have also implemented some more features for image processing on GPU:
1. Rotation to arbitrary angle in realtime.
2. Now we can work with LCP (lens profiles) to do undistortion and CA removal. We utilize ready LCP or prepare them from Adobe Lens Profile Creator.
Post by: DeafEyeJedi on August 11, 2017, 06:49:00 PM
Thanks for the heads up @megapolis -- any chance that this will eventually run under Wine? I just tried again and unfortunately the same errors came up from when I first reported (http://www.magiclantern.fm/forum/index.php?topic=19021.msg180458#msg180458first reported). Is it really due to the lack of not having required NVIDIA CUDA installed on this MBP?

(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Ffarm5.staticflickr.com%2F4375%2F35695302413_8ecb63e404.jpg&hash=6380caca0575d87a6228985057c48185) (https://flic.kr/p/WogKNv)

Seems I'll be better off running an emulator if one wants to try this app on their OS X?
Post by: megapolis on August 15, 2017, 11:14:58 AM
Current version is working with Windows only. At the moment we need to design and to implement on CUDA quite a lot of algorithms for DNG image processing. Other OS will be a subject for implementation in the future, but not now.
Post by: 3Dto5D on September 19, 2017, 04:51:23 PM
Thats a really nice GUI and looks good too. Too bad I'm in Mac OS. I really would Love to use this on the Mac natively though If there was any chance. Thanks.
Post by: megapolis on November 09, 2017, 08:50:39 AM
New features in the latest release:
1. Project templates to save current set of parameters and settings. Now one can utilize that template to process next DNG series with the same parameters. Have a look at Project templates widget.
2. DNG player is working with audio from wav-file.
3. This is the first release with accelerated lossless jpeg decoder on CPU. We will publish more info about that soon.

Post by: jankrueck on December 02, 2017, 11:56:17 AM
Hey!

I've been playing around with this. again.
And sorry to say, but I dont get it. All of this is available in Resolve or in ACR as well.
To me it feels kinda bulky to import and export files.

I don't want to spread heate, just saying, I dont get it :D

Anyways, I', still looking for a descent way to handle mlv/4kraw without debayering to 1238234 dng files ;)

keep it up, Jan
Post by: megapolis on December 06, 2017, 10:58:25 AM
It's difficult to agree that
Quote
All of this is available in Resolve or in ACR as well.
Just try to play DNG series with 4.6K resolution and Denoiser option on, you could hardly get smooth video output with ACR. It's much better with Resolve, but still this is a problem.
The most frequent usage of that software is preview of DNG series. You just need to choose a folder with DNG in Windows Explorer to see realtime video. This is fast and simple. The latest release is working with our new CPU-based Lossless JPEG decoder which is faster than decoders from dcraw, libraw, lj92, Adobe DNG SDK.
P.S. Unfortunately MLV support is not yet ready.
Post by: IDA_ML on December 06, 2017, 12:39:38 PM
Megapolis,

I was wondering if it might be possible to just add MLVFS to your software.  Although I agree that the preview quality of the DNGs is great, it simply takes to long to open a DNG folder and this really makes it too heavy to use unless you really have a very beefy videocard.  Opening MLV files directly would be a way better option, especially if this could be done fast.  MLVFS would help in that respect if it could be implemented.  Just a thought.
Post by: megapolis on December 07, 2017, 10:46:53 AM
As I know, usually there is no need to have beefy video card for image processing of DNG images with resolutions less than 2K. If I haven't understood you correctly, please advise. If our software is working slow, please send me a link to your MLV file for evaluation.

You can test your MLV files by running MLVFS and Fast CinemaDNG Processor. What you need in Windows-7/10 (64-bit):
4. Run the following command: mlvfs -f Z: --mlv-dir=\mlvdir

Then from Windows Explorer you can click with right button on your MLV file and choose in the context menu “Preview with Fast CinemaDNG”. Actually we haven't done anything here. Transform from MLV to DNG is done by MLVFS.
Post by: megapolis on December 11, 2017, 11:00:28 AM

This is a benchmark for GPU-based image processing of MLV which was loaded via MLVFS, processing is done with Fast CinemaDNG Processor on NVIDIA GeForce GTX 580 (PCI-Express x16 Gen2):

Total memory 1536 MB, free 179 MB, allocated 109 MB
Input image: 1280x720 pixels
Host-to-device transfer = 0.47 ms
Linearization LUT = 0.35 ms
White balance = 0.03 ms
Raw curve = 1.06 ms
Debayer = 1.15 ms
ProPhoto space transform = 0.09 ms
RGB Lut = 0.21 ms
Output color space transform = 0.09 ms
Crop time: 0.00 ms
Resize = 0.00 ms
16 to 8 bit transform = 0.06 ms
Histogram = 1.20 ms
Viewport crop = 0.00 ms
Viewport resize = 0.88 ms
Total GPU = 7.90 ms
Total GPU + CPU = 10.95 ms

P.S. Could you please give me a link to 4K MLV footage for testing?
Post by: IDA_ML on December 11, 2017, 06:05:12 PM
P.S. Could you please give me a link to 4K MLV footage for testing?

Megapolis,

I have prepared a short (84 frames) 3K MLV file (3072x1920) for you to test.  It is about 590 MB and you can download it from here:

https://we.tl/mdeBlxLtvx

It takes about 20s. to open this file with FastCinemaDNG from Explorer with MLVFS installed as you suggested above.  If I want to view the next MLV file, I have to close the first one and if I forget to do this, the software crashes.  The computer that I used for this test and for editing my videos has a Q6600 CPU, 8GB of RAM and a GTX 750Ti GPU (2GB DDR5 RAM).  I am on Win7x64. An opening time of  20 s. for such a small file is way too long.  MLV Producer opens the same file in about 3 s. Moreover, in Producer I can open a whole batch of MLV files in just a few seconds.  I have just tested it with 15 MLV files (a total of 8 GB) and it created thumbnails of all of them within 9 s. after dragging them from Explorer onto the MLVProducer icon.  Once the thumbnails are in the preview window and I click on each of them, the MLV file opens in full size almost instantaneously.  So, if I want to browse between lots of MLV files, I prefer to use Producer since it is so fast and easy to use.  I use FastCinemaDNG only if I want to view a particular MLV file at a high quality and real-time playback.

Conclusion:  FastCinemaDNG is great in terms of preview quality and fast playback, as well as editing options but slow and not convenient to work with.  Converting files using the FFMPEG option is a pain.  This would be a great software if it would have been faster, better organized and would offer convenient and fast export/converting options.

I hope, this feedback is useful and wish you great success in making your software more user friendly to work with.
Post by: megapolis on December 12, 2017, 11:56:19 AM
Thanks a lot for your MLV file and for your feedback. On my PC (Core i7-3820 3.6 GHz, RAM 16 GB, NVIDIA GeForce GTX 580), which is quite old, it takes 5-6 seconds to load your project. I agree that 20 s is not acceptable, but generally, for DNG image processing we need to have good CPU, GPU and SSD, so the PC should be quite powerful. We always load new project without offloading previous one. We will check why it causes crash.

The first run of each software takes around 2-4 seconds, so it's not surprising. For GPU-based image processing we also have to initialize CUDA and allocate GPU memory, which are not very fast procedures. That's why 5-6 seconds for such a task at the first run should be reasonable. To insure fast loading for the next project we need to optimize our software and I hope to cope with that in a couple on weeks.

Interface to work with FFmpeg is quite simple, you just need to put there right command line. We have prepared a list of frequently used command lines, so it should be not very difficult, you can find that info in the manual.

The main idea of our software is to insure fast image processing and smooth output for 4K with maximum possible options like high quality debayering, denoising, undistortion, geometry transforms, 3D LUTs, etc. We think that it could be done on GPU in realtime with GeForce GTX 1060 or better.
Post by: IDA_ML on December 12, 2017, 05:50:33 PM
Megapolis,

Maybe, I should share another thought about FastCinemaDNG with you.  Working only with folders full of cDNG sequences is not a good idea at all.  This means that you have to drag all your MLV files that you wish to view, to a MLVFS folder and apply MLVFS to them.  This additional step is impractical and takes time and a lot of disk space.  In most cases, your MLV-files are spread in hundreds of directories on different internal and external drives.  What if you want to quickly view a specific MLV file or find it among 100 others?  Do you want to convert all of them into cDNG folders first?  This is very impractical.  It would be much easier if you could just click on the MLV-file and open it immediately.  This is how Producer works.  All you need to do is to set the file association .MLV to open with Producer.

If you could add MLV support to FastCinemaDNG, this would make it much more user friendly.  Think about it.
Post by: megapolis on December 13, 2017, 08:25:56 AM
IDA_ML,
Thanks for sharing your thoughts. This is exactly what we are doing now and we hope to release direct support of MLV format soon. We are going to open MLV instantly from Explorer without running MLVFS and without convertion to cDNG.
Post by: IDA_ML on December 13, 2017, 04:09:48 PM
This is great, Megapolis!  May I make another, in my opinion, useful suggestion?  Could you possibly modify Fastcinemadng in such manner that the user could navigate to a folder with MLV files in Explorer and by clicking on that folder, Fastcinemadng would create inside Explorer a window with thumbnails of all MLVs inside the folder.  This thumbnail creation should happen very fast, as in Producer.  Once the user finds a  thumbnail of interest, he clicks on it and the MLV file opens in the full sized software window, ready for playback, adjustments, quick export, etc.  If the user wants to repeat the same thing with another MLV, he just clicks on its thumbnail and the file opens in the full sized window.  In other words, Fastcinemadng should work as any photo viewer (such as IrfanView for example), but with MLV-files, instead of JPEGs or CR2 files.  You don't even have to animate the thumbnails as DaVinci Resolve does.  All you need to do is to use a single frame from somewhere in the middle of MLV clip to create its thumbnail.  It should just give a hint to the user what that clip is all about and I think this would be very helpful and user friendly already.  Do you think, this would be possible?
Post by: megapolis on December 14, 2017, 11:21:53 AM
Thanks for your suggestions. We do have such plans, but we are going to implement them in a way of Windows Explorer shell extension, that would generate thumbnails for MLV files while viewing folder content. It shouldn't be time consuming procedure as soon as image processing pipeline for such a task is very simple. The same feature is implemented in Adobe DNG Codec for Windows. It will be done later, because currently we are working on MLV support and on fast DNG decoding.
Post by: megapolis on December 19, 2017, 09:25:48 AM
When we do GPU-based image processing with Fast CinemaDNG Processor software, we have to bear in mind that performance of CPU and SSD also play an important role in this process, since for any image we have to read, to download, to parse, to decode DNG, and only then we can upload uncompressed raw data into GPU memory for image processing and display.

The main bottleneck for CPU is fast DNG decoding. Typically DNG images are encoded with lossless compression algorithm and usually this is Lossless JPEG.
Lossless JPEG algorithm is essentially serial, so GPU can't help at decoding. To speed up decompression on CPU, it is possible to do decoding of each tile or of the entire image in a separate thread, and one can accelerate Huffman decoding algorithm on CPU.

We have implemented both methods, so we can do lossless jpeg decoding at multi-threaded mode, and we have also optimized the process of DNG decoding on CPU. It's difficult to say how fast that new DNG decoder, because decoding performance strongly depends on image content. Here you can see some benchmarks which correspond to the best and the worst cases of Lossless JPEG decoding for multithreaded applications. These examples illustrate the idea of multithreading performance for lossless jpeg decoding on multicore CPU.

16-bit image, compression ratio 10.4 bpp (lossless compression)
LJ92 (library liblj92): 266 MPix/s
Fastvideo LJ Decoder: 407 MPix/s

12-bit image, compression ratio 5.6 bpp (lossless compression)
LJ92 (library liblj92): 284 MPix/s
Fastvideo LJ Decoder: 475 MPix/s

These results show that fast DNG decoding on CPU is possible in realtime for DNG series with 4K resolution and more. Decoding optimization, vectorization and multithreading are key factors to achieve high performance decoding.

At the following link there is more detail concerning benchmarks and other info about lossless jpeg decoding on CPU:

Our new DNG decoder helps to reduce CPU load. Earlier, due to lack DNG decoding speed on CPU, we ran into problems with smooth video playback for 4.6K footages from BMD URSA, and now we don't have these jerks on good PC even in the case if we switch on gpu-based denoiser.
Post by: megapolis on February 16, 2018, 12:09:29 PM
The latest release is more stable and reliable, we've improved the performance, several bugs were removed. Now one can switch on/off every curve (RAW, RGB, HSV) to see the difference.

We've also added GUI to work with external 3D LUTs (RGB) in cube format. They could be applied via GPU in realtime. Duration in milliseconds of that stage of image processing could be seen at Benchmarks widget. Maximum cube size is 65x65x65. In order to switch on 3D LUT module, close current project, go to Options dialog, choose tab “Output and Extensions” and check the box for 3D LUTs module. All your luts should be placed in the folder C:\Users\User\Fastvideo\3D LUTs. On NVIDIA GeForce GTX 1060 processing time is around 2.5 milliseconds to apply 3D LUT 32x32x32 to 16-bit image with 4K resolution.

Post by: megapolis on February 19, 2018, 11:37:03 AM
At the following page
we've created a list of direct links to download sample files and sequences of DNG or CinemaDNG footages. All the links are currently valid and they correspond to raw data from Blackmagic Design, Ikonoscop, DJI, Kinefinity, AXIOM, etc. We utilize these footages for testing of our software for realtime DNG processing. Please let us know if we missed any interesting CinemaDNG footages which are available on the net.
Post by: megapolis on March 07, 2018, 03:38:05 PM
We've implemented interoperability between 3DLUT Creator and Fast CinemaDNG Processor. Now we can create 3D LUTs with 3DLUT Creator and immediately include them into image processing pipeline to fulfill color grading on GPU.

Basically, user starts from choosing current DNG frame which could be a good source to create 3D LUT. Then Fast CinemaDNG software runs 3DLUT Creator which is responsible for 3D LUT design. This is very powerful and popular software with thousands of users all over the world. We actually send to 3DLUT Creator our 16-bit TIFF which will the basis to create/edit 3D LUT. Finally, we automatically get 3D LUT file in cube format from 3DLUT Creator and insert it into image processing pipeline on GPU. This is the way to get final grading in realtime at the same workflow with DNG processing.
Post by: megapolis on March 25, 2018, 11:51:22 AM
We carry on with further development and optimization of Fast CinemaDNG Processor and here you can see the latest improvements which are present in the current release:
1. In the previous version of the software on NVIDIA GeForce GTX 1080, to apply 3D LUT HSV with size 36x57x61 to 16-bit 4K image, we spent ~8.5 milliseconds. Now we can do the same at just ~0.8 milliseconds. Quite often such a 3D LUT is a part of DCP profile.
2. Previously, on NVIDIA GeForce GTX 1080, we applied 64x64x64 RGB LUT to 16-bit 4K image at ~8.8 milliseconds. Now the same 3D LUT can be applied within ~0.6 milliseconds. Processing time of a particular 3D LUT can be seen in the benchmark window, where all stages of image processing pipeline are displayed.
3. The maximum size of 3D LUT is 256 now. Processing time to apply such a 3D RGB LUT on GeForce GTX 1080 varies in the range of 4-8 milliseconds for 16-bit 4K image. Some users do work with such LUTs, one have to remember that such a large LUT needs around 500 MB of GPU memory. By default, we are working with 3D LUTs with cube size up to 64.
4. We've improved software stability in the case of insufficient GPU memory size. Nevertheless, mining on the GPU during image processing is not recommended :(.
5. GPU memory consumption for Unsharp Mack algorithm is reduced by three times.

Post by: pc_bel on March 26, 2018, 02:13:16 PM
Thanks!!!
Waiting for the mlv support!!!!
Hope it will be soon  :D
Post by: Tony Weller on March 29, 2018, 02:43:13 PM
Is there anyway to reset the interface?  have got my self into a pickle.

Sharpening and de-noising very nice features, also looking forward to MLV support.
Post by: bouncyball on March 29, 2018, 03:34:37 PM
Is there anyway to reset the interface?
+1
Post by: megapolis on March 29, 2018, 10:39:19 PM
At the moment we haven't finished with UI management, so the only way to reset the interface is to delete the following branch in registry HKEY_CURRENT_USER\Software\Fastvideo\  and to reinstall the software.
MLV support is expected in April.
Post by: Tony Weller on March 29, 2018, 11:03:25 PM
OK thanks, I'll wait patiently

Credit to you it's flying along on my low spec i3 and gt1050 card and as I said earlier the DE-noising and sharpening are excellent.

IMO the best GUI is Resolve14 free or studio.
Post by: megapolis on April 05, 2018, 11:50:34 AM
We've implemented a new feature to import CinemaDNG raw footages to Adobe Premiere Pro. The subject is not straightforward, as soon as there are many possible choices for CinemaDNG encoding and formatting. For example, for the latest Blackmagic cameras one can't import CinemaDNG Raw files to Premiere Pro and it could be the case with other encoding options for CinemaDNG as well. An idea to save DNG series with better compression and correct formatting is also important for further editing in Premiere Pro. I hope that it could be relevant here as soon as ML users are working with Adobe Premiere as well.

We've implemented CinemaDNG transcoding to the format which is native to Adobe Premiere Pro CC.
This is converter pipeline at Fast CinemaDNG Processor:
• Choose project output format to be DNG
• Choose encoding method: Uncompressed or Lossless JPEG
• Press red button on Player
• Wait for transcoding to be finished
• After transcoding you can find at Output folder new footage with specified encoding
Uncompressed export option includes the following bit depths: 8-bit, 10-bit, 12-bit, 14-bit, 16-bit. For compatibility with Adobe Premiere Pro CC one have to utilize either Uncompressed or Lossless JPEG export options.
Post by: Tony Weller on April 06, 2018, 12:08:26 AM
So still no MLV support  Done
Post by: pc_bel on April 06, 2018, 09:56:53 AM
It's good to have a lot of options in same software, but I hope it doesn't mean not to have MLV direct support... :-[
Post by: Tony Weller on May 21, 2018, 12:09:34 PM
Just had email from fastcinema regarding the now included MLV support, and it works very well :)

Jusr drag and drop MLV file to the interface, very fast, focus dots also taken care of.

Only issue I have so far is cannot change aspect ratio to match my newly aquired EOSM RAW 1736*444 video.

Found it

Post by: megapolis on May 21, 2018, 01:07:45 PM
Thanks a lot to @g3gg0 for the help with MLV format understanding and for making the file mlv_structures.h to be LGPL. We are also very thankful to @AWPStar, @IDA_ML and to other people from ML forum for useful comments.

We've finally implemented MLV support at Fast CinemaDNG Processor software and we can play and process MLV on GPU natively. Now it's possible to open MLV files from Windows Explorer via context menu, or one can set file association .MLV to open MLV with Fast CinemaDNG or drag-n-drop MLV file to the application window. The latest version for Windows could be downloaded here:

Please bear in mind that the software is working on Windows with NVIDIA GPU only (Kepler or better), it's not working without such GPU. The latest NVIDIA driver should be installed as well. Your feedback is welcome. If your MLV file can't be loaded or it's loaded with errors, please send us the link to your MLV file for testing.

The software supports 10/12/14/16-bit uncompressed MLV files or compressed with lossless jpeg. We also extract and play audio. MLV to video transform could be done via interoperability with external FFmpeg which should be installed by user. We've also implemented support for spanned MLV files and option to export CinemaDNG series out of MLV with lossless or lossy encoding.

The first project is loaded not very fast as soon as we need time to load application, to initialize CUDA, to check and to allocate GPU memory. If the next project has the same frame resolution or less, and the same bit depth, then it will be loaded immediately. If new project has bigger resolution or different bit depth, then we will have to reallocate GPU memory and recreate GPU pipeline for image processing, so MLV import will take more time.

What you can do with Fast CinemaDNG Processor software
1. This is fast MLV Player with image processing on NVIDIA GPU
2. Realtime debayering, denoising, resizing, sharpening, geometric transforms, etc.
3. Support for DCP and LCP profiles
4. Color grading with 3D LUTs (cube format)
5. MLV export to TIFF/JPG or to video

This solution could be quite fast if you have good SSD, CPU and GPU. MLV preview should be smooth. To check the performance, please have a look at benchmarks widget to see timing for each stage of image processing. One can also perform a transform from MLV to JPG series to see how fast it could be.
Post by: andy kh on May 21, 2018, 02:03:01 PM
good to know that now it starts supporting MLV. wil download and test it now

dit: it doenst work  on my laptop with 2gb nvidia graphic
Post by: megapolis on May 21, 2018, 02:12:49 PM
Quote
it doenst work  on my laptop with 2gb nvidia graphic
Which GPU model do you have? Minimum requirement is GPU of 6xx series (Kepler architecture). Have you installed the latest NVIDIA driver? 2 GB should be ok for images up to Full HD.
Post by: andy kh on May 21, 2018, 04:19:25 PM
its 525m  thats why its not working. i wasnt aware that minimum should be 6xx
Post by: Kharak on May 21, 2018, 07:27:49 PM
Will test as soon as i get a descent internet connection.

Is Nvidia 980m supported? Older versions worked with it, not sure if you changed anything
Post by: megapolis on May 21, 2018, 07:45:22 PM
Quote
Is Nvidia 980m supported? Older versions worked with it, not sure if you changed anything
Yes, it should work. Previous version of the software was based on CUDA-8.0 which was compatible with 5xx series of NVIDIA GPU. Now we've moved to CUDA-9.1 and that's why minimum requirement is 6xx NVIDIA GPU.
980m is laptop gpu and quite powerful. This is Maxwell architecture which is fine.
Post by: megapolis on June 20, 2018, 09:45:26 AM
1. AVX speedup for focus dots removal
2. Export to EXR format
3. One can save current frame to any 24-bit image format which is supported in QT
Post by: bouncyball on July 11, 2018, 04:50:29 PM
When there will be ready Linux version?
Post by: megapolis on July 11, 2018, 05:07:14 PM
I'm sorry for the delay. We have too many urgent things to do at the moment. Currently we are working on grayscale DNG support. We are also going to release pgm2dng opensource project at github soon. I hope that Linux version of Fast CinemaDNG Processor for Ubuntu 16.04 should be ready within 2-3 weeks. I will post that info here as soon as it's ready.
Post by: bouncyball on July 12, 2018, 09:35:17 AM
Post by: breaker on July 21, 2018, 02:53:02 PM
I have tried hard to export MLV files as DNG files. But all i can export is MP4.
Tried to change Default Output format to DNG in Options. Tried to choose DNG instead of ffmpeg in Render dialog... and a lot of other stuff.
The .dng files seem to be ready in the project explorer window to th left. But I want them exported as separate files.
I'm using lastest version.
Post by: megapolis on July 21, 2018, 08:24:21 PM
Thanks for your info. I've checked that and I can see that you are right - in the latest release, which we've uploaded yesterday, there is a problem at DNG export with Lossless JPEG compression. All other options for DNG export (uncompressed DNG, BMD 3:1, BMD 4:1 and BMD 5:1) are working well and you can use them. I think, we will be able to fix that on Monday. I will let you know.

For DNG export you need to set Output format to be DNG and in "DNG export" tab choose compression algorithm. Then press red button at Player panel and you will get exported DNGs at /Output folder.
Post by: breaker on July 22, 2018, 07:38:31 PM
Thanks for quick reply! I did not use any compression, but the strange thing is that I got it working after you replied, but then I had the files on a local SSD-disk. At earlier tries I had the files on a network disk, could that be a reason?
Post by: megapolis on July 23, 2018, 05:50:03 PM
Your MLV/DNG files could reside either on SSD or on network disk, the software should work. We have a user who is processing 5K CinemaDNG images on M.2 network disk via 10GigE and even at that case he can achieve realtime processing with our software.
In the latest release we've also added support of Kinefinity digital cinema cameras.
Post by: breaker on July 23, 2018, 07:04:24 PM
Thanks! Downloaded and installed. Most of the GUI scales a lot better on my 3840x2160 sceen, but the picture is very small now.
Don't seem to import more than the first mlv file. DNG's from M00, M01 etc. don't appear (only 102 dng's from MLV + M00...M21). That was also a issue for me on the latest version. I'm happy to test more  :)
Post by: megapolis on July 23, 2018, 10:01:12 PM
Quote
Most of the GUI scales a lot better on my 3840x2160 sceen, but the picture is very small now.
Have you tried to zoom the picture? Could I have a look at screenshot?

Quote
Don't seem to import more than the first mlv file. DNG's from M00, M01 etc. don't appear (only 102 dng's from MLV + M00...M21).
Could you please send me your set of spanned files for testing? We tested such files and there were no problems with them.
Post by: breaker on July 23, 2018, 11:11:10 PM
Quote
Have you tried to zoom the picture? Could I have a look at screenshot?
Sent you link by PM. The picture's frame didn't scale, but the picture scaled up inside original small frame.

Quote
Could you please send me your set of spanned files for testing? We tested such files and there were no problems with them.
Sent you link by PM. Not ordinary mlv video, but Full res Silent Pic.
Post by: megapolis on July 25, 2018, 12:38:56 PM
Thanks for sending your screenshots and mlv files.
Now High DPI mode is working. Your spanned mlv files also could be loaded and processed.
Post by: theBilalFakhouri on July 26, 2018, 02:02:17 AM
Hello! @megapolis

It's really nice software for viewing MLV files in Real-Time! I was using a build from about three months without problems in playback but the latest one I can't playback the file until I press the mute sound button and when sound is on the playback stuck,, can you confirm that in Windows ? (I am on Windows 8.1).

Also I am wondering why loading the file is taking long before it open I am using SSD and even for small files you should wait until it loading,, can it be improved?

Nice software!
Post by: megapolis on July 26, 2018, 06:53:06 AM
Three months ago, as I remember, we didn't have full audio support yet. Since then we've added audio player and it could be a problem at playback if audio file size doesn't correspond to a number of frames in mlv or dng series. If you press mute, you switch off audio player, so audio can't affect the playback. Could you please send me a link to your mlv for testing to discover possible bug in audio player? You can do that here or via PM.

As far as concerns project loading time, it takes so long because before loading we need to reallocate GPU memory and recreate all GPU-based modules for image processing. These are not fast procedures. We know how to make it better, but the task is quite complicated and we hope to accomplish it by the end of the year.

MLV/DNG projects can be loaded fast if they have the same frame resolution and bit depth. In that case we don't need to reallocate GPU memory and we can reuse it. Please don't close current project before opening the next one. If all your mlv/dng are from the same camera, you will get fast loading for all projects starting from the second one at such approach.

If you have loaded one project and the next project has the same bit depth, but less or the same width and height, in that case the second project will be loaded fast as well. If your projects have different bit depths, in that case we always have to recreate image processing pipeline and it takes time.

Good SSD helps to read mlv/dng fast, this is very important to ensure smooth playback. This is especially important when you are loading uncompressed mlv/dng. Please note that our software is offering both mlv2dng export and dng recompression (dng2dng transform), so you will be able to get your dngs with lossless or lossy compression. You can also cut your dngs at the same time if you need.
Post by: theBilalFakhouri on July 27, 2018, 01:24:49 AM
@megapolis

Yes it wasn't three months exactly Hahahaha I thought it was three,, I has download it in 29/5/2018 about 1.5 month ago. Here is how the problem looks like:

And here the MLV (https://drive.google.com/open?id=1EZ60FwXgnzyajaOmpL82ZaLHrJIpKM7u) file. There is no problem when playing extracted DNGs with audio only with MLV files not working correctly.

Thanks for explaining about loading time and good luck for improving that fingers crossed! Also for exporting DNGs from MLV I had no luck with exporting settings it some kind of complicated thing for me (I was trying maybe to export to H.264 using ffmpeg) . Now I tried exporting to DNG and Motion JPEG it just fine and more simpler than ffmpeg commands.
Post by: megapolis on July 27, 2018, 07:55:00 PM
Thanks for your info and for mlv. This is a bug. I will let you know when we fix it.
Post by: 12georgiadis on July 30, 2018, 08:43:12 PM
Hello, very promising app!
I wanted to know if there is a possibility to implement a batch for cinema offline workflow Id. Export ProRes 4444 12 bits (av foundation) + ProRes proxy that shares the same tc + reelname + name on metadatas. The idea is that we can edit with proxy for offline editing. Then conform with ProRes 4444.

Or then what alternative codec to ProRes 4444 with C-log do you recommend ?
I heard that jpeg2000 is lighter than APR444 but is it editable in Premiere Pro CC / FCP X / Resolve / Avid MC ?
Could it be contained in a .mov ? Can we put a log-c on it ?
Can we have an offline workflow like working with APR Proxy and conform to jpeg2000 (sharing the same TC and name metadatas) ?
is it seen as one file and not multiple stills ? Is it faster to process from mlv than APR 4444 ?
What about Cineform ? Is it compatible with CUDA ?

By the way, what demosaicing algorithm do you recommend to remove aliasing when you have a camera without vaf-filter (like eos-m) ?

Envoyé de mon iPhone en utilisant Tapatalk
Post by: megapolis on July 31, 2018, 06:23:43 PM
Quote
I wanted to know if there is a possibility to implement a batch for cinema offline workflow Id. Export ProRes 4444 12 bits (av foundation) + ProRes proxy that shares the same tc + reelname + name on metadatas. The idea is that we can edit with proxy for offline editing. Then conform with ProRes 4444.
Right now it's not possible at our software. You can do that in two steps:
1. Export from Raw to ProRes 4444 12 bits via FFmpeg
2. Export from Raw to ProRes proxy via FFmpeg
We are going to add scripting to the software in the future to be more flexible and I think that such a task could be solved then.

Quote
Or then what alternative codec to ProRes 4444 with C-log do you recommend ?
We can't give you such a recommendation. We think that ProRes is good.

Quote
I heard that jpeg2000 is lighter than APR444 but is it editable in Premiere Pro CC / FCP X / Resolve / Avid MC ?
We have experience with JPEG2000 and recently we've actually released GPU-based JPEG2000 codec. You can get more info here:
https://www.fastcompression.com/products/jpeg2000/gpu-jpeg2000.htm
This is very complicated algorithm and our JPEG codec on GPU is about 15-20 times faster. You can see our J2K benchmarks at the site. I think that J2K will make sense only in the case if there is a second GPU at your PC, exactly for J2K handling in realtim. So, J2K is not a light solution. It's quite heavy, but with high quality, and it supports 14 and 16 bits as well. Though, for small resolutions it could be ok even on a single GPU. Soon we are going to release MXF player on GPU, but this is different task.

Quote
Could it be contained in a .mov ? Can we put a log-c on it ?
Export to MOV is usually done via FFmpeg, so this is not a problem. As far as concerns Log-C, we still need to add a feature to import output curves from external files. Right now our software can't do that.

Quote
Can we have an offline workflow like working with APR Proxy and conform to jpeg2000 (sharing the same TC and name metadatas)?
We haven't done that yet. You can try it with our software via external FFmpeg, which can encode to J2K.

Quote
is it seen as one file and not multiple stills?
In general, if you save J2K frames in MXF file, then in will be just one file. You can also save J2K as multiple stills.

Quote
Is it faster to process from mlv than APR 4444 ?
We haven't done that comparison yet.

Quote
What about Cineform ? Is it compatible with CUDA ?
I think that Cineform could be implemented on GPU, but I haven't heard about such an attempts. In general, that algorithm could be done in parallel, but at the moment it exists only at CPU implementations, as I know.

Quote
By the way, what demosaicing algorithm do you recommend to remove aliasing when you have a camera without vaf-filter (like eos-m)?
I don't know good solution for that task. Chroma denoising could help, but not too much. I think that current progress in debayering is slow and I think that we could expect good results only from machine learning side. Neural networks (CNN) show very good results, but they are still very slow. As I know, max debayering performance currently is around 1 Mpix/s on GPU at CNN.
Post by: mothaibaphoto on August 01, 2018, 06:51:29 AM
...
1. Export from Raw to ProRes 4444 12 bits via FFmpeg
Sadly, there is NO 12 bits ProRes in FFmpeg.
But You, as a software developers, can help to fix that:
https://trac.ffmpeg.org/ticket/7163
Post by: masc on August 01, 2018, 11:14:22 AM
Sadly, there is NO 12 bits ProRes in FFmpeg.
But You, as a software developers, can help to fix that:
https://trac.ffmpeg.org/ticket/7163
Post by: 12georgiadis on August 02, 2018, 10:47:57 AM
Right now it's not possible at our software. You can do that in two steps:
1. Export from Raw to ProRes 4444 12 bits via FFmpeg
2. Export from Raw to ProRes proxy via FFmpeg
We are going to add scripting to the software in the future to be more flexible and I think that such a task could be solved then.
We can't give you such a recommendation. We think that ProRes is good.
We have experience with JPEG2000 and recently we've actually released GPU-based JPEG2000 codec. You can get more info here:
https://www.fastcompression.com/products/jpeg2000/gpu-jpeg2000.htm
This is very complicated algorithm and our JPEG codec on GPU is about 15-20 times faster. You can see our J2K benchmarks at the site. I think that J2K will make sense only in the case if there is a second GPU at your PC, exactly for J2K handling in realtim. So, J2K is not a light solution. It's quite heavy, but with high quality, and it supports 14 and 16 bits as well. Though, for small resolutions it could be ok even on a single GPU. Soon we are going to release MXF player on GPU, but this is different task.
Export to MOV is usually done via FFmpeg, so this is not a problem. As far as concerns Log-C, we still need to add a feature to import output curves from external files. Right now our software can't do that.
We haven't done that yet. You can try it with our software via external FFmpeg, which can encode to J2K.
In general, if you save J2K frames in MXF file, then in will be just one file. You can also save J2K as multiple stills.
We haven't done that comparison yet.
I think that Cineform could be implemented on GPU, but I haven't heard about such an attempts. In general, that algorithm could be done in parallel, but at the moment it exists only at CPU implementations, as I know.
I don't know good solution for that task. Chroma denoising could help, but not too much. I think that current progress in debayering is slow and I think that we could expect good results only from machine learning side. Neural networks (CNN) show very good results, but they are still very slow. As I know, max debayering performance currently is around 1 Mpix/s on GPU at CNN.

As said above, no ProRes 12 bits. Only AVfoundation.
j2k is intersting because if it's wrapped in MXF, it can be used for editing on all NLE.
Cdng is good and all the options you offer are excellent, but this format is sadly not very well handled by fcp X / Premiere / Avid.
Then, where we can use it except with Davinci Resolve ?
I think ProRes + J2k GPU encoding + GoPro cineform GPU is very futur proof editing codec as it can be used in cross platform.
Post by: megapolis on August 03, 2018, 08:34:52 AM
Quote
As said above, no ProRes 12 bits. Only Avfoundation.
As I know, ProRes is DCT-based compression algorithm, which is, to a certain extent, almost the same (not exactly the same) as JPEG. We have implemented 12-bit JPEG on GPU and it's super fast:
https://www.fastcompression.com/products/jpeg/12-bit-jpeg-codec.htm  (https://www.fastcompression.com/products/jpeg/12-bit-jpeg-codec.htm)
Please note that libjpeg library also has 12-bit JPEG option and its performance is sufficient to get decoding in realtime on modest CPUs.
By the way, Blackmagic CDNG RAW 3:1 is also utilizing that compression algorithm.
Could it be a solution?

Quote
j2k is interesting because if it's wrapped in MXF, it can be used for editing on all NLE.
I think that j2k is too heavy to be comparable with ProRes, j2k is too slow, though it could have better quality. To get smooth playback for j2k at full resolution, you need very good PC, no chances for laptop. I agree that j2k at MXF can be used at any NLE, but how many users really do that? In that workflow we will need multi-GPU PC. We are going to add such a feature, hopefully this year, but two GPUs will be a must. Our j2k codec on GPU is ready.

Quote
Cdng is good and all the options you offer are excellent, but this format is sadly not very well handled by fcp X / Premiere / Avid.
Our software can smoothly process and play CDNG/RAW series at full resolution for 4K and higher. Can you do that with FCPX/Premiere/Avid smoothly not at ½ or ¼ mode together with high quality debayering? At the moment, external FFmpeg is the only option to use our software with any NLE. Interoperability with FFmpeg is working well.

Quote
Then, where we can use it except with Davinci Resolve?
At the moment that software is mostly utilized by our customers which are ok with export of JPEG series. In that case everything is done on GPU and this is very fast. It's called ingestion task for realtime multiple camera systems and that approach is also used in 3D and VR applications. Please have a look how it's working:
http://ir-ltd.net/introducing-the-aeon-motion-scanning-system/  (http://ir-ltd.net/introducing-the-aeon-motion-scanning-system/)

I agree, that export to ProRes or DNx would be necessary for our software, but right now this is not possible. It's a shame. But you can use it with any NLE via FFmpeg.
We also have very positive feedback concerning our MG debayer algorithm and this is the reason why many our users do preprocessing at Fast CinemaDNG Processor software.

Quote
I think ProRes + J2k GPU encoding + GoPro cineform GPU is very futur proof editing codec as it can be used in cross platform.
It looks interesting, but we are not sure that this is standard approach. Implementation of such an algorithm on GPU will take at least a year (we are a small company), so before starting such a development, we need to understand why it's worth doing. Unfortunately it's not clear for us.
Post by: theBilalFakhouri on August 13, 2018, 04:18:32 PM
Hi @megapolis

It would be nice if we can export .wav audio file beside Motion JPEG .avi format for MLV so we can have audio playback too after exporting to Motion JPEG.

Thanks!
Post by: 12georgiadis on August 13, 2018, 07:15:41 PM
As I know, ProRes is DCT-based compression algorithm, which is, to a certain extent, almost the same (not exactly the same) as JPEG. We have implemented 12-bit JPEG on GPU and it's super fast:
https://www.fastcompression.com/products/jpeg/12-bit-jpeg-codec.htm  (https://www.fastcompression.com/products/jpeg/12-bit-jpeg-codec.htm)
Good to know ! But there is also 12 bit with ProRes. It needs AVfoundation to work and not ffmpeg. MLV app is also using AVfoundation to get 12 bit prores. That could be an interesting implementation.

Please note that libjpeg library also has 12-bit JPEG option and its performance is sufficient to get decoding in realtime on modest CPUs.
By the way, Blackmagic CDNG RAW 3:1 is also utilizing that compression algorithm.
Could it be a solution?
I think that j2k is too heavy to be comparable with ProRes, j2k is too slow, though it could have better quality. To get smooth playback for j2k at full resolution, you need very good PC, no chances for laptop. I agree that j2k at MXF can be used at any NLE, but how many users really do that? In that workflow we will need multi-GPU PC. We are going to add such a feature, hopefully this year, but two GPUs will be a must. Our j2k codec on GPU is ready.
Our software can smoothly process and play CDNG/RAW series at full resolution for 4K and higher. Can you do that with FCPX/Premiere/Avid smoothly not at ½ or ¼ mode together with high quality debayering? At the moment, external FFmpeg is the only option to use our software with any NLE. Interoperability with FFmpeg is working well.
At the moment that software is mostly utilized by our customers which are ok with export of JPEG series. In that case everything is done on GPU and this is very fast. It's called ingestion task for realtime multiple camera systems and that approach is also used in 3D and VR applications. Please have a look how it's working:
http://ir-ltd.net/introducing-the-aeon-motion-scanning-system/  (http://ir-ltd.net/introducing-the-aeon-motion-scanning-system/)

I agree, that export to ProRes or DNx would be necessary for our software, but right now this is not possible. It's a shame. But you can use it with any NLE via FFmpeg.
We also have very positive feedback concerning our MG debayer algorithm and this is the reason why many our users do preprocessing at Fast CinemaDNG Processor software.
It looks interesting, but we are not sure that this is standard approach. Implementation of such an algorithm on GPU will take at least a year (we are a small company), so before starting such a development, we need to understand why it's worth doing. Unfortunately it's not clear for us.

Ok for j2K.
Your example of VR project etc. is an interesting but specific approach. Here is what I'm trying to get for 2 years :

1) You're shooting MLV, which are the raw files, right ?
2) common cinema workflow is offline/online workflow. A good news is that 5DmkIII can records both MLV + H264 proxy. Thanks to Danne's switch app, it's possible to stamp the same tc to the proxy file than the MLV and correct synching the offrame of the proxy (it doesn't start in the same time as the mlv record). This way, we can edit offline (with proxy) and conform later online (relink) to the MLV. Which means, no transcoding and direct editing with h264 proxy. For Fcpx users, background proxies can improve the speed of playback.
3) When it's finished, you send an FCPXML to DavinciResolve and use MLVFS to generate on the fly CDNG readable by Resolve. the conformation is perfect thanks to the TC, like in any other cinema camera workflow (sony, red, arri...)

What is the benefit ?
1) direct editing on any modern NLE
2) save tons of data space and time !
3) With a standard and fast forward workflow, more pro people from cinema could jump into the magic lantern adventure to shoot feature with old DSLRs, open-source workflow and share their tips & experiences to the community.

What are the cons ?
1) poor performance during grading (because CPU MLVFS)
2) no interface with switch (command line only) and no GPU rendering and playback.

What could be improved with fast cinema DNG ?
1) generate ProRes Proxy via FFmpeg with a script that timestamp the same TC on proxy than on the MLV. Most cameras cannot generate proxy mlv in the same time (all except 5DmkIII) + script for 5DmkIII that correct black off frame from proxy & timestamp same tc on proxy than MLV
2) a system to generate on the fly CDNG with GPU rendering to speed workflow with resolve ? Or if not possible, generate CDNG that maintains the same TC and synch them to the proxy file (H264 or prores proxy)

Post by: megapolis on August 15, 2018, 01:37:56 PM
@theBilalFakhouri

Quote
I was using a build from about three months without problems in playback but the latest one I can't playback the file until I press the mute sound button and when sound is on the playback stuck, can you confirm that in Windows ? (I am on Windows 8.1).

Quote
It would be nice if we can export .wav audio file beside Motion JPEG .avi format for MLV so we can have audio playback too after exporting to Motion JPEG.

In the latest release you can see bug fixes both for audio sync and for .wav audio at MJPEG:
Post by: megapolis on August 15, 2018, 03:56:06 PM
Quote
What could be improved with fast cinema DNG ?
1) generate ProRes Proxy via FFmpeg with a script that timestamp the same TC on proxy than on the MLV. Most cameras cannot generate proxy mlv in the same time (all except 5DmkIII) + script for 5DmkIII that correct black off frame from proxy & timestamp same tc on proxy than MLV
2) a system to generate on the fly CDNG with GPU rendering to speed workflow with resolve ? Or if not possible, generate CDNG that maintains the same TC and synch them to the proxy file (H264 or prores proxy)

I think that it could be done, but we need more sofisticated specification for the full task. Could you please prepare it in more detail from the very beginning till the end? We will probably be able to generate proxy .mp4, .wav and full-frame .dng series at the same time.
Here are some questions:
1. If we choose new start and stop positions for CDNG series, which time code we need to write to CDNG file at start position? Is it zero or not? The same question for CDNG file at stop position – which time code should be there?
2. If we choose correct start and stop positions at CDNG series, what we have to do with audio file? Should it be truncated according to start and stop coordinates?
3. I don't think that we need to do anything with black frame series because we will choose start and stop positions manually. Is it correct?
Post by: theBilalFakhouri on August 15, 2018, 04:11:58 PM
@megapolis

I have just download the latest version but the problem is still there and I can't see .wav beside Motion JPEG. Maybe you have uploaded a wrong version?
Post by: megapolis on August 15, 2018, 04:25:03 PM
Sorry, we've fixed that bug for CDNG series, not for MLV. If you do fast export from CDNG to MJPEG, then wav file is also exported to the same folder. Will try to do that for MLV tomorrow.
Post by: theBilalFakhouri on August 15, 2018, 04:34:38 PM
Oh thanks for this nice software! :D I am waiting ;D
Post by: megapolis on August 16, 2018, 12:30:14 PM
@theBilalFakhouri
We've fixed bugs with mlv audio and added .wav for MJPEG export option:
If you see any bugs, please let me know.
Post by: theBilalFakhouri on August 16, 2018, 03:35:09 PM
Thank you! it's working now. I will do my best to support this nice software soon.
Post by: megapolis on August 21, 2018, 11:57:14 AM
Quote
What could be improved with fast cinema DNG ?
1) generate ProRes Proxy via FFmpeg with a script that timestamp the same TC on proxy than on the MLV. Most cameras cannot generate proxy mlv in the same time (all except 5DmkIII) + script for 5DmkIII that correct black off frame from proxy & timestamp same tc on proxy than MLV
2) a system to generate on the fly CDNG with GPU rendering to speed workflow with resolve ? Or if not possible, generate CDNG that maintains the same TC and synch them to the proxy file (H264 or prores proxy)

Please note that for FFmpeg you need to add the following to the command line:
-timecode 00:00:00.00 if fps = 29.97
-timecode 00:00:00:00 if fps = 59.94

As we understand, you will do the following:
Export to mp4 or anything else via FFmpeg (from Fast CinemaDNG)
Do the rest in Davinci or Final Cut.

Please let us know whether this is correct or not.
Post by: 12georgiadis on August 22, 2018, 01:22:23 PM
Hello Megapolis,

thank you and sorry for late reply, I'm on vacations  8)

Thank you. I'll do the test in middle of september.

Please note that for FFmpeg you need to add the following to the command line:
-timecode 00:00:00.00 if fps = 29.97
-timecode 00:00:00:00 if fps = 59.94

As we understand, you will do the following:
Export to mp4 or anything else via FFmpeg (from Fast CinemaDNG)
Do the rest in Davinci or Final Cut.

Please let us know whether this is correct or not.

Not exactly.
1) I shoot MLV raw and simultaneously record in Proxy H264 mp4. To do that, the canon has to start first the H264 rec and then the MLV raw. There is a timing difference. The timing difference is filled by a black on the mp4 Proxy. The sound is recorded on the mp4 proxy only.
2) in switch, I use a script that dupplicates the h264, reset the tc to 00:00:00:00 on the new dupplicate file and cut the black and export the audio.
it takes maximum 10' (depends on the volume of files)
3) I edit directly with proxy on premiere / Fcpx  etc. (offline editing). I mean, I'm editing 10' after the offload. No need to transcode. No time wasted. My last documentary was 30 hours of MLV files and I edit on laptop ;-) If the laptop is lagging, I activate Prores proxy background transcode. And i can switch between proxy mp4 and prores proxy from fcpx if neccessary. It's automatic, and you have better performances. at the end I switch again on mp4 proxy (it's one button).
4) I finish the edit, I conform by exporting an XML/FCPXML, AAF, depends on the software NLE. I don't export video file or audio file.
5) I generate on the fly CDNG with MLVFS. They have TC 00:00:00:00, same as the proxy mp4
6) I open resolve, I put my CDNG files in a bin, I put the exported audio in a bin, I import the XML/FCPXML/AAF, I relink automatically thanks to the TC + exact same filename and it's conformed. My editing timeline is back, but with the CDNG files now.
7) I can grade, export the master etc.

I don't want to generate durable CDNG files. I already have MLV files to store. And it's a lot of storage. And it's so slow ! We have to transcode before edit ! Too long for nothing. And I don't want to double the storage. This is nonsense.
The problem is that MLVFS is slow because it's CPU. The idea is to have a GPU solution for on the fly CDNG, because Resolve won't read MLV.
And your software has good settings, good corrections and good performance CDNG, this can be a very good solution. Also because MLVFS doesn't have all the options that you have.

Post by: megapolis on August 23, 2018, 02:20:59 PM
Quote
The problem is that MLVFS is slow because it's CPU. The idea is to have a GPU solution for on the fly CDNG, because Resolve won't read MLV. And your software has good settings, good corrections and good performance CDNG, this can be a very good solution. Also because MLVFS doesn't have all the options that you have.

I don't think that MLVFS is the slowest processing module. If you disable focus dots removal with chroma smooth, the only task for mlvfs is to find frame data block on disk, to generate dng header and to send it to application. These stages are not CPU hungry, their speed is rather limited by HDD performance.

DNG processing is slow because of demosaic and denoise stages. High quality demosaic and denoise algorithms are CPU hungry. We've managed to develop extremely fast and high quality demosaic and denoise GPU filters. That's why dng processing in Fast CinemaDNG is faster than in Resolve. And this is the reason why it is useless for us to boost MLVFS with GPU. The most heavy tasks are perfomed by rendering application, not by MLVFS.

Fast CinemaDNG can produce synchronized proxy, CinemaDNG and audio from MLV. But still you have to process DNGs in Resolve, that wouldn't be as fast as mp4, h.264 or ProRes processing.
Post by: 12georgiadis on August 23, 2018, 08:22:26 PM
I don't think that MLVFS is the slowest processing module. If you disable focus dots removal with chroma smooth, the only task for mlvfs is to find frame data block on disk, to generate dng header and to send it to application. These stages are not CPU hungry, their speed is rather limited by HDD performance.

DNG processing is slow because of demosaic and denoise stages. High quality demosaic and denoise algorithms are CPU hungry. We've managed to develop extremely fast and high quality demosaic and denoise GPU filters. That's why dng processing in Fast CinemaDNG is faster than in Resolve. And this is the reason why it is useless for us to boost MLVFS with GPU. The most heavy tasks are perfomed by rendering application, not by MLVFS.

Fast CinemaDNG can produce synchronized proxy, CinemaDNG and audio from MLV. But still you have to process DNGs in Resolve, that wouldn't be as fast as mp4, h.264 or ProRes processing.

Ok very interesting answer. I have another proposition :
If you add a feature to import xml/fcpxml/aaf, we can import the timeline’s information at the end of the edit and detect by the clip name only the clips that have been used in the edit. This way, we process the edited files and still save a lot of storage (for a doc, we often use 1/30 of rushes or less). Plus it’s automatic and a sort of conformation / consolidate combo. Do you think it’s possible ?

Envoyé de mon iPhone en utilisant Tapatalk
Post by: megapolis on August 24, 2018, 11:39:09 AM
Quote
Ok very interesting answer. I have another proposition:
If you add a feature to import xml/fcpxml/aaf, we can import the timeline’s information at the end of the edit and detect by the clip name only the clips that have been used in the edit. This way, we process the edited files and still save a lot of storage (for a doc, we often use 1/30 of rushes or less). Plus it’s automatic and a sort of conformation / consolidate combo. Do you think it’s possible?

We understand that with MLVFS you have just one source, which is finally processed with Resolve, so you spend less HDD storage, but processing is slow due to both MLVFS and Resolve.

As we see, you would like to get fast MLVFS to solve your problem. With such MLVFS you will still process DNG not very fast due to Resolve. Unfortunately, that feature is outside the scope of our software. We process both DNG and MLV directly. For your task you can temporarily save DNG series to process them fast with our software.
Post by: 12georgiadis on August 24, 2018, 02:17:50 PM
We understand that with MLVFS you have just one source, which is finally processed with Resolve, so you spend less HDD storage, but processing is slow due to both MLVFS and Resolve.

As we see, you would like to get fast MLVFS to solve your problem. With such MLVFS you will still process DNG not very fast due to Resolve. Unfortunately, that feature is outside the scope of our software. We process both DNG and MLV directly. For your task you can temporarily save DNG series to process them fast with our software.
@megapolis,
It is a good summary of my previous hypothesis. I perfectly understood that resolve is the problem and that your software is the fastest to process direct dng/cdng.
There is stills another way to bypass resolve’s problem. If you add a feature that import xml/aaf/fcpxml and reconnect to the mlv, it can be amazing.
1) if I shoot 100hours of shooting and at the end I have a 1hour film, do you think it’s a good idea to process all Mlv files in dng before the edit ? No, especially if you have proxy h264 (for now only with 5dmkiii but it could be generalized if lossless 8...11 is done on digic4/5/6 caméras). This way you can edit with it and save storage + time !
2) so the reliable solution is to process direct mlv in your software with only the clips that have been edited in the timeline after the editing in proxy h264. To reference automatically the clip used in the timeline, we use Xml / aaf / fcpxml. It avoids the need to reference by hand and one by one the clips and then import it in your software. If you add an import feature with xml/aaf/fcpxml, we can have all the used clip in the batch list automatically. A timeline of one hour, it can go up to 400 clips. So, it’s better to do it automatically, like it’s done in cinema since 1990 with the Analog roll / proxy video clip and EDL/avid.

Ideally, we could pre-grade these clips and export in ProRes cine-log to have good performance in resolve.

Envoyé de mon iPhone en utilisant Tapatalk
Post by: megapolis on August 26, 2018, 09:38:08 AM
Quote
It is a good summary of my previous hypothesis. I perfectly understood that resolve is the problem and that your software is the fastest to process direct dng/cdng.

If this is the case, why are you going to process dng/cdng in Resolve? You can process mlv at FastCinemaDNG and get output with any intermediate codec to work with further. This is the way to bypass mlv reading and dng debayering at Resolve. Yes, you will need more HDD space (though not too much due to compression), but you will not work with mlv/dng at Resolve anymore. Why don’t you consider that approach?

Quote
There is stills another way to bypass resolve’s problem. If you add a feature that import xml/aaf/fcpxml and reconnect to the mlv, it can be amazing.

I agree that this is one more possible way to solve the problem, but it’s not simple. We will need to get into xml/aaf/fcpxml formats and at the moment we don’t have such experience.

Quote
1) if I shoot 100hours of shooting and at the end I have a 1hour film, do you think it’s a good idea to process all Mlv files in dng before the edit ? No, especially if you have proxy h264 (for now only with 5dmkiii but it could be generalized if lossless 8...11 is done on digic4/5/6 caméras). This way you can edit with it and save storage + time!

I think that still it’s a viable idea, as soon as there is a reason to preview all your footages with maximum image quality and at full resolution, not just with proxy h264.

Quote
2) so the reliable solution is to process direct mlv in your software with only the clips that have been edited in the timeline after the editing in proxy h264. To reference automatically the clip used in the timeline, we use Xml / aaf / fcpxml. It avoids the need to reference by hand and one by one the clips and then import it in your software. If you add an import feature with xml/aaf/fcpxml, we can have all the used clip in the batch list automatically. A timeline of one hour, it can go up to 400 clips. So, it’s better to do it automatically, like it’s done in cinema since 1990 with the Analog roll / proxy video clip and EDL/avid.
Ideally, we could pre-grade these clips and export in ProRes cine-log to have good performance in resolve.

I agree that this is an ideal case, but I can’t tell you when it could be ready. Currently we are also working on server version of Fast CinemaDNG and it will work with multiple clips, multiple GPUs and with scripting. Your suggested workflow in not included yet, but I think that it could be possible.
Post by: 12georgiadis on August 26, 2018, 06:49:20 PM
If this is the case, why are you going to process dng/cdng in Resolve? You can process mlv at FastCinemaDNG and get output with any intermediate codec to work with further. This is the way to bypass mlv reading and dng debayering at Resolve. Yes, you will need more HDD space (though not too much due to compression), but you will not work with mlv/dng at Resolve anymore. Why don’t you consider that approach?
Thank you for your answer Megapolis. That’s what I meant. Editing h264 on an NLE, exporting xml/aaf/fcpxml to preserve the in/out of each clip, order and name clip, import xml etc. To fast cinema dng, conform (offline h264 to Online MLV), get the list clips used in the editing, make pre-correction on mlv (debayering, chromasmooth, dot removal, vertical stripes, dark frame...), export in ProRes c-log, conform from xml/aaf/fcpxml, reconnect the timeline editing with ProRes, color grade, import mix, export master to any deliverable.
[/quote]

I agree that this is one more possible way to solve the problem, but it’s not simple. We will need to get into xml/aaf/fcpxml formats and at the moment we don’t have such experience.

I think that still it’s a viable idea, as soon as there is a reason to preview all your footages with maximum image quality and at full resolution, not just with proxy h264.

Most of the time Editors & directors currently Edit offline and don’t need maximum quality to preview. A color grader need the best quality Most of them are working on resolve. So we need to do a conformation. That’s why I suggested to do the transcode from mlv to ProRes after the edit (to save storage & time) by importing an xml in fast cinema dng and then reconnect it in resolve. Resolve is a finishing software. We grade, we’re assembling the mix and exporting the masters. All this process need to be done automatically.
[/quote]

I agree that this is an ideal case, but I can’t tell you when it could be ready. Currently we are also working on server version of Fast CinemaDNG and it will work with multiple clips, multiple GPUs and with scripting. Your suggested workflow in not included yet, but I think that it could be possible.
Could you explain more the advantage of a server version ?
For the rest, it would be more than necessary to include it. It’s essential for a good cinema workflow. Offline/online is just the standard, as well as XML/aaf/fcpxml. We cannot transcode everything even if it’s compressed. It’s doubling the online storage. It’s ok if you have to generate intermediate from timeline’s file. Not the best for a production but it’s ok for storage’s cost. If you need some case examples of workflow, I can send it to you. I worked for feature and shorts with some very original & exotic workflows but in all cases, for time and money, offline/online was used.

Envoyé de mon iPhone en utilisant Tapatalk
Post by: 12georgiadis on August 26, 2018, 06:57:46 PM
@megapolis :
For cameras without h264 proxy’s, the ideal workflow would be :
1) shoot mlv
2) import in fast cinema DNG and export all footage to ProRes proxy (36mbit) (it’s one step more than with 5dmkiii)
3) edit in NLE
4) export the editing in xml/aaf/fcpxml
5) import xml/aaf/fcpxml in fast cinema dng, pre-correct, export ProRes c-log (444 or above)
6) conform in resolve with ProRes c-log, grade and export master.

Envoyé de mon iPhone en utilisant Tapatalk
Post by: megapolis on August 26, 2018, 09:51:50 PM
Quote
Could you explain more the advantage of a server version?

That solution is not yet ready, so it’s not worth speaking about advantages. We are working on the software which will work as a server, without GUI, to process big quantities of frames on one or several GPUs. As soon as we could have many different workflows, we need to develop scripting to be able to cope with different tasks. This is concerned not only with mlv/dng, but also with much more solutions for massive image processing.
We already can process mlv/dng over network, so there is no need to copy raw data to your local PC if your network is fast enough.

Quote
If you need some case examples of workflow, I can send it to you. I worked for feature and shorts with some very original & exotic workflows but in all cases, for time and money, offline/online was used.

Thanks for your suggestion. We will need your examples, and it would be better to start from standard, non-exotic workflow.

Quote
For cameras without h264 proxy’s, the ideal workflow would be:
1) shoot mlv
2) import in fast cinema DNG and export all footage to ProRes proxy (36mbit) (it’s one step more than with 5dmkiii)
3) edit in NLE
4) export the editing in xml/aaf/fcpxml
5) import xml/aaf/fcpxml in fast cinema dng, pre-correct, export ProRes c-log (444 or above)
6) conform in resolve with ProRes c-log, grade and export master.

There is also an opportunity to create MP4 with our software and FFmpeg at step #2,  then you won’t have any problems with storage.
Post by: 12georgiadis on August 26, 2018, 10:53:01 PM
That solution is not yet ready, so it’s not worth speaking about advantages. We are working on the software which will work as a server, without GUI, to process big quantities of frames on one or several GPUs. As soon as we could have many different workflows, we need to develop scripting to be able to cope with different tasks. This is concerned not only with mlv/dng, but also with much more solutions for massive image processing.
We already can process mlv/dng over network, so there is no need to copy raw data to your local PC if your network is fast enough.

Thanks for your suggestion. We will need your examples, and it would be better to start from standard, non-exotic workflow.

There is also an opportunity to create MP4 with our software and FFmpeg at step #2,  then you won’t have any problems with storage.
Mp4 is gop Ibp codec. It’s not
Optimized for editing. ProRes proxy is 36 mbit, just a little bit more than dv bitrate. It’s widely used. Mp4 proxy is ok because this is the only option possible With a 5dmkiii. But if we can choose, it’s definitely better An i-frame based codec for performances

Envoyé de mon iPhone en utilisant Tapatalk
Post by: 12georgiadis on August 26, 2018, 11:04:46 PM
That solution is not yet ready, so it’s not worth speaking about advantages. We are working on the software which will work as a server, without GUI, to process big quantities of frames on one or several GPUs. As soon as we could have many different workflows, we need to develop scripting to be able to cope with different tasks. This is concerned not only with mlv/dng, but also with much more solutions for massive image processing.
We already can process mlv/dng over network, so there is no need to copy raw data to your local PC if your network is fast enough.

Thanks for your suggestion. We will need your examples, and it would be better to start from standard, non-exotic workflow.

Ok for server solution.
For workflows give me a contact e-mail and I send you some pdfs.

Envoyé de mon iPhone en utilisant Tapatalk
Post by: 12georgiadis on August 26, 2018, 11:32:28 PM

(https://www.magiclantern.fm/forum/proxy.php?request=https%3A%2F%2Fthumb.ibb.co%2FjHA3Hp%2FCapture_d_e_cran_2018_08_27_a_00_26_12.png&hash=3417ec695728b2db65e4fb003b62ae21) (https://ibb.co/jHA3Hp)

one example of my previous film
Post by: megapolis on August 27, 2018, 12:04:45 AM
or you can send PM to me.
Post by: bouncyball on September 01, 2018, 11:04:30 AM
Quote
Fast CinemaDNG Processor for Linux Ubuntu 16.04, 64-bit - expected at August 2018

August has gone ;)
Post by: 12georgiadis on September 01, 2018, 12:19:47 PM
or you can send PM to me.
check on MLV app threads. Features have been implemented with FCPXML. Still some tests to do from Resolve => Pr CC / Avid MC to convert fcpxml to xml/aaf.
Post by: megapolis on September 01, 2018, 01:55:43 PM
@bouncyball
Yes, August has gone, but Linux solution is not yet ready. I'm sorry about that. I will let you know as soon as it's ready.

Thanks, I've read this thread. I will write here when we could do that.
Post by: megapolis on September 04, 2018, 12:15:03 PM
For your suggested workflow we need the following for testing: several MLVs, corresponding proxies, and fcpxml that you got from these proxies. Could you please send us several examples?
Post by: Kharak on October 18, 2018, 01:47:42 PM

These are my "first" impressions/findings. A lot of this might come down to user error.

First of I cant import anything, when I click to find a file path, be it add files to project or change the 3D Lut Directory the program stops responding and I have to exit. I can basically only choose which features I want, set up the project, go to options and change anything except Path's.

The only way I get to play around with the program is by opening an old project from an older version (ver. from Early Summer) where I have a DNG sequence imported, sucks as its not a very flattering shot. But I cant figure out how to change the current project settings, seems like one cant change Project settings in existing projects. So to change settings I need to make a new project which will require me to import files again and that will crash the program.

I am very interested in importing an MLV to test out the MG debayering. So far I only have the DNG sequence to play with and that one is already converted from mlv_dump with Amaze. Now I am not sure if the Amaze debayering is baked in the DNG's and therefore applying MG Algorithm is messing with the image. I say this, because when watching the sequence in Fast CinemaDNG the Red Channel is messed up badly with round/circle Dots all over it. But when I export it again as DNG sequence and either preview a frame in Windows photo viewer or Resolve, the dots are gone, this is perhaps down to how Photo Viewer and Resolve debayer the DNG's.. I don't know. But I'd like to make a direct comparison between the output of MLV_dump and Fast CinemaDNG.
I also think the WB is skewed after exporting DNG, as the shot I am playing with is daylight WB so around 5500, but to get accurate WB I have to push it to 4800k in Resolve. (kinda like MLV App does when viewing MLV's).

I also tried De-noising to see if I could remove the dots in the red channel. Tried a combination of all the options, denoise, raw denoise etc.. It seems to help a little with the Dots but ends up being detrimental to the rest of the image. Also because the 5 vertical sliders dont have any information I am not entirely sure what they do, what is positive or negative value? As the Sliders start in a centered position, I can assume that the slider furthest to the left is High Frequency and furthest to the right is Low frequency as that is how the image seems to react, but cant be entirely sure. Also in the Common tab, with the two Wavelet Types I dont notice any difference, except a few ms in the benchmark, decomp level, higher is more aggresive?

Does Increasing Max Y. Treshold in Common make the increments finer or does it increase the power of the threshold?

The Help System is well categorized, but the Denoise info is confusing as it seems you've changed the names of the two denoise methods, also according the the embeded images in the Help Systems which have different names again than the Text ensues.
Quote
5.13  Denoising

in the software there are two denoising modules which could be applied independently. Both of them are wavelet-based, but the first one (RAW spatial denoiser) is applied for RAW data before demosaicing and the second one (RGB spatial denoiser) is applied to color data right after demosaicing. Denoiser in time domain is under development and is expected soon.

It is possible to suppress spatial noise for each channel of Raw Bayer image before applying demosaicing. We split Raw Bayer image into 4 planes according to Bayer pattern and then remove spatial noise for each plane separately. Parameters: wavelet name, threshold function, number of DWT resolution levels, array of denoising thresholds for each wavelet band.

There is also an opportunity to suppress spatial noise for luma and chroma. We convert RGB data to YCbCr before denoising. Parameters: wavelet name, threshold function, number of DWT resolution levels, array of denoising thresholds for each color component and for each wavelet band.

Which of the Denoisers is the RAW Spatial denoiser and which one is RGB? in the Help System it says the first denoise is RAW Spatial denoising, but in the Denoising tab, RAW Denoiser is second and the first one is just called Denoiser. And again, the lack of information on the sliders is confusing. I would prefer them with their proper names or something more specific e.g. "Raw Spatial Denoising" or "Pre-Debayering Noise reduction". And a suggestion, not that I know exactly how your De-Noiser works, but in my experience separate R G B channel de-noising always works wonders with Bayer patterns as the Canon Bayer patterns (and most others I believe) always contain more Green pixels than red and blue, so green channel always has way less noise than red and blue channel. Just something I found gave good results in Neat Video, lowering the Green channel curve which has helped retaining a lot of information..

Just a general question. Are there any parameters that will not affect the picture if exporting to DNG? will colour space affect the DNG output? Like MLV App has a bunch of parameters that will not affect the image if exporting to DNG as the output will be RAW, how is it with Fast CinemaDNG? Which parameters if so?

Other than that, the program is very fast! with or without Denoising it runs at full speed.

Let me know if you want some Screenshot or anything, I will PM you then.
Post by: megapolis on October 18, 2018, 05:53:30 PM
@Kharak

Quote
First of I cant import anything, when I click to find a file path, be it add files to project or change the 3D Lut Directory the program stops responding and I have to exit. I can basically only choose which features I want, set up the project, go to options and change anything except Path's.

You are right – this is the way to open DNG series from selected folder, but it doesn’t work for MLV files. Usually we drag-n-drop MLV file or folder with DNGs from Windows Explorer to player window of our software. Or you can do right button click on MLV file or on folder with DNGs to load data via context menu. Folder for 3D LUTs is correct and this is the path for 3D LUTs that we supply with our software. You can choose another path to a folder with your 3D LUTs in .cube format.

Quote
I also think the WB is skewed after exporting DNG, as the shot I am playing with is daylight WB so around 5500, but to get accurate WB I have to push it to 4800k in Resolve. (kinda like MLV App does when viewing MLV's).

When we do DNG export, we don’t change any raw data, WB or color matrixes. Actually we can do that, but we don’t. Please show me your example for checking.

As far as concerns denoising, we apply wavelet-based algorithm. If we say "Raw denoise", it means that it’s applied to raw data. Usual denoiser is also based on wavelets and we apply it to RGB. You are right, RAW Denoiser should be on the left. We will also check the content in the Help for denoising. Thank you.

I’m sorry, noise suppression for a separate raw channel is not working at the moment. Interface for that solution is quite complicated and we haven’t done it yet. The software is ready, but the interface is not. There is also one more opportunity to control raw data by applying raw curves before raw denoising. It’s working.

Quote
Raw Spatial Denoising" or "Pre-Debayering Noise reduction".

These names are ok, but they are too long for tabs. We will check what could be done here.

Quote
Just a general question. Are there any parameters that will not affect the picture if exporting to DNG? will colour space affect the DNG output? Like MLV App has a bunch of parameters that will not affect the image if exporting to DNG as the output will be RAW, how is it with Fast CinemaDNG? Which parameters if so?

At the moment we export DNGs as is, without any raw transforms, we can just change compression method and we can cut raw image. Though some users ask us to include raw curves and raw denoiser to DNG export pipeline. I think we will do that in the future, it makes sense in some situations.
Post by: megapolis on October 23, 2018, 01:24:52 PM
Post by: megapolis on November 20, 2018, 01:59:35 PM
Development of the first stable release of Fast CinemaDNG Processor software is over – version 1.0.0 is ready and it could be downloaded here:
Post by: bouncyball on November 28, 2018, 03:51:13 PM
Sad. There is still no Linux version available...
Post by: megapolis on January 22, 2019, 08:53:59 AM
We've added dark frame subtraction and flat-field correction to Fast CinemaDNG Processor software. Currently we can use prepared images in PGM format for dark frame and PPM/TIFF for flat-field, GUI for calibration procedures will be added soon.
to @bouncyball: we do remember about Linux version, sorry for the delay.
Post by: Lars Steenhoff on January 22, 2019, 10:24:18 AM
Would love a Mac version too  :)
Post by: megapolis on January 22, 2019, 10:44:24 AM
We will do that as soon as Apple start to work with NVIDIA. For our software we need PC/laptop with NVIDIA GPU.
https://www.forbes.com/sites/marcochiappetta/2018/12/11/apple-turns-its-back-on-customers-and-nvidia-with-macos-mojave/#12df8b7337e9 (https://www.forbes.com/sites/marcochiappetta/2018/12/11/apple-turns-its-back-on-customers-and-nvidia-with-macos-mojave/#12df8b7337e9)
Post by: Lars Steenhoff on January 22, 2019, 11:01:44 AM
Nvidia works on High sierra with pascal Nvidia GPU's for example 1080 ti works with Nvidia web drivers in E-gpu enclosure or in Mac pro 5.1
Cuda also works in high Sierra

( I have tried both and they work well )

I hope Nvidia will be able to release the web drivers for the 2080 cards soon.
because it's a shame how apple is dealing with this situation, I understand your not willing to invest time in an uncertain platform.

But I love my MacBook Pro and I have a 1080ti ordered for my sonnet e-GPU enclosure.
Post by: megapolis on March 30, 2019, 11:57:11 AM
Now it's based on CUDA-10, so please update your NVIDIA driver before running the software.
Post by: megapolis on May 24, 2019, 09:49:20 PM
We’ve implemented a new version of dark frame subtraction and flat-field correction in Fast CinemaDNG Processor software. As usual, everything is done on GPU, so it’s quite fast.

We can apply flat-field correction (FFC) and dark frame subtraction by providing two corresponding linear RAW images in PGM or DNG format. To prepare these images from DNG files we can use dng_validate.exe utility from DNG SDK.
This is a command line to get FFC image: dng_validate -16 -2 FFC <path\to\dng>

This will extract 16-bit linear RAW data into FFC.tiff. The FFC and dark frame width and height must be exactly the same as width and height of the processed RAW file. Otherwise the correction will not work.
To supply FFC and dark frame files, click “...” buttons next to “Dark frame” or “FFC frame” field. To temporary disable correction, uncheck “Enable dark frame and flat field correction” check box.
To disable whole FFC and dark frame corrections, uncheck "Dark frame and flat field correction" check box in the application processing options.

Post by: theBilalFakhouri on June 18, 2019, 01:09:08 AM
Hi @megalopolis

Will there be GPU Dual ISO processing for MLV in future? Any plans for that?
Post by: megapolis on June 18, 2019, 01:14:22 PM
Dual ISO feature is very interesting, but I'm not sure that we will be able to implement it soon on GPU. Hopefully, we will release soon some other features like automatic bad pixels correction, defringe and some more.

We are doing quite a lot of other projects with GPU image processing, not only for MLV/DNG. You can see more info here:
https://www.fastcompression.com/blog/content.htm (https://www.fastcompression.com/blog/content.htm)
Post by: theBilalFakhouri on July 02, 2019, 04:34:15 PM
Cool

Why it's so hard to add H.264 export settings or Prores ? :'(

Also The audio isn't synced when exporting MotionJPEG , when viewing MLV in fastcinemadng.exe it's synced properly , also what method are you using to fix focus pixels ? it's make the app very slow (viewing the MLV) when enabling it and isn't it better to add support for focus pixels maps instead of processing the whole image ? , it would be cool!

Also playback MLV or DNGs with audio mute is very smooth but when the audio on it's skipping frames or choppy , is the audio needs a lot of processing or something else happening ?

Thanks
Sorry for the Alsos  :P
Post by: megapolis on July 02, 2019, 09:15:48 PM
@theBilalFakhouri
Thanks for your info. At the moment H.264 or ProRes could be added via external FFmpeg only. It’s not really hard. You need to specify output format as FFmpeg and then set correct command line for FFmpeg. Not ideal, but looks acceptable.

Thanks, we will check audio output synchronization for Motion JPEG. It’s also done via FFmpeg.

Focus pixels we are correcting on CPU and you are right that it’s slow. We haven’t finalized the algorithm yet, so we don’t have GPU version.

Currently we are doing Bad Pixel Correction (BPC) on CPU as well. This is adaptive averaging over 5x5 window for RAW data. Within a couple of weeks GPU-based version should be ready. At the moment we are utilizing CPU version for testing.

I think that dynamic BPC is much better than pixel maps. There are different types of bad pixels (hot, dead, bright, etc) which could be seen in different situations. So it’s quite difficult to create precise map for all these cases. There is also image sensor degradation, so we have new bad pixels to come out. Our BPC is working as impulse noise filter and quite often it corrects 5,000-10,000 pixels per 10-20 Mpix image, which we think to be good. We expect that total time for BPC will be really small on GPU, though right now we do that on CPU and it’s slow.

MLV (DNG) playback with audio implies that for a particular audio packet we will process corresponding RAW frame without any delay. This is not always the case even on GPU and this is the reason why we see such jerks. We could probably do some prefetching to fix that issue. Audio doesn’t need a lot of processing and at the second run it should work smoothly.
Post by: megapolis on September 06, 2019, 10:46:45 AM
We’ve added the following fixes and new features to the Fast CinemaDNG Processor software:

1. Dynamic bad pixel correction on GPU. There is no need to have a list of bad pixel coordinates, the software can find and interpolate bad pixels in realtime at RAW domain. On NVIDIA GeForce GTX 980 we need around 1 ms to remove bad pixels from 12-bit 12-MPix image. We used to have that feature on CPU and now we’ve implemented it on GPU. It’s working with 8-16 bit raw images (bayer and grayscale).
2. Apple licensed their ProRes encoder to us, so we’ve included Apple ProRes support on CPU. Now we can export processed frames to original Apple ProRes 422 LT, 422, 422 HQ, 4444, 4444 XQ. We can offer MLV to ProRes and DNG to ProRes transforms.
3. Motion JPEG output encoding on GPU now is working well with audio.
4. We can store JPEG and TIFF images to SSD in a separate thread after GPU processing, so total processing time is better now.

Post by: megapolis on October 15, 2019, 03:22:20 PM
In the latest version of Fast CinemaDNG Processor software we’ve implemented native support of BRAW format from Blackmagic Design. Apart from BRAW Player, there is an option for BRAW export to CinemaDNG. It’s working quite well, but not perfect. To the best of our knowledge, this is the only solution for raw export from BRAW footages. Please download and test the software. Your feedback is welcome.
https://www.fastcompression.com/blog/braw-player.htm (https://www.fastcompression.com/blog/braw-player.htm)
Post by: ilia3101 on October 15, 2019, 04:19:52 PM
wow! I have heard Blackmagic say BRAW is an open standard, but I can't find any info or specifications about it, so I am starting to suspect it is not true. Did you find the spec? Or did you figure out how it works by yourself?

Also glad to hear that it's not actually "partially debayered", I guess they just say that to avoid trouble with RED (fair enough).
Post by: megapolis on October 16, 2019, 11:54:31 AM
I can’t really call BRAW to be an open standard. Unfortunately we can’t find BRAW format specification either, we can see just Blackmagic SDK manual, that’s all. The manual doesn’t include that spec, this is the problem.
Sure, you can do a lot with Blackmagic SDK, but you are supposed to work with processed images because Blackmagic has already done decoding and raw processing. This is the idea they are trying to push.
As far as concerns “partially debayered” data, it also sounds strange, because hardware capabilities of BMD cameras just can’t be compared to modern CPU or GPU, so this could hardly be partial debayering. It looks like an approach for specific data representation which is more suitable for fast lossy compression in camera hardware.
If I remember it right, RED has patented in-camera compression with wavelets, so the situation with BMD doesn’t look the same.
Post by: ilia3101 on October 18, 2019, 10:18:41 PM
Thanks for confirming my suspicion that it is not an open standard. So Blackmagic are kind of lying. Also I asked on the BM forum and just got a response today: https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=100646

I see on your website that you figured out that is a custom MOV container. Are you using blackmagic SDK with some hacks to get bayer data? Or have you figured out all the BRAW reading yourself?
Post by: Luther on October 19, 2019, 02:00:48 AM
got a response today: https://forum.blackmagicdesign.com/viewtopic.php?f=12&t=100646
Heh, they have no clue what "open" means. This is why you can't let marketing guys take care of technical terms.
Quote
Blackmagic RAW is defined as an Open Standard because it is cross-platform and open for anybody to include in their products/develop with using our free SDK.
Post by: megapolis on December 06, 2019, 06:51:09 AM
We’ve released open source project PGM2DNG to transform raw images from PGM format to DNG. You can get more info and source codes at
https://github.com/fastvideo/pgm2dng (https://github.com/fastvideo/pgm2dng)
We need to convert PGM to DNG to be able to process them with our Fast CinemaDNG Processor software. Usually this is the case with machine vision and industrial cameras.
Post by: megapolis on March 17, 2020, 08:00:57 AM
New features at Fast CinemaDNG Processor software:
1. Improved BRAW processing for BMPCC 4K and 6K
2. Support for Canon CR2 and CR3, Nikon NEF formats

Post by: megapolis on May 04, 2020, 08:30:27 PM
We’ve released Linux version (Ubuntu 18.04, 19.10, 20.04) of Fast CinemaDNG Processor software which is working on NVIDIA GPU. It includes all features which we already have in Windows version, including the following:
1. Smooth RAW Video Player for MLV, DNG, BRAW
2. RAW transforms: MLV to DNG, BRAW to DNG, DNG to DNG
3. MLV / BRAW / DNG to JPEG/TIFF/EXR
4. Output to authentic Apple ProRes 422 LT, 422, 422 HQ, 4444, 4444 XQ
5. Bad pixels removal, dark frame subtraction, FFC, wavelet-based denoiser
6. Support of DCP and LCP profiles, 1D and 3D LUTs
7. Improved performance for NVIDIA Turing GPUs (RTX series)
8. Interoperability with external FFmpeg