HDRColor

[Revan654]

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/

[FranceBB]

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...

[Revan654]

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/20160604220510/http://www.snovidenie.com/plugins/hdr/

[TheFluff]

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)

[rean]

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? :)

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.

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.

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.

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.

[TheFluff]

oh hello

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.

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?

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.

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.

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.

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.

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?

[rean]

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!

This is complete nonsense

Bravo! Also I am a bad person bla-bla-bla.

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.

[WorBry]

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 ?

[Revan654]

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.

[WorBry]

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 ?

[lansing]

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.


=== 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.

[rean]

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.

[rean]

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.

[lansing]

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.

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.

[rean]

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.

[wonkey_monkey]

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.

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!

[WorBry]

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:


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.

[lansing]

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???


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.

[poisondeathray]

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


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

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

[Groucho2004]

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.

[poisondeathray]

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.

To be clear, you're referring to rean's software ?

But apparently there are some speed improvements / optimizations , better stability than avisynth mt (but that was a buggy piece of ____ , so no surprise there)

Personally , I'm wondering how it stacks up to avisynth+ mt (actual benchmark tests, avsmeter, actual scripts etc...)

[Groucho2004]

To be clear, you're referring to rean's software ?Yes.

But apparently there are some speed improvements / optimizations , better stability than avisynth mtFrom what I recall, rean's AVSMT is buggier than SEt's and some of the coding is atrocious, unfortunately all the post that related to that are gone.

Personally , I'm wondering how it stacks up to avisynth+ mt (actual benchmark tests, avsmeter, actual scripts etc...)Me too. :)

[rean]

poisondeathray, the plugin is created 3 years ago when no RGB 16-bit were available. A 8-bit processing for color correction is not optimal because rounding errors. So we work in YUV 16-bit for better color and also speed.

Plugin internal processing is in RGB after YUV→RGB and back RGB→YUV. So the plugin output is identical to RGB 3D LUT processing in Resolve, Photoshop, etc. But we can use 4:2:0 for speed, because most camera sources are still 4:2:0. There is no benefit to use better subsampling for these sources, also it reduces processing speed.

BT.2020 is not supported. I have no sources in my video production with this color space, so no support is available. Also most 3DLUT files you can find and buy in the internet are for Rec.709. But potentially adding this color space is trivial - a new constant with a conversion code in additional to Rec709/601.

Speed results are different for different parts. I pointed different tests for different situations:

Old Avisynth MT may work on 2 threads only, because it crashes after 10 minutes in random places if use 3 threads or more. After bugfix this limit is not actual, so we can process wth 3-8 threads and result speed may be increased by 2 times. The crash cause is MT cache overloading due algorithm limitations used by the MT developer. And these situations are for real processing scripts, not synthetic tests for subset of plugins or internal filter.

My test results AvisynthMT vs AvisynthMT+ are for real projects I use regularly with optimized thread count for both versions to get most possible speed. These tests may be available, because Video Artifact supports AvisynthMT+ (not all plugins can work due some plugins do not work with avs+ or work in one thread only, so very slow and not usable). The general difference is 5-15%. And these tests for x86 only, because I cannot recreate a 64-bit test version due some limitations. I tried to switch to Avs+ many times, but a performance and stability is a key for my projects. Currently only AvisynthMT is the core engine for VideoArtifact to get stable and fast processing.

I tried some tricks like multiprocess ( I have own developed avs2yuv MP edition to call many Avisynth instances in different processes). But is not usable - it requires 32GB memory and no real speed gain because CPU/memory bandwidth and cache limitations. So I have not published it anywhere as it is useless to usage.

I have not posted anything about my plugin here because my primary work is for VA, nor generic Avisynth processing. And many users know it and purchase time to time, because still use HDRCore and can see a purchase link on the web site.

