@tosvus I have a wide internet connection, so I can download any file size. You can use a file store services: Google Drive, Dropbox, etc. to share it. They are fast.
@spacewig a help will be published online, because also big examples will be published there to demonstrate "how-to". I have no plan to include it to a distribution. Currently no help available yet. I am focusing now to a program stability. Also I am testing it currently on a real project before publish.
@MikhailK. Wrong way at all...
"In x64 directory I renamed x264 to x264-10bit.exe" - the program will not work with a renamed 8-bit x264. Only a real 10-bit version should be used. Also x264 10 bit is already included to the coming beta (and latest alpha, as I remember). No any download and rename required to make 10 bit results.
Your steps are correct in generally, but you forgot to execute "Make.bat" files in every step (or if you use a very old alpha - "Apply"). They are necessary. This trick is a speed optimization to control every step with a comfort fps, because a lot of CPU needed to whole processing chain.
This may look complicated, but if you have a lot of long files, you get the fastest and comfort way to process them. The program is optimized for very long batch processing with many processing hours in every step.
Some important knowledge things:
An Avsi file is a project file. It contains a list of all step parameters and filters used in every step. So when click to "Add to/Make Avsi" you include these steps to that file. Also you had no any tuning steps, as I see, so your result will contain an unknown "default" set of filters. So you will get an unknown processing and an unknown result. Because no any video file extracted and created in every step (no Make.bat had executed), you had only a short black windows. These scripts execute only if any source video is available.
The correct behavior is "Add to avsi" → change processing parameters → "Make" → Go to a next step. In a coming beta version these steps are now simplier.
Also please wait the beta version. There are a lot of important bugs fixed. I.e. an incorrect color profiles used in import and export to H.264; a color shift in ut codec in RGB mode.
Version 0.8.0.Beta1, 2013-07-22
Scripts simplification and refactoring.
Default Windmotion directory is now C:\Windmotion.
All scripts and code are now in wm directory.
You can use different Windmotion versions in the same time.
Film Grain emulation functions added (Pro).
Motion-enabled fps change function FlowChangeFps added (Pro).
ResizeUp added (Pro).
Settings and user code are now in wm\inc\Settings.*.
ANSI-encoded file name support.
Support of spaces in directory names.
Better Color Matrix conversion.
Export of utcodec with correct color is added.
Qaac is used to encode aac audio for better quality (Pro).
Encode quality optimizations (Pro).
Better import with a frame lost and thread protection code over Avss LAV.
New functions FileDS and FileFF are used for import.
Sony HX20 optimized profile is improved.
Chroma Subsampling name changed in avsi and Settings.bat.
Protection against accidental undo.bat operation.
CPU use warning in Import scripts to protect a frame lost.
Edit scripts speed optimization.
GPU mode disabled by default (Pro).
LastCrop, LastResize.
Cinema Full HD, 2K and 4K resolution support.
MXF file format support for Import and Make.
Improved film and audio projects (Pro).
Webm and ogg support for Film (Pro).
New camera support: Panasonic GH3, GF1.
Panasonic GH2 mov mode support.
FakeRange renamed to NoiseRange.
New deblock function RepairJpeg8 (Pro).
Single version of avsi for all resolutions.
Default Edit avsi is now without filters applied.
Project width and height settings are removed.
Project ffmpeg thread settings improved.
Non-ringing resize to 360p for Film (Pro).
New install script and logo images.
Bugfix: Src scripts corrected (wrong matrix, incorrect bat).
Bugfix: Fixed pc range flag for x264.
Bugfix: Fixed 601 color matrix for x264.
Bugfix: Fixed color matrix for 360p Film (Pro).
Bugfix: Incorrect preview source (Pro).
Bugfix: Histogram position on cropped frames corrected.
Bugfix: AA script corrected.
Bugfix: Incorrect MAnalyse vector direction.
Bugfix: Incorrect RGB source matrix.
Bugfix: PlayEdit clipboard operations corrected (again).
Bugfix: Incorrect "\" usage in scripts.
Plugin list corrected.
Avss is changed to a LAVFilters mod.
Matroska Splitter is removed (no longer used).
UtCodec, LAVFilters, FFmpeg updated to the latest version.
TODO: Documentation in progress.
Hi @rean,
Thanks for your beta version. I've already downloaded your beta and since you didn't release any tutorial, I would appreciate if you could confirm I'm doing everything right.
I'm on Win7 64bit. I use GH2 files. My goal: to get a video file transcoded to 4:4:4 16bit.
According to these steps I got my file transcoded to Chroma Subsampling 4:4:4 and Bit depth: 8 bit!!! The new file is visually better than the original MTS and its size is much larger than the original. Why is it 8 bit and not 16 bit?
I also tried another export formats (Make DNxHD-10bit mov.bat, Make DNxHD-10bit mov.bat) and these transcoded files became: Chroma Subsampling 4:2:2 and Bit depth: 10 bit!!! The new file is visually the same as the original MTS and its size is almost the same as well. Why is it 10 bit and not 16 bit, and not 4:4:4?
I didn't use ProRes because I'm on a PC.
Am I doing something wrong?
Thank you in advance.
@MikhailK 16-bit files are not supported by export codecs. 10-bit depth is the best depth you can get.
"Make h264 mov.bat" creates a 8-bit H.264 file. DNxHD and ProRes codecs support only 4:2:2 export. There is only one possibility to get 10-bit 4:4:4 - to use H.264 10-bit codec. But, probably, any commercial software cannot read it.
Most compatible solution now is ProRes/DNxHD 10-bit 4:2:2. Most depth solution is H.264 10-bit 4:4:4.
16 bit is an internal depth, used for color correction filters. 16-bit export is really useless. Currently the largest possible bit depth range for regular camera image is from 9 to 14 bits, if you use color correction filters. But most of these additional bits are simply filled with a noise.
10..11-bit result is obtained in the case when you do a color correction to get very desaturated and washy image. 12..14-bit expansion is useless because a source quality reason.
8..9-bit result is good for regular high quality video. Additional one bit may give you rounding error space, so 10-bit is the most perfect solution, that can be usable in real projects.
To get a 4:2:2 or 4:4:4 resolution, you should use any noise reduction filter in Y, U and V channels. If it does not used, the actual resolution will be 4:2:0, the same as your source (or 4:2:2 for MJPEG cameras). In this case additional pixels will contain only a random noise or an interpolation. Also sharp may give you only H.264 artifacts. So, please note - if you really want to get something better than 4:2:0, use noise reduction in all channels.
Perhaps I've written is not clear ... I apologize, English is not my native language. I have difficulty to convey what I wanted to say.
PS. Currently I am hard working with a video project and new two-language web site (ru+en) for Windmotion, so I have no time to create any documentation. Probably I will start publish it in this week or two.
My workflow for my current project was DSLR footage -> Cineform and then edit within FCP7. How is the workflow with windmotion ? Do I need to denoise using Neat Video and then use windmotion ? So the workflow will be DSLR -> Cineform -> Neat Video -> Windmotion ?
Can you offer an output option to Cineform ? Or even to Prores ? I would be very keen on an output from 1080p or 720p to 2K 16:9 footage - with the 4:4:4 scaling applied.
@zcream, Windmotion has fine denoise filter. It should be used first, because after any other denoise filters you will destroy existing details. If you will not use it, your Windmotion usage is absolutely not required, because 4:2:0 -> 4:x:x upscale is not possible without Windmotion denoise. So, better steps are: DSLR footage -> Windmotion (crop, trim, denoise, dehalo, sharp, etc) in 4:2:2 -> ProRes or utcodec (4:2:2). Also, probably Neat Video will not be required after Windmotion denoise.
If you really want 4:4:4, use H.264 as a result.
Short Windmotion denoise "howto" (before I publish a full manual).
Usage: MotionDegrain8(clip c, clip m, int "bs", int "frames", int "th", int "limit")
Here are: c - original clip in the current channel (Y,U,V)
m - motion clip, used to restore details. These two parameters are default used for best quality. So, no any changes are required. Pro edition has a feature to tweak this motion clip to get better results in some cases.
bs - block size, used for motion calculation. Use 4 or 8 for detailed clip, 16 or 32 for very noise or less detailed clip.
frames - number of sequenced frames used to calculate motion and to denoise. Use values from 2 to 6. No any common requirements to choose, because it is a source kind-related. I use 2 to 4 in most cases. Bigger values creates motion artifacts (see below).
th - threshold to denoise. Use values from 1 to 10000. Bigger values enable more aggressive denoise, also you will get temporal artifacts (like a slow motion of fast movement objects). So better usage of this filter - to convert 50p(60p) to 25p(30p) or to denoise static scenes. Change a framerate after this filter. As a result you will get less strobe effect. I use 800 in my projects (50p->25p). You should keep this value minimal, for your source, to get less artifacts.
limit - frame change threshold limit in a brightness value range. In most case use 255(no limit). If you have artifacts, try to decrease it to 2 or 3.
Pro edition has another denoise filters, those create no temporal artifacts, or can better denoise of some clips.
@rean With the paid version, CF allows for a 4:4:4 export. Prores allows for 4:4:4 anyway. These 2 codecs cover pretty much most of the commercial editing range. If you include the Avid DnxHD, that would be close to a 100% coverage. I would be happy to pay more and be able to get 10-bit 4:4:4 export with Cineform.
Firstlight Cineform is by far the fastest primary color grading app I have seen - and I would really like to use it.
Another trick used by Cineform and possibly by 5DtoRGB is to spread the 16-235 range of luma over the entire 10-bit. This offers an extra range while grading.
@zcream I understand your request.
Probably in the future, but now I have no possibility to develop a special code for your codecs export. Windmotion supports only codecs from ffmpeg using conversion from a H.264 temporary file. (Why this strange way? I have removed DirectShow export possibility while development, because I found unknown bugs in third-party components. For this reason, two months ago, I decided to close the project. Also ffmpeg has no possibility to choose color matrix directly, so we have color shift in HD videos (known bt.709/bt.601 issue). But I found a conversion from H.264 file works fine, so I use this strange solution.)
Prores 4444 is not yet included in ffmpeg. I know this codec is included in ffmbc, but probably it is not supported for 10-bit conversion from H.264, so I do not support it. Also I found ffmbc is 3 times slow, without any superiority over ffmpeg.
Windmotion final release will support the same codec set as supported currently in beta. This includes: ProRes 4:2:2 10bit, DNxHD 1080p 4:2:2 10bit, H.264 lossless (all modes), Ut codec (all modes but RGB mode has color shift for HD source because a bug in ffmpeg), MJPEG 4:2:2, v210 4:2:2 10 bit.
I myself do not like the way the export is made currently. Currently this is a set of tricks to get accurate color over open source tools those developed by programmers not artists. But this is the best solution available today for me, which works fast and without errors. Perhaps in the future, I'll do something like ffmpeg, but for Windmotion especially, but not now.
@zcream, probably later. I was busy working on the new Windmotion web site. Now I am ready to make a documentation and examples.
New Windmotion example (before/after):
It is a very noised Sony NEX-7 ISO 3200 footage. And a Windmotion Pro result.
A bigger screenshot, ProRes 4:2:2 10 bit file, before/after video, MTS source and other info is here.
A youtube low quality preview:
@rean, the Nex footage looks really good. Evident even with low quality youtube clip. How are you coming along with optimization for GH3 (based on sample-clips I sent)? When that is ready, I'll be buying the "Personal Edition" for sure! :)
I have started to publish the user manual. Currently available two articles. They cover most of questions about program usage steps.
i was eating peanut butter and honey !!! now i see this. Thanks @rean ,you make my day. Finally clear instructions. And thw video and image is awesom the before an after!! thanks!!
The Nex shots look very good.
Here is the latest beta version. The next release will be the final release. I have successfully created a big 7-hour Full HD project with this version. The main documentation is also almost ready.
Version 0.9.0.Beta2, 2013-09-04
Audio processing disabled by default.
16:9 2K support 2048x1152.
Film grain filters are moved to different functions.
Film grain 16-bit export support.
Increased default crf for 720p film (Pro).
Script "Edit\Edit All Before After" without a histogram added.
Bugfix: Incorrect parameters of MakeFilm scripts fixed, setlocal added (Pro).
Bugfix: Private scripts removed from installer (Pro).
Bugfix: Incorrect mp4 mixing for Film (Pro).
x264 updated to the latest version (Komisar build is used).
TODO: Documentation in progress.
I'm very impressed with your nex7 footage sample. it would be really nice to see some type of chart where the effects on detail are more obvious. Awaiting the final version. any idea on pricing?
any idea on pricing?
From $0 to $275.
Thanks @humpman for the GF1 (hacked) footage 720p MOV MJPEG 120 mbps.
It is a resize example from 720p to 1080p with Pro edition sharp filters. Source image is pre-resized for 1080 for comparison. Denoise and dehalo filters and red and blue channel saturation are also used.
It is not very best resolution upsample example, because unfortunately the source video is blurry without subpixel details (probably GF1 lens is not so good for this fantastic hack bit rate). So I used existing 1-2 pixel sharp only. Subpixel sharp is useless here - I had only random dirty pixels.
It looks like you're new here. If you want to get involved, click one of these buttons!