Messages

not working with AAF

My guess is that it might be helpful if you added how you test it.

@ marekk
Could you add a link to the automatic builds in the first post, so it would be easy to find?

@ Chucho
Looks like a very interesting finding. I wonder what the devs can make of it?

If you look at the Filename in the Resolve's Media Pool the DNGs are called: M07-1257_[00000_000451].dng
But the exported proxies are called M07-1257_00000.mov

What happens if you limit the source filename to max 14 characters? (When using Reel Names in EDL files there is a limit of 8 characters)

If there is a reel name tag for cdng too, I would suggest using the embedded file creation time as time code and the date as reel name as defaults(most softwares only read first 8 characters of reel name tags).

A quick test with a file from a 60D in Movie mode, a couple of ML builds back: http://we.tl/4Mv47vaiRS

There seems to be a bug in 12 bit + 15% unchecked which makes the screen black with green monocrome highlights.

(*) batchmode is coded
(*) most code is rewritten
(*) no more 14bit-output, because not needed
(*) blacklevel and whitelevel read from raw-data
(*) colormatrix read from raw-data

(+) sitting on 12bit linear mode - after finishing that, exe will be published

Great to hear you're making progress. Thank you for investing your time in this much needed tool. Now you have succeeded with the 14 to 12 bit conversion, I can't help my curiosity on the question of this process is too heavy to implement in camera or not(as discussed in the 12/10 bit conversion thread), but I guess it is premature to ask those questions. 

If you consider an update/change of the raw/dng format,  please consider to include creation time and date, because this data then can be used for embedded time code and reel name in the later process.

Dcraw is a command line tool which can read a text file with texture coordinates for each pixel and fix them. The downside is that you'll have to make the text file manually.

File example:
http://www.cybercom.net/~dcoffin/dcraw/.badpixels

Thank you for your insights. Like you I love Avisynth, but it is probably better to accept it's limitations for now.

EyeFrame 1.8.0 is out with more RAW speed improvements.

Get it here:
eyeframe.tk

Here's a bit of the docs:

Common parameters

string filename : The path (both relative and absolute are okay) to the file to be read or written to.
No default, must be specified.

format : This specifies the format of the raw file. Options are:

"RGB" or "rgb" - 24 bits per pixel (3 bytes) in order. When reading a raw file, the output of the filter is an RGB24 clip.
"BGR" or "bgr" - 24 bits per pixel (3 bytes) in order. When reading a raw file, the output of the filter is an RGB24 clip.
"RGBA" or "rgba" - 32 bits per pixel (4 bytes) in order. When reading a raw file, the output of the filter is an RGB32 clip.
"ARGB" or "argb" - 32 bits per pixel (4 bytes) in order. When reading a raw file, the output of the filter is an RGB32 clip.
"BGRA" or "bgra" - 32 bits per pixel (4 bytes) in order. When reading a raw file, the output of the filter is an RGB32 clip.
"ABGR" or "abgr" - 32 bits per pixel (4 bytes) in order. When reading a raw file, the output of the filter is an RGB32 clip.
"Y8" or "y8" or "GREY" or "grey" or "GRAY" or "gray" - 8 bits per pixel (1 byte) greyscale. When reading a raw file, the output of this filter is a YV12 clip, with all colour information set to neutral. Native Y8 content is not presently supported in AVISynth (planned feature for v2.6, current version at time of development is 2.58).
No default, must be specified.
packing : A packing format string, FEATURE IN BETA - PLEASE REPORT ISSUES.
The format is a list of of triples, optionally with whitespace, separated by semicolons. Each triple (the second and third numbers are optional) spells out the total number of bits, then inside that total, how many to skip, and how many to use, ie:
"total:skip:use; total2:skip:use2; etc".
So in a total of 12 bits, if you want to skip the first 3, and use the next 5 (ignoring the last 4), you would use "12:3:5" - that's XXX4 3210 XXXX to give the bit positions.
Because AVISynth only keeps / represents 8 bits, the "use" value will be treated as 8 even if more is specified. More can be specified because it makes specifications much easier to write, and because future versions of AVISynth might allow more.
The packing resets at the end of every row, so trailing bits are skipped over and the next row starts at the next full byte.
Any packing specified for a planar format will be applied equally to each plane, not to the elements of the plane in order, so if you have, for example, 12-bit luma, but 8-bit chroma, you will need to read or write your file in multiple passes. See Read Exotic and Write Exotic.
Examples:

16-bit "High Colour" is packed as 5 bits of red, then 6 bits of green, and 5 bits of blue. The packing string is "5;6;5", equivalent to "5:0:5; 6:0:6; 5:0:5". Format "RGB".
10-bit v210 raw format would be "12:2:10; 10; 10" (the repeating happens for free). Format UYVY I think - I can't obtain a sample file. Use RawReadInterleaved("UYVY") or RawReadInterleavedUYVY() or RawWriteInterleaved("UYVY") or RawWriteInterleavedUYVY().
16-bit video is not a good example - you can just load it without a packing string and use TurnRight().AssumeFrameBased().AssumeTFF().SeparateFields().SelectEven().TurnLeft(). It may even be faster - you'd have to benchmark it. If you want to use it, say packing="16:0:16" or "16:0:8" - they're equivalent.
Default = No string, or "". Packing defaults to 8-bit samples.
filehead : When reading, it is the length (in bytes) of a file header to skip over. When writing, Sashimi will insert this many null bytes at the start of the file.
Default = 0.