But, these next years, Avisynth and also 3DLUT processing in it will dead, because CUDA and GPU processing on free software like Fusion or Resolve is a reality. Blackmagic changes the video production some years age and many video software is dead. There is also a free license option for Nuke for home users. I move to OFX plugin development as more potential. And many Avisynth plugins may be ported to OpenFX. The API is very similar.

[rean]

Groucho2004,
to be more clear, Video Artiafact is a software, based on a set of batch files those execute video editor or processing in different ways. And it is based on Avisynth MT, FFmpeg and some other programs to encode video. For processing speed it uses own set of Avisynth code, some code are moved to binary plugins for speed. The program contains processing code templates for many existing V-DSLR cameras and may be used for video restoration tasks like generic Avisynth usage.

[TheFluff]

From what I recall, rean's AVSMT is buggier than SEt's and some of the coding is atrocious, unfortunately all the post that related to that are gone.
My memory is hazy but I seem to recall that it was rean who at some point "fixed" a thread synchronization bug (think it was a deadlock) by wrapping the entire thing in what amounted to a try/catch (possibly with a timeout? don't remember) and just tried the same thing again when it failed.

It would be really interesting to have some actual benchmarks to verify rean's claims against modern alternatives but it's such a pain to use I can't be bothered, and the burden of proof should probably be on the party attempting to charge money for these things anyway.

But, these next years, Avisynth and also 3DLUT processing in it will dead, because CUDA and GPU processing on free software like Fusion or Resolve is a reality.
The reason timecube was ported to Avs+ was that it turned out that it's faster than the CUDA solution. :V

BT.2020 is not supported. I have no sources in my video production with this color space, so no support is available. Also most 3DLUT files you can find and buy in the internet are for Rec.709. But potentially adding this color space is trivial - a new constant with a conversion code in additional to Rec709/601.

Oh, trivial, is it now? Do you even HDR, bro?

[videoh]

The reason timecube was ported to Avs+ was that it turned out that it's faster than the CUDA solution. The CUDA plugin is faster on my machine at 3840x2160. It was ported because not everyone has an nVidia GPU and I was bored.

[rean]

TheFluff, there are many different fixes in my AvistnthMT mod. For example there is no thread sync in some resizers where assembly code is generated on the fly. But most bugs are related to MT cache. SEt created own cache code for some reasons, but the implementation is not optimal, because some frames tends to get extreme high priority and cannot being disposed at all. So we have a permanent memory leak that tends to get processing crashed after some couple processing minutes. Another my improvements are connected to some cache code improvement to work better if memory is full. And some another "traditional" crashes are related to plugin memory vs AviSynth memory dilemma. Most source plugins cannot work if memory is near full.

And, totally, my build is based on some unknown SEt build, because the diff file posted by SEt is not for the latest SEt binary build. I made a couple of changes to get it compiled. So many places are not identical. I tried to ask SEt to get the real diff but get no response. So we unknown is there any hidden fixes those are not available in my build. But in generally I had no another bugs while using my build these years.

In general sense a CPU version of 3DLUT cannot be faster than CUDA version. CUDA is generally an engine that executes precompiled C-like code on every tread on GPU directly. 3DLUT code can be perfectly optimized because can process every pixel on own thread. Probably you mean thet on Vapoursynth and AVS a memory transfer to GPU and back is slower than direct CPU computing of everything. But I mean using CUDA on Resolve. Where frame buffer is already allocated on GPU memory. And if OpenFX developer want, it can use this feature. So very simple plugins can run faster on GPU as OpenFX.

I already have some OFX plugins developmeng. On my i7 4Ghz processing is 2 fps, but on CUDA and OpenCL it is ~ 100-200 fps. On very old Nvidia GTX-960.

About HDR, yes. But I know some conversions may be destructive even in HDR, because mathematical limitations with floating point. I had no experience with BT.2020 yet, so probably it is really hard as you mean. But I know many issues with LOG to Rec709 and back, so agree with you.

[poisondeathray]

But, these next years, Avisynth and also 3DLUT processing in it will dead, because CUDA and GPU processing on free software like Fusion or Resolve is a reality. Blackmagic changes the video production some years age and many video software is dead. There is also a free license option for Nuke for home users. I move to OFX plugin development as more potential. And many Avisynth plugins may be ported to OpenFX. The API is very similar.
The way I vew it as more tools in the toolbelt. Certain workflows can certainly use them

Also add blender, natron to that list . Natron is like an open source nuke (hell, the GUI is a nuke copy) with OFX support, gmic, community plugins - really fantastic . Nuke (free version) is non commercial - you can't use it for client projects, and there are quite severe limitations compared to the other versions



It was ported because not everyone has an nVidia GPU and I was bored.

I like it when you're bored :D

[videoh]

Don't forget that offloading to the GPU frees up CPU for encoding. And don't forget that just as not everyone has a high-end GPU, not everyone has a high-end CPU.

[Groucho2004]

It would be really interesting to have some actual benchmarks to verify rean's claims against modern alternatives but it's such a pain to use I can't be bothered, and the burden of proof should probably be on the party attempting to charge money for these things anyway.Well, I decided to give it a go.

Here's the script, QTGMC (latest version, latest plugins) with a short, interlaced SD clip:

##For AVS+, the "SetMTMode" statements are removed
and "prefetch(5)" placed at the end of the script.

SetMemoryMax(1200)
SetMTMode(5,5)
LoadPlugin("f:\qtgmc_bench\source\DGDecode.dll")
MPEG2Source("f:\qtgmc_bench\source\bench.d2v", idct = 3)
AssumeTFF()
SetMTMode(2)
QTGMC(Preset = "Slow", edithreads = 2)


SEt's latest MT:
[Runtime info]
Frames processed: 3408 (0 - 3407)
FPS (min | max | average): 8.66 | 275349.58 | 72.42
CPU usage (average): 82%
Thread count: 16
Physical Memory usage (peak): 1226 MB
Virtual Memory usage (peak): 1289 MB
Time (elapsed): 000:00:47.056


rean's build:
[Runtime info]
Frames processed: 3408 (0 - 3407)
FPS (min | max | average): 6.35 | 198863.59 | 52.58
CPU usage (average): 93%
Thread count: 16
Physical Memory usage (peak): 1229 MB
Virtual Memory usage (peak): 1288 MB
Time (elapsed): 000:01:04.816

Note: Slower AND more CPU usage -> much less efficient.


Latest AVS+:
[Runtime info]
Frames processed: 3408 (0 - 3407)
FPS (min | max | average): 4.36 | 255681.83 | 78.99
CPU usage (average): 90%
Thread count: 26
Physical Memory usage (peak): 398 MB
Virtual Memory usage (peak): 429 MB
Time (elapsed): 000:00:43.143

[wonkey_monkey]

FPS (min | max | average): 8.66 | 275349.58 | 72.42

Forgive my ignorance, but what gives with that huge number? Without knowing where that's come from I wouldn't put much faith in the averages as being indicative of much.

[Groucho2004]

FPS (min | max | average): 8.66 | 275349.58 | 72.42

Forgive my ignorance, but what gives with that huge number?These are cache hits I suppose. You can see this frequently with temporal filters and/or multi-threading.
Here is the data for frames 1 - 100 (0 - 99) from the AVSMeter log file:
[Performance data]
Frame Frames/sec Time/frame(ms) CPU(%) Threads Memory(MiB)
1 7.594 131.687962 0.0 16 35
2 103.782 9.635582 0.0 16 35
3 81353.289 0.012292 0.0 16 35
4 68.019 14.701869 0.0 16 35
5 18.184 54.994139 0.0 16 35
6 120.434 8.303290 0.0 16 35
7 63.635 15.714567 0.0 16 35
8 69.022 14.488154 0.0 16 35
9 25.606 39.053287 0.0 16 35
10 38.971 25.660244 0.0 16 35
11 98.803 10.121119 0.0 16 35
12 34.482 29.000335 0.0 16 35
13 46.200 21.644930 0.0 16 35
14 48.642 20.558479 0.0 16 35
15 27.819 35.946468 0.0 16 35
16 217.959 4.588013 0.0 16 35
17 28.868 34.640158 0.0 16 35
18 179.795 5.561880 0.0 16 35
19 22.854 43.756958 83.8 16 636
20 61.100 16.366605 83.8 16 636
21 66.871 14.954136 83.8 16 636
22 41.108 24.326277 83.8 16 636
23 32.570 30.702785 83.8 16 636
24 89.141 11.218185 83.8 16 636
25 28.581 34.988525 83.8 16 636
26 54.199 18.450669 83.8 16 636
27 40.589 24.637210 83.8 16 636
28 61.181 16.344814 83.8 16 636
29 26.367 37.926886 83.8 16 636
30 64.704 15.455036 83.8 16 636
31 41.699 23.981539 83.8 16 636
32 67.559 14.801881 83.8 16 636
33 26.360 37.936107 83.8 16 636
34 61.803 16.180548 83.8 16 636
35 60.916 16.416053 83.8 16 636
36 30.516 32.769249 83.8 16 636
37 33.666 29.703494 83.8 16 636
38 57.611 17.357793 83.8 16 636
39 34.117 29.311267 83.8 16 636
40 430.441 2.323200 83.8 16 636
41 29.034 34.442647 84.4 16 1181
42 59.651 16.764142 84.4 16 1181
43 38.804 25.770316 84.4 16 1181
44 67.581 14.797132 84.4 16 1181
45 32.718 30.564220 84.4 16 1181
46 58.395 17.124802 84.4 16 1181
47 125.753 7.952128 84.4 16 1181
48 38.957 25.669184 84.4 16 1181
49 33.270 30.057174 84.4 16 1181
50 151.624 6.595252 84.4 16 1181
51 28.822 34.695470 84.4 16 1181
52 72.349 13.821868 84.4 16 1181
53 72.490 13.795049 84.4 16 1181
54 42.238 23.675636 84.4 16 1181
55 35.871 27.877286 84.4 16 1181
56 77.412 12.917843 84.4 16 1181
57 31.644 31.601224 84.4 16 1181
58 111860.781 0.008940 84.4 16 1181
59 25.094 39.849479 84.4 16 1181
60 163.025 6.134020 84.4 16 1181
61 46.250 21.621463 84.4 16 1181
62 35.960 27.808562 84.4 16 1181
63 46.832 21.352994 84.4 16 1181
64 133.900 7.468268 84.4 16 1181
65 45.243 22.102809 84.4 16 1181
66 22.832 43.797745 97.0 16 1202
67 321.381 3.111569 97.0 16 1202
68 61.172 16.347329 97.0 16 1202
69 49.971 20.011481 97.0 16 1202
70 38.302 26.108626 97.0 16 1202
71 48.849 20.471317 97.0 16 1202
72 51.269 19.504993 97.0 16 1202
73 70.117 14.261868 97.0 16 1202
74 70.234 14.238123 97.0 16 1202
75 33.132 30.182329 97.0 16 1202
76 66.627 15.008891 97.0 16 1202
77 37.092 26.960131 97.0 16 1202
78 76.742 13.030706 97.0 16 1202
79 41.218 24.261183 97.0 16 1202
80 82.446 12.129195 97.0 16 1202
81 27.242 36.708018 97.0 16 1202
82 99431.813 0.010057 97.0 16 1202
83 28.252 35.395561 97.0 16 1202
84 137.707 7.261817 97.0 16 1202
85 43.041 23.233399 97.0 16 1202
86 33.221 30.101313 97.0 16 1202
87 49.942 20.023216 97.0 16 1202
88 146.577 6.822376 97.0 16 1202
89 47.484 21.059661 97.0 16 1202
90 36.087 27.710504 97.0 16 1202
91 49.527 20.190834 97.0 16 1202
92 82.524 12.117742 95.3 16 1218
93 39.161 25.535369 95.3 16 1218
94 38.589 25.914187 95.3 16 1218
95 56.399 17.730745 95.3 16 1218
96 36.266 27.574173 95.3 16 1218
97 119318.164 0.008381 95.3 16 1218
98 28.519 35.063953 95.3 16 1218
99 138.057 7.243379 95.3 16 1218
100 32.199 31.056739 95.3 16 1218

[wonkey_monkey]

Oh I see, I was thinking of that number the wrong way round. That makes perfect sense.

[rean]

short, interlaced SD clip
SetMemoryMax(1200)
SetMTMode(5,5)
edithreads = 2
6.35 | 198863.59 | 52.58

Yet another useless benchmark with not optimal settings with very strange small clip, no output encode... that shows nothing real. My usual large scripts use a lot of different plugins include resizers, luts, denoise, sharp, color correction and also x264 10bit or ProRES 10-bit encode with extreme settings that I use in real video production within years.

Test real full hd large h.264 video files with optimized settings that also encodes the result back to the disk as you usually use Avisynth for production.

Do not test min/max/average fps - it is just a useless piece of digits that shows nothing. If you want to create a good test program, it should average fps within a few seconds, but is also useless because some scenes using denoise you can give up to 10x fps difference frame to frame.

Do not test thread count and CPU usage. There are many cases when 5% CPU usage can produce video much faster than 100% cpu usage when it just swapping cache buffers because memory limits and cache mismatch logic.

Do not test small video sources you never use in real projects. You will test for nothing.

DO not test without encode. It is also useless. We want processing speed but not to see how some software just eats power.

Do not test anything with incorrect memory optimization. First of my AvisynthMT build is optimized for 3000+ memory max, and using 1500 and smaller memory usage is the case when SEt MT build is good optimized for speed and where because it has processing bugs on big video files.

Do not test small video fragments, because in real usage SEt MT build just crashed on large files after some minutes.

Do not test different software with the same settings. Different software works differently, so you need to improve setting on every case to get the fastest result then compare.

I understand that my recommendations are useless for you, because you just want test for flame. But I write it for users who just want to get maximal speed of using software for real processing.

[rean]

Another things you should know using different Avisynth builds:

On small scripts where no big memory is required, the AvsMT+ uses frame cache differently than Avisynth. It keeps memory, and it adds new frame buffer if really there are parallel usage requirements. So it keeps memory. It works perfectly for small scripts using many processing threads. On large scripts when we cannot keep all frames, it will loose cache and in some cases it will hangs. So we need to decrease threads to get maximal possible thread count. Using Memory max on in it gives you less additional speed, because additional memory is not used.

On small scripts SEt MT works perfectly with small memory. It has additional MT cache to keep flames. You can also try as many threads as you can give to get 100% CPU usage. But for large scripts and large video it cannot keep all frames to memory and there is also a memory leak in the MT cache. So on large scripts it is recommended to keep ~2000 memory for memory leak. If your video is small, it will work. But remember, to give it work, you must keep memory max on it ~1000-1500 or you will get crash. If you process small video on small threads, keep cache as small as you can, because that cache combination: MT cache + Avisynth cache works perfectly. So in the forum you will get many old recommendations to give 64mb to 800. It is because it is really works faster on small cache for SD sources and keeps memory leak.

On small scripts my AvisynthMT mod works not optimal. I changed memory constants those really optimized for memory frames for SD sources. Now they are optimized for full hd. Also it is optimized for full memory use. Recommended values are 3000-3600. Below 3000 there is a speed decreasing because my new MT cache code mod works not optimal. Some edit-time cache optimizations are removed, so it can work less speed than SEt build. But if we have large scripts where memory is a key, my build works stable where SEt build crashes. So we can try use more threads than SEt build. On UHD videos and large scripts there also new optimization code is working that allows to use memory in some not-parallel way, you can get big cpu usage, but slow processing. In these cases you need to decrease thread count to 2-3. If comparing to SEt build, it cannot work at all on these conditions - permanent crashes. So you should know - my build allows not to crash on large scripts and it works much better on large memory max, but SEt build works on small memory max.

If you will compare all three software, on optimal settings and small scripts and SD video AviSynth+ will work better. On real but not complex scripts, all the builds should work the same speed, but if you use small memory max, my build will work slower, because not optimized for these cases. On large scripts and large frames, Avs+ and my build should work the same speed, but SEt build may crash. On very large scripts with UHD video and no any chance to get all frames on memory, SEt build will always crash. Avs+ can work but it tends to hangs (deadlock?). My build will still work, but if it can reach absolutely memory limit, it can still crash because no memory. If you have these cases, you should know, that no any build will work on these situations and you should switch MT processing off on all Avisynth clones.

On real encode cache and real big scripts, Avs+ will work a less slowly than my build because it uses much more threads, and content switch time will eats CPU but real processing speed will be a bit slower.

So the conclusion: do not use SEt build because bugs. You can get crashes after 2-3 hours of processing or on 5-15 minutes. We do not know the exact time and you will get random crashes. For real encode you can use both Avs+ or my build. They give around the same level stability and speed. But if you use old plugins, my build is compatible, because it is native Avisynth with additional MT modes those can be complete disabled.

If you use Video Artifact or extreme large scripts, the situation is different: my build is a winner, because all VA script use extreme large memory amount, we will use cache optimizations for these cases. Also you have better stability and only tested stable plugins. I never include modern plugin versions because stability.

For most possible speed on any biuld you should know that more threads is not always good. You should give to the encode program and for video reading source filter as many processor time as you can. So in real cases 1-2-3 threads for Avisynth may be the best possible case. Even if you use some benchmark tools these aggressive promoted here - do not trust them. These tools are good for plugin developers. You must test your processing using a timer. Keep less threads on Avisynth code and give some additional threads to key plugins like mvtools and source reading. For complex scripts give a memory headroom. Not always 3500 memory max is good. Not always CPU usage is good. Use only timer for benchmark.

[Groucho2004]

I just skimmed through all this, it seems that your avisynth.dll works only well with very specific scripts which apparently have to be very large. Whatever.

Anyway, this response is more or less what I was expecting. I'll leave it to others to make sense of it.

[rean]

Groucho2004, of course. If someone use 64-bit plugins only, they should use AvisynthMT+ only. I use x86, where memory full cases is a reality, and my mod is created some years ago when Avisynth+ was not stable, and specially for memory full cases.

Today we can buy multi-core processors with 6+ cores, where using x86 is not possible because memory model limitations of Avisynth MT. Unfortunately for some reasons I need to use x86 only, so I use my mod as stable and also faster on scripts typically used for my tasks and my hardware. If some users like my mod too, it is great, but not a way to get a war Avisynth+ vs AvisynthMT.

So I ask you not to inflate these talk about speed, as meaningless. We all understand the trends, and each of us has different hardware and projects. If there is a head on the shoulders, then for selection it is necessary to test everything.

[Groucho2004]

All this is off-topicYes, this is way off topic and hopefully a mod could move it to a separate thread, probably starting with post #39.

[WorBry]

All this is off-topic (and boring!). Can we please forget about rean's commercial framework and its performance and get back to 3D LUT stuff with free plain vanilla AVS(+)?

Yes, this is way off topic and hopefully a mod could move it to a separate thread, probably starting with post #39.

+1, maybe even at post #36.

[Wilbert]

Moved to seperate thread.

[videoh]

Thanks for splitting, Wilbert.