Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 22nd August 2018, 21:09   #1  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 305
HDRColor

It might be worth adding that videoartifact also has a Avisynth filter for 3dLuts. It also uses the same name as the one posted here(Cube). The Filter does cost a bit of money for the HDRColor filters(Which Contains the 3D Lut functions). They also have a bunch of other HDR filters works with Dither tools and are adjusted correctly. It supports 8, 16, 32 and 88(MSB/LSB).

Link: https://www.videoartifact.com/hdr/
Revan654 is offline   Reply With Quote
Old 22nd August 2018, 23:21   #2  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 500
HDRTools works in 16bit interleaved which is basically aligned horizontally rather than vertically like Dither Tools (16bit stacked).
I remember that it used to be free and discussed here on doom9 many years ago, that's why I have it in my Avisynth plugin directory.
I thought the project was dead; I had no idea that the author developed it even further.
Too bad it became a closed source paid software.
Even back in the days, people struggled to use 16bit interleaved rather than 16bit stacked just because it was supported by less filters.
Now that Avisynth+ is widely available and real high bit depth is available and faster, people just use real high bit depth.
Avisynth 2.6.1 users generally use Dither Tools in 16bit stacked and considering that you have now to pay for HDRTools, I don't think there's much space left for it...
FranceBB is offline   Reply With Quote
Old 23rd August 2018, 01:04   #3  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 305
Quote:
Originally Posted by FranceBB View Post
HDRTools works in 16bit interleaved which is basically aligned horizontally rather than vertically like Dither Tools (16bit stacked).
I remember that it used to be free and discussed here on doom9 many years ago, that's why I have it in my Avisynth plugin directory.
I thought the project was dead; I had no idea that the author developed it even further.
Too bad it became a closed source paid software.
Even back in the days, people struggled to use 16bit interleaved rather than 16bit stacked just because it was supported by less filters.
Now that Avisynth+ is widely available and real high bit depth is available and faster, people just use real high bit depth.
Avisynth 2.6.1 users generally use Dither Tools in 16bit stacked and considering that you have now to pay for HDRTools, I don't think there's much space left for it...
It still free, Only the HDRColor 64Bit version is paid ware. I never recall HDRColor being Freeware. HDRCore Tools does both 16Bit stacked and linear.

This was the old Site: https://web.archive.org/web/20160604...m/plugins/hdr/
Revan654 is offline   Reply With Quote
Old 23rd August 2018, 02:23   #4  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,063
I really wouldn't trust Revvo's tools too much. The guy was always kind of a nutjob, and back when he still posted here he demonstrated a very, uh, let's say unorthodox view of correctness in video processing (in various different ways). Very much the kind of individual who shunned anything "not invented here"; he insisted on his own fork of Avisynth for many years because according to him all other variants were unusable for some very murky reasons. I'd link some old flamewars but he deleted his account and all his threads with it.

e: looks like his "VA Core" is still some custom fork of the ancient 32-bit Avs-MT, so he never did migrate to Avs+ after all. Not really surprising.
e2: I'm also pretty sure everything he's selling is available for free in Vapoursynth (and probably most of it in Avs+ too these days)

Last edited by TheFluff; 23rd August 2018 at 02:31.
TheFluff is offline   Reply With Quote
Old 23rd August 2018, 12:15   #5  |  Link
rean
Registered User
 
Join Date: Aug 2011
Posts: 11
Quote:
Originally Posted by TheFluff View Post
I really wouldn't trust Revvo's tools too much. The guy was always kind of a nutjob
Omg. This user still continue to spread lies about users who disagree with them. Why you are so angry, TheFluff?

Quote:
Originally Posted by TheFluff View Post
and back when he still posted here he demonstrated a very, uh, let's say unorthodox view of correctness in video processing (in various different ways).
You are wrong. I posted here a lot of ideas to get better processing of modern camera sources (it is ~ 90% of all selling customer and pro cameras from 2000 including modern 4K models), because existing Avisynth filters and most user plugins were not compatible with these video sources, because a non-standard TV level encoding. It was not my non-standard point of view for video processing but a way most companies like Sony and Panasonic used to create high quality solutions using old 8-bit standards. So this way is not standard, but gives users additional value range to keep details in existing technical limitations.