framehead : When reading, it is the length (in bytes) of a a frame header to skip over. When writing, Sashimi will insert this many null bytes before each frame of data.
Default = 0.

So maybe it is just a question of how the ML RAW is packed and specify it for the plugin. Is there anywhere I can find this info?

I came across a plugin which deals with all sorts of RAW files: https://sites.google.com/site/ourenthusiasmsasham/soft#TOC-Sashimi
The docs are quite detailed of various raw formats and also on bitrate conversion(source included too).

This shows some resemblance with the original image, but I haven't found the correct way to open the files yet.

Code Select Expand

LoadPlugin("Sashimi.dll")
RawReader("M03-1651.RAW", "RGB", 1280,720,packing="14")

There is a packing parameter, but I don't know the "packing" of Magic Lantern Raw. Would be great if Avi/Vapour-synth could import those files for further correction.
Avisynth is 8 bit only, but Vapoursynth supports higher bitrates too.

The thread on doom9.org: http://forum.doom9.org/showthread.php?t=154830

Uploaded an improved version(same version number) with a bit faster RAW import thanks to A1ex: http://www.magiclantern.fm/forum/index.php?topic=5404.msg47583#msg47583

The included default dcraw 16 bit setting seems to get rid of the pink cast on the RAW video shot on a 60D.

He he, this works!   

Thanks!!

I'm not sure I understand. Without -o I'm only specifying the import folder/file(which also is the output folder/file).

What I'm asking is the option to specify a different output folder than the source folder.

raw2dng "sourcefolder" "outoutfolder" - isn't that read as two source folders?

EDIT:
Just tested that with the latest raw2dng:

Code Select Expand

raw2dng myraw.raw myfolder
Myfolder was already created, but the resulting dng files ended up in the same folder as the myraw.raw file.

EDIT2:
raw2dng "C:\Users\user\Desktop\myraw.raw"
Places the files in the location of raw2dng. 

Would it be possible to add -o "output dir" to the command line options of raw2dng?

Then it wouldn't be necessary(takes time) to copy the source RAW files to the same folder as raw2dng before processing them.

@RAW2GPCF
I'm using this command line:

Code Select Expand

"C:\Program Files (x86)\GoPro\Tools\RAW2GPCF" C:\Users\user\Desktop\RawFiles\Raw\M01-1120.RAW C:\Users\Public\Documents\Video\aa.mov
In cmd it runs and ends fine with done, but there is no resulting file? I wonder why, could it be that the ratio isn't an HD one(60D footage)? I'm on Win 8 with CineForm Studio Premium.

EDIT: Ah, adding  '-422' makes it produce a file.

If the folder called Eyeframa Data is placed in the correct path the main Eyeframe Converter folder can be placed where you like. That doesn't make it fully portable,  but I guess you could call it moveable.

Maybe if you set the path of the data folder in the ini file you can move them where you want. The important thing is that the Eyeframe data folder must be located in a place with writing permissions for editing and saving new presets.

Had a quick look, but couldn't see any difference between 0 and 1 in the last number. 

Noticed that raw2dng writes the fps, so now it is automatically detected and added in EFC.

The dng files are straight from raw2dng. I can't change the wb on those files. Are you using the dng files?

The settings mentioned above are for dcraw.exe for creating the tiff>video files. The settings are dcraw settings google then for further explanation. However those numbers for daylight, flash etc. is just a question of what light conditions you shot in and then can correct them.

Great the the uninstaller now works! And you don't think it is that slow anymore

The white balance setting can be changed as described above: http://www.magiclantern.fm/forum/index.php?topic=2732.msg44999#msg44999

You could try with the old default setting($rawset="-v -w -T -H 2") - or look in the end of this post to find values which will fit your shooting conditions better.

Daylight: -r 2.1426, 1, 1.5488, 0
Shade: -r 2.4619, 1, 1.3193, 0
Cloudy: -r 2.3066, 1, 1.4258, 0
Tungsten: -r 1.5264, 1, 2.3428, 0
WhiteFluorescent: -r 1.9072, 1, 2.1973, 0
Flash: -r 2.3701, 1, 1.4141, 0

raw2dng and the raw file must be in the same folder. There is no destination option in raw2dng. Instead of messing around in the folder with the source files and then copy the resulting files to a new folder afterwards, I think it is more hygienic to copy the files before the processing.  I wish that raw2dng eventually would get an output path option, so this the copy step could be avoided.

I've fixed the folder dialog and uploaded a new 1.7.9.

If you open the Menu: View > Log you can see in end of the file in what process it hangs (either dng2raw or dcraw), and try to locate a newer/better version(for dcraw check the link above) and let me know if that will solve the problem of larger files.

Did you try 1.7.9?
Dcraw is not too fast, but you might be able to find a faster version which fits you system better here: https://sites.google.com/site/manuelllorens/

I'm not getting that uninstallation error here on Win 8, but I've tried to fix it and uploaded EFC 1.7.9 again. I hope this will take care of that uninstallation error(but I can check it, because I can't reproduce it here).
If that doesn't solve it and you just want to get rid of EFC then just delete the EyeFrame Converter folder in Programs, and a folder called 'Eyeframe Data'.