Avisynth filters these days just worked incorrectly with super-white and super-black areas, so after processing these color values were just deleted. A lot of useful color information may be lost including very important object areas like sky, so result video after processing may look very ugly (color distortion). Also it was very hard to color correct these sources directly in Avisynth. Using gamma correction in Avisynth just were incorrect and ugly way to get anything be simple for user.

These days there were no quality free video editors, so Avisynth processing was very useful for many people like me. I liked processing speed for Avisynth, so I used it for all my films. Because those days there were no filters to work with these sources, I created Dither-based scripts to work correctly with these sources. Later I created native code filters you know currently as HDRCore-series. Additionally I added support for 16 and 32-bit processing and posted here ideas why my ideas may be a standard way for future Avisynth processing. My proposals may add to Avisynth processing more speed, compatibility and usability for developers and users.

For example, 16-bit linear processing is 1.5 times faster than ugly lsb-msb way because processor cache mismatch and additional code logic. Also it is very hard to develop.
Also my floating point proposals may add users a standard 0-255 color scale in any bitdepth. For example these days users used very ugly 0-255 and 0-65535 ranges to create own scripts. Some people discussed that this must be 0.0-1.0 range in 32-bit, so this set of ranges were not usable. I just proposed one standard value range 0.0-255.0 range for all bitdepth.
This color level standard is also very simple to create fast code, so create Avisynth filters with mixed bitdepth may be very simple.

But, anyway, current Avisynth+ solution is very different from these ideas, so no time to discuss my ideas here again.

I will simply add here that we discussed this here, but unfortunately, as usual, good ideas die under the onslaught of insolent people who resorted to insults.
I considered it unacceptable for myself to participate in this farce, to do something for people free of charge, expending efforts, but receiving in return a lot of negativity. And so I left those discussions then.

Quote:
Originally Posted by TheFluff View Post
he insisted on his own fork of Avisynth for many years because according to him all other variants were unusable for some very murky reasons.
These reasons are simple. I forked Avisynth MT because these days it was very fast comparing with alternate solutions. Because I used very complex scripts in 16-bit, it was very important for me. What about 5 fps processing speed vs 0.1 fps using alternate solutions? Avisynth MT was also very buggy. Many hundreds of user posts here in forum about crashes. Most crashes in read filters like FFmpegSource and similar filters were because these bugs.

I made my fork and first of all I improved cache logic to better processing stability with UHD video. Some changes were not ideal and produced new bugs, so some users these days insulted me that I am very bad developer and my fork is fully garbage. But currently my Avisynth MT fork is stable. There is a lot of improvements and fixes currently. Also I fixed a lot of new found bugs including most of "traditional" MT crashes because incorrect logic of multi-threading processing code by the MT author.

Quote:
Originally Posted by TheFluff View Post
e: looks like his "VA Core" is still some custom fork of the ancient 32-bit Avs-MT, so he never did migrate to Avs+ after all. Not really surprising.
Yes, because it is my Avisynth MT fork -based. I used it and do not want to use AviSynthMT+. It is still not compatible with lot of used very important filters also unstable with typical scripts I use to process video. Also it is still slow comparing with my AvisynthMT fork. I tried to switch to AvisyntMT+ many times, but unfortunately it is not usable with my solutions. 5-15% slow also crashes in cases where my fork is stable and works in 24-hours per day. These crashes may be fixed by decrease processing threads, but it costs additional speed. So using AviSynthMT+ is slow for me.

It is not because some bugs in my scripts, but because AviSynthMT+ threading model is less efficient because more universal, also it is not ready for very complex code I use usually for processing where memory is typically full. So I see no reason to use it.

Another reason why I do not change anything, is because my HDRCore filters are compatible with AviSynth+/MT+, so there is no reason to change anything. Also I do not like 2.6 API. My code is fully compatible with 2.5.

You should know yet another reason why I am not here in Avisynth community is because I am a developer of VideoArtifact that already contains all required tools to work with video sources. Yes, it is based on HDRCore + my fork of AviSynthMT. And yes, it contains everything different than usually used typically by any Avisynth user. The cause is just simple: my code is many times faster and usable for complex processing with extreme high quality. I spent many months to get it faster and compatible with pro-postproduction, so using usual Avisynth stuff is just useless for me because a lack of speed and related tools to get the comparable speed and quality.

Quote:
I'm also pretty sure everything he's selling is available for free in Vapoursynth (and probably most of it in Avs+ too these days)
You are wrong. VideoArtifact is not AviSynth nor Vapoursynth clone nor functional equivalent. It is a specialized software with unique features. Just because it is not a set a filters, but also a lot of tools for footage source workflow, including backup, reencode and mastering for H.264 and VP9, also it is created to use with commercial software like Adobe or Blackmagicdesign.

Of course, some VideoArtifact filters have functional equivalent in AviSynth and Vapoursynth, but my solution is optimized for workflow and speed for video production.

PS. HDRCore Cube filter is always free with VA Core - that contains my AviSynthMT fork and a lot of optimized filters and software, like script editor:
http://www.videoartifact.com/core/
They work with VA Community edition:
http://www.videoartifact.com/va/

And if some people want the complete solution for video post-production may buy the commercial edition.
The software is fully supported. I receive bug reports and improve it time by time.

Some people do not understand that additional software support costs extra. I am not a hobbyist but I use Avisynth and programming for pro reasons. Sorry, but I have no free time to port anything to workflows typically used by community. Also I have no sufficient time to discuss on forums. Currently I support my filters to be compatible with VACore only.

But if some people really want me to port my solutions to AviSynth+ or Vapoursynth, I ready to discuss it, but for your donation or another help. This probably may include my 3DLUT code filters. I ready to publish it as open source, but I would get a compensation.
__________________
Software developer and post-production engineer
rean is offline   Reply With Quote
Old 23rd August 2018, 14:56   #6  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,063
oh hello

Quote:
Originally Posted by rean View Post
I posted here a lot of ideas to get better processing of modern camera sources (it is ~ 90% of all selling customer and pro cameras from 2000 including modern 4K models), because existing Avisynth filters and most user plugins were not compatible with these video sources, because a non-standard TV level encoding. It was not my non-standard point of view for video processing but a way most companies like Sony and Panasonic used to create high quality solutions using old 8-bit standards. So this way is not standard, but gives users additional value range to keep details in existing technical limitations.
I'm not only referring to the silly 16-255 range issue. Among many other things I can recall some interesting ideas you had about gamma which Colours pointed out were highly questionable from a mathematical standpoint.

Quote:
Originally Posted by rean View Post
For example, 16-bit linear processing is 1.5 times faster than ugly lsb-msb way because processor cache mismatch and additional code logic. Also it is very hard to develop.
Also my floating point proposals may add users a standard 0-255 color scale in any bitdepth. For example these days users used very ugly 0-255 and 0-65535 ranges to create own scripts. Some people discussed that this must be 0.0-1.0 range in 32-bit, so this set of ranges were not usable. I just proposed one standard value range 0.0-255.0 range for all bitdepth.
This color level standard is also very simple to create fast code, so create Avisynth filters with mixed bitdepth may be very simple.
I dunno if you've been living under a rock or something, but the stacked 16-bit format has been dead for years. Avs+ has native 16-bit int and 32-bit float support, as does VS. And of course neither uses 0.0-255.0 as a numeric range for float, because why on earth would they?

Quote:
Originally Posted by rean View Post
I will simply add here that we discussed this here, but unfortunately, as usual, good ideas die under the onslaught of insolent people who resorted to insults.
I considered it unacceptable for myself to participate in this farce, to do something for people free of charge, expending efforts, but receiving in return a lot of negativity. And so I left those discussions then.
Have you ever entertained the thought that your good ideas may in fact have been bad ideas? I know painting yourself as a misunderstood genius who only fails because of malicious people like me is comforting, but it's also, uh, not healthy.

Quote:
Originally Posted by rean View Post
These reasons are simple. I forked Avisynth MT because these days it was very fast comparing with alternate solutions. Because I used very complex scripts in 16-bit, it was very important for me. What about 5 fps processing speed vs 0.1 fps using alternate solutions? Avisynth MT was also very buggy. Many hundreds of user posts here in forum about crashes. Most crashes in read filters like FFmpegSource and similar filters were because these bugs.

I made my fork and first of all I improved cache logic to better processing stability with UHD video. Some changes were not ideal and produced new bugs, so some users these days insulted me that I am very bad developer and my fork is fully garbage. But currently my Avisynth MT fork is stable. There is a lot of improvements and fixes currently. Also I fixed a lot of new found bugs including most of "traditional" MT crashes because incorrect logic of multi-threading processing code by the MT author.
There was an alternative solution that the mainstream userbase was migrating to at the time: Avs+. It also has such revolutionary features as support for high bitdepth and 64-bit operating systems. Forking the old Avs-MT and reinventing a bunch of wheels that Avs+ had already solved was plainly speaking idiotic and even today your hacked up fork lacks features that Avs+ has had for years. You also keep insisting Avs+ has bugs that prevent you from using it, and while you have the time to maintain your own fork, you don't have time to actually report these bugs.

Quote:
Originally Posted by rean View Post
Yes, because it is my Avisynth MT fork -based. I used it and do not want to use AviSynthMT+. It is still not compatible with lot of used very important filters also unstable with typical scripts I use to process video. Also it is still slow comparing with my AvisynthMT fork. I tried to switch to AvisyntMT+ many times, but unfortunately it is not usable with my solutions. 5-15% slow also crashes in cases where my fork is stable and works in 24-hours per day. These crashes may be fixed by decrease processing threads, but it costs additional speed. So using AviSynthMT+ is slow for me.

It is not because some bugs in my scripts, but because AviSynthMT+ threading model is less efficient because more universal, also it is not ready for very complex code I use usually for processing where memory is typically full. So I see no reason to use it.
This is complete nonsense and we've been over this many times. Your scripts aren't very complex, and if you want more memory use just use 64-bit like everyone else. I doubt these incompatible filters you're going on about even exist at all.

Quote:
Originally Posted by rean View Post
You should know yet another reason why I am not here in Avisynth community is because I am a developer of VideoArtifact that already contains all required tools to work with video sources. Yes, it is based on HDRCore + my fork of AviSynthMT. And yes, it contains everything different than usually used typically by any Avisynth user. The cause is just simple: my code is many times faster and usable for complex processing with extreme high quality. I spent many months to get it faster and compatible with pro-postproduction, so using usual Avisynth stuff is just useless for me because a lack of speed and related tools to get the comparable speed and quality.
If you want to sell these things on their own merits I really think you should post some benchmarks to back up your claims.

Quote:
Originally Posted by rean View Post
But if some people really want me to port my solutions to AviSynth+ or Vapoursynth, I ready to discuss it, but for your donation or another help. This probably may include my 3DLUT code filters. I ready to publish it as open source, but I would get a compensation.
Did you somehow not notice that an Avs+ port of Timecube (VS 3DLUT filter) was posted in this thread already?
TheFluff is offline   Reply With Quote
Old 24th August 2018, 11:03   #7  |  Link
rean
Registered User
 
Join Date: Aug 2011
Posts: 11
TheFluff,
If your point of view is different than have some else, IT IS NOT MEAN that different people is bad. Stop post thought than I am bad person ("idiotic", "only fails", and some another bad words you always use to beat a person). My person is not the point of this forum. And I have no good English level to kick you in your troll battle. But I really don't want that some people like you post any rumors and fables those are totally lie.

My ideas, development and my solutions are available because they solve different problems, also to solve very hard combinations of contradictory requirements like processing speed, quality, cost of development, legal, patents, algorithm and CPU limitations etc. If you have different requirement and different resources, that also does not mean that another person is bad and another solution is bad.

About gamma correction - x^y is used for it. And this function has a limitation for negative values. If you do not understand this limitation, and also does not understand performance issues with it, that mean you cannot understand why I used some idea that works and solve these limitations. There may be different ways to solve it, but my idea, used in HDRCore, works perfectly for the purpose of all filters used for it. This is good for a performance and visually. This does not mean that I am a bad person, bla-bla-bla.

About using old tools you do not like, eg 32-bit, old Avisynth build etc. - I am a person who like results those works and solve issues, limitations, resources, and technical tasks. For these days these solutions, yes, not optimal in a technical perfection. But for real people like me, if works perfectly. Because it just works and in perfect performance and aesthetic sense. This is a well known dilemma: technical perfection or existing solutions. Some people will choose technical perfect things because they are geeks.

I chose Avisynth MT, because it is the fastest solution available for my tasks. If you have only one hour video in a month, but in my case I have dozens of hours every month and requirements to get it as perfect as possible. And I process these hours with 2-10 fps. But using any other solutions I cannot reach even 1 fps. If you do not understand what is 1 fps, that means one hour of video will be done in 50 hours. What about 200 hours of video? I have totally processed them already using my solutions in a good performance. Your conversations about the choice of "well known community solutions" give me laugh when I see how I will suffer with your decisions.

I recompiled Avisynth MT to improve the performance in 2-5 times where it just crashed totally in random places after 10-15 minutes of processing, I created alternate filters to fast process some computing places, I totally recreated any existing script filters to improve performance and totally benchmarked it in a real processing to get these 2-10 fps. And what about these development hours those were unsuccessful and you does not know about it? Also my solution had worked 2-3 years ago.

You think your Vapoursynth is good? It is totally cannot work with audio. LOL these people require I used it for my tasks? Really? I trim 50fps video in realtime with audio in a correct way using Avisynth MT. You think AvisynthMT+ is good? It just hangs on those scripts with 20-30 filters even on 3 threads where Avisynth MT just works. You think my scripts are not complex? What about 12 instance mvtools denoisers those work in Y, U, V separately with a possibility to control every parameter in a visual editor? There are also many EEDI-based AA filters together!

Quote:
This is complete nonsense
Bravo! Also I am a bad person bla-bla-bla.

Quote:
Did you somehow not notice that an Avs+ port of Timecube (VS 3DLUT filter) was posted in this thread already?
Did you somehow not notice that HDRColor with a 3D LUT filter is yet available 3 years and works perfectly with Avs+ and also in 16-bit YUV including 4:2:0?
Ok, we will wait also some couple years when some user will create some new fast filter that is already available for years in Video Artifact, and also free.
__________________
Software developer and post-production engineer
rean is offline   Reply With Quote
Old 24th August 2018, 19:46   #8  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,136
Quote:
Originally Posted by rean View Post
Did you somehow not notice that HDRColor with a 3D LUT filter is yet available 3 years and works perfectly with Avs+ and also in 16-bit YUV including 4:2:0?
........and also free.
Confused now. So where is the download link for this free version (? 32bit only) of HDRColor "that works perfectly with AVS+", which would be taken to imply the official version of AVS+, not some special fork ?
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 24th August 2018 at 19:53.
WorBry is offline   Reply With Quote
Old 24th August 2018, 23:30   #9  |  Link
Revan654
Registered User
 
Revan654's Avatar
 
Join Date: May 2004
Posts: 305
Quote:
Originally Posted by WorBry View Post
Confused now. So where is the download link for this free version (? 32bit only) of HDRColor "that works perfectly with AVS+", which would be taken to imply the official version of AVS+, not some special fork ?
Link: https://www.videoartifact.com/core/

It's part of the VACore bundle installer. You can use 7z app to open the exe file if you just want the dll file.
Revan654 is offline   Reply With Quote
Old 25th August 2018, 03:53   #10  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,136
Ok, thanks. So I extracted the HDRColor.dll from VACore.exe > Core.7z and (since there was no included documentation) found a reference webpage that details the VA filter parameters:

https://www.videoartifact.com/tips/va-filters/

Tried testing with AVISynth+ (r2636, MT, i386) but can't get passed the error message "There is no function named 'Cube'". Didn't matter if I put the HDRColor.dll in the C:\Program Files (x86)\AviSynth+\plugins or plugins+ folders, or in the same folder as the AVS script and loaded it from there. Compatibility ?
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 25th August 2018 at 06:42.
WorBry is offline   Reply With Quote
Old 25th August 2018, 04:21   #11  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,074
Just out of curiosity I tried out Video Artifact. And the user experience is bad. I think just this line alone from the setup guide would probably kept most users away from using the program.

Quote:
=== How To Use ===

1. Place your video file to this folder.
Why would I want to do that?? I have videos that are 10+ GB, I can't be moving the files around just so it can be opened by the program. In the video tutorials he did make it work by copying the VA folder to the video file location, but then its batches won't work if I have more than one video file in that folder...This design is just a lack of common sense.
lansing is offline   Reply With Quote
Old 25th August 2018, 06:36   #12  |  Link
rean
Registered User
 
Join Date: Aug 2011
Posts: 11
WorBry, do not move HDRColor.dll from the VACore folder, or the license will be invalid and the dll plugins will not be available in your scripts. The .dll is locked to Video Artifact folder. If you move the .dll file to any other folder, it will not work. If you like it, you can buy a license to get a 64-bit/32-bit versions, also unlocked, so you may place the purchased .dll to any folder you want.

lansing, the VA design is optimized to batch use with project files after recording session in a video production. You need to move project video files or the "va" folder to your project folder with videos. This solution helps user to use only mouse clicks and manipulate with video sources using different features of the commercial edition of the program. No any video file location edit nor video file name edit are required. The program scripts will search for video files from the project folder and generate avs files per project video file. It is different form usual Avisynth usage because Avisynth has no IDE or edit program - it is just a language, but it is easy to work with footages in production, because there are a couple of batch scripts are available with different functions. Remember - a Video Artifact project is a folder. If your video folder has hundreds of files, it is not easy. Just keep only processed files and keep the project video file count is under 10. The program design is optimized for batch processing of many files in one time on processing workstations without user interaction. For example you can add files to the project and execute processing for many hours and even days on a special "rendering" computer in a local network. For a indie Avisynth user this solution is overkill, but the program is for video production as a business.
__________________
Software developer and post-production engineer
rean is offline   Reply With Quote
Old 25th August 2018, 06:43   #13  |  Link
rean
Registered User
 
Join Date: Aug 2011
Posts: 11
The Cube function reference is:

function Cube(clip c, string "file", int "from", int "to", float "rg", float "gg", float "bg", float "a", float "b", float "ao", float "bo", float "sat", float "sato", int "bitdepth")

c is clip.
file is a 3D LUT file. *.cube or *.3dl is supported. If you specify "", no 3D LUT operation will apply.
from and to are TV standard codes: 601 or 709. Use 601 for SD clips or 709 for HD clips.
rg, gg and gb are RGB gain values. Use 1.0 for no brightness correction.
a and b are clip Y-channel input range. For TV standard it is 16...235.
ao and bo are clip Y-channel output range. For TV standard it is 16...235.
sat is a clip input saturation before 3D LUT. Try 1.0 for no changes.
sato is a clip output saturation after 3D LUT. Try 1.0 for no changes.
bitdepth is a clip bitdepth code: 8, 16, 32 or 88 for stacked 16-bit.
returns clip.

It works with YUV sources: 4:2:0, 4:2:2 or 4:4:4, 8-bit, 16-bit stacked or native. Or 32 bit. RGB is not supported.

Any other Video Artifact and HDRCore filter reference is located here: http://www.videoartifact.com/tips/va-filters/
Not all filters are available in the free community edition.
__________________
Software developer and post-production engineer

Last edited by rean; 25th August 2018 at 06:46.
rean is offline   Reply With Quote
Old 25th August 2018, 11:48   #14  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,074
Quote:
Originally Posted by rean View Post
lansing, the VA design is optimized to batch use with project files after recording session in a video production. You need to move project video files or the "va" folder to your project folder with videos. This solution helps user to use only mouse clicks and manipulate with video sources using different features of the commercial edition of the program. No any video file location edit nor video file name edit are required.
That still doesn't explain why the hassle just to open a video file.

Quote:
Originally Posted by rean View Post
The program scripts will search for video files from the project folder and generate avs files per project video file.

...

If your video folder has hundreds of files, it is not easy. Just keep only processed files and keep the project video file count is under 10.
Why would I want to do that? It shouldn't be the user's responsibility to rearrange his files just for this program.
lansing is offline   Reply With Quote
Old 25th August 2018, 12:31   #15  |  Link
rean
Registered User
 
Join Date: Aug 2011
Posts: 11
lansing, it is not a separate video file editor, so open and save separate files is not supported. Automatic generation of avs files includes also generating batch files with encode parameters, output bitdepth and subsampling etc. Also the files are placed to different locations in some parts of software, also file rename is supported in different ways. Also the processing is based on template files for specific cameras or scenes. So this design helps to keep a simplify for the batch processing also some limitations of Avisynth if we want not to edit file names any time with a lot of files. Also some projects require different setting for it and custom scripts etc. We only control a folder and script parameters. In most cases it is just mouse clicks.

If you want different way, you need different software or complete redesign the program that mean a very different program. VA processing is based on folder and anything on it based on this concept. Historically, it had created to batch process of a lot files with very less of user time on many render computers. Using edit file names, execute different encode program and another ways usually used by Avisynth users is not useful in this case. It requires a lot of routine tasks those very annoyed. So I created a new concept that helps everything to get only file copy to specific folder and works with this folder as a project. Additional features - automatic source backup, rename, sort, control quality are also based on this idea.

This design solves many hidden problems and additional user interaction things you do not know yet. So the workflow is optimized for batch processing in video production, where we have many files every day in different folder from different cameras.
__________________
Software developer and post-production engineer

Last edited by rean; 25th August 2018 at 12:43.
rean is offline   Reply With Quote
Old 25th August 2018, 13:42   #16  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 1,650
Quote:
Originally Posted by lansing View Post
That still doesn't explain why the hassle just to open a video file.

Why would I want to do that? It shouldn't be the user's responsibility to rearrange his files just for this program.
That does sound like very lazy programming to me. And I should know, I'm a very lazy programmer.

Quote:
Originally Posted by rean View Post
So the workflow is optimized for batch processing in video production, where we have many files every day in different folder from different cameras.
By making users move everything to a specific folder? That makes no sense!
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 25th August 2018, 15:51   #17  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,136
Quote:
Originally Posted by rean View Post
WorBry, do not move HDRColor.dll from the VACore folder, or the license will be invalid and the dll plugins will not be available in your scripts. The .dll is locked to Video Artifact folder. If you move the .dll file to any other folder, it will not work. If you like it, you can buy a license to get a 64-bit/32-bit versions, also unlocked, so you may place the purchased .dll to any folder you want.
That's not what your earlier statement implied:

Quote:
Originally Posted by rean View Post
Did you somehow not notice that HDRColor with a 3D LUT filter is yet available 3 years and works perfectly with Avs+ and also in 16-bit YUV including 4:2:0?
......and also free.
Never mind. AVSCube works fine for me.
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 25th August 2018 at 15:54.
WorBry is offline   Reply With Quote
Old 25th August 2018, 17:54   #18  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,074
Quote:
Originally Posted by rean View Post
lansing, it is not a separate video file editor, so open and save separate files is not supported.
What??? A video editor that was not designed to open a video file???

Quote:
Originally Posted by rean View Post
If you want different way, you need different software or complete redesign the program that mean a very different program. VA processing is based on folder and anything on it based on this concept. Historically, it had created to batch process of a lot files with very less of user time on many render computers. Using edit file names, execute different encode program and another ways usually used by Avisynth users is not useful in this case. It requires a lot of routine tasks those very annoyed. So I created a new concept that helps everything to get only file copy to specific folder and works with this folder as a project. Additional features - automatic source backup, rename, sort, control quality are also based on this idea.

This design solves many hidden problems and additional user interaction things you do not know yet. So the workflow is optimized for batch processing in video production, where we have many files every day in different folder from different cameras.
This looks more like a failed design by the program. And instead of redesigning it you're enforcing normal users to cope with the failed design themselves.
lansing is offline   Reply With Quote
Old 25th August 2018, 20:32   #19  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,722
Quote:
Originally Posted by rean View Post
It works with YUV sources: 4:2:0, 4:2:2 or 4:4:4, 8-bit, 16-bit stacked or native. Or 32 bit. RGB is not supported.
Is that right ? Seems kind of odd that RGB is not supported ? for a RGB cube LUT ? You have rg,gg,bg gain parameters in the function but RGB is not supported ??

I'm guessing it's meant to fast track the workflow in specific scenarios. But I can see potential issues in other scenarios

Quote:
from and to are TV standard codes: 601 or 709. Use 601 for SD clips or 709 for HD clips.
You said earlier was developed with UHD in mind, so shouldn't BT.2020 be included?

The website says 5-10% faster
Quote:
Also it is powered by a special AviSynth MT build that is 5-10% faster than AviSynth Plus MT on real processing.
But earlier you say 2-5x (which is 200-500% if my math is correct) , so I'm wondering which specific workflows can benefit or under which workloads or which "real processing" . (Basically I'm wondering if any users have additional benchmarks with actual scripts, actual sources, repeatable tests)

Anyways thanks for posting , it's a shame that some posts got deleted. Some people were asking for LUT filters in avisynth way back in other threads too and nobody mentioned this



And thanks to videoh for his port too
poisondeathray is offline   Reply With Quote
Old 25th August 2018, 20:45   #20  |  Link
Groucho2004
 
Groucho2004's Avatar
 
Join Date: Mar 2006
Posts: 4,107
Just to avoid any confusion - This is not a "software" or a "program", it's a bunch of scripts, plugins and free utilities, that's it.
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 04:24.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.