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. |
21st May 2016, 19:45 | #301 | Link |
The image enthusyast
Join Date: Mar 2015
Location: Brazil
Posts: 270
|
Both in Windows Media Player, last version, and in MPC-BE, last stable version, shows: "it's not possible render the file", translating from portuguese.
__________________
Searching for great solutions |
22nd May 2016, 01:22 | #303 | Link |
The image enthusyast
Join Date: Mar 2015
Location: Brazil
Posts: 270
|
I think the problem, or an it piece, is in Avisynth 2.6.0, because I've tried run a simple Bicubic upscaling, and I didn't can make it.
As I told you, I installed it again, but I didn't have time enough to play with it. What I guessed so strange was the instability of SuperResXBR. One time, the script I wrote worked; other time, it didn't do. I was with MPC-BE 1.4.6 beta (From this I ran SuperResXBR script). I was think it was the problem, then I go back to MPC-BE 1.4.5 stable, but the problem wasn't it. I will install the MPC-BE 1.4.6 beta again.
__________________
Searching for great solutions Last edited by luquinhas0021; 22nd May 2016 at 01:24. |
22nd May 2016, 01:55 | #304 | Link |
The image enthusyast
Join Date: Mar 2015
Location: Brazil
Posts: 270
|
You wrote that SuperRes with passes = 2 generates a bigger file, when compressed, that SuperRes with passes = 3. This means passes = 2 makes a sharper (Or more detailed) image?
Can I say that this script is like a SuperResXBR visible sharpest (Or more detailed) settings: SuperResXBR(Passes=2 or 3, Str=1, Soft=0, XbrStr=5, XbrSharp=1.5, fDownscaler="SSim", fStr=1, fSoft=false, fB=0, fC=1)? Ah, your last image comparison show the clown and lighthouse images, but it's four by four times bigger than the original ones, no-upscaled, that you show in first image comparison. But the SuperResXBR has factor 2 of upscaling. So, can you put here the original images you used in last image comparison?
__________________
Searching for great solutions |
22nd May 2016, 06:31 | #305 | Link | ||
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Quote:
Passes=5 loses some details somehow. I'm running it twice: Double+InterFrame+Double. I just tried the first double with 5 passes and the 2nd with 3 passes and the result was great! Here's the file size with each pass settings 2 passes: 89.6MB 3 passes: 88.3MB 4 passes: 87.8MB (loss of details) 5 passes: 87.6MB (loss of details) 5 passes + 3 passes: 87.4MB (sharp!) Quote:
In the screenshots above, I'm using SuperResXBR(3, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, fWidth=1012, fHeight=778, fDownscaler="Bicubic", fB=0, fC=.75) The original images are in the first post of this thread. |
||
23rd May 2016, 01:49 | #306 | Link |
The image enthusyast
Join Date: Mar 2015
Location: Brazil
Posts: 270
|
MysteryX, honestly, I didn't see any difference between 3 passes and 5 + 3 passes, unless artifacts shift. My screen is good and has optimal color/luminous calibration, and I saw with zoom 100%.
Mystery, I used this above script for Clown and Lighthouse images, but, fortunately, it didn't stay distorted or with big halos: SuperResXBR(Passes=3, Str=1, Soft=0, XbrStr=4, XbrSharp=1.5, fDownscaler="SSim", fStr=1, fSoft=false, fB=0, fC=1) Maybe I down XbrStr from 4 to 3.7, in order to avoid any possible distortions, without loss of details and sharpness. But this is it! You had spoken SSIM retains more details that Bicubic; after, spoke Bicubic 0.75 and SSIM 0.8 are almost equal, but the edges in Bicubic 0.75 are sharper (I imagine 0.75 and 0.8 refers to "fC" parameter). This why I put SSIM with fC=1: retain more details and to be equal or sharper than Bicubic 0.75.
__________________
Searching for great solutions Last edited by luquinhas0021; 23rd May 2016 at 02:03. |
23rd May 2016, 04:34 | #307 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
SSim doesn't use fB and fC parameters
Are you really seeing better results with SSim than with Bicubic before applying SuperRes? I'm considering changing the default downscaling method to Bicubic. or maybe, to avoid confusion, I could share the same fB and fC parameters for both SSim or Bicubic, and remove fStr and fSoft. |
23rd May 2016, 05:05 | #308 | Link |
The image enthusyast
Join Date: Mar 2015
Location: Brazil
Posts: 270
|
I didn't test Bicubic, because, when I tried run the script, happened the error I told you.
I'm considering the technical information you spoke. SSIM doesn't use fB and fC parameters in your plugin or, really, it, originally, don't have b and c parameters? Where is 0.8, from SSIM 0.8, from? There's way like I increase or decrease this number? I don't advice you remove fStr neither fSoft anyhow, unless you put, by default, fSoft=0 and fStr=1.
__________________
Searching for great solutions Last edited by luquinhas0021; 23rd May 2016 at 05:21. |
23rd May 2016, 08:21 | #309 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
SSim uses fStr=.5 and fSoft=false by default.
Bicubic uses fB=0 and fC=.75 by default. "maybe" I could change the syntax so that SSim uses fB instead of fStr and fC instead of fSoft (0 or 1) This syntax simplification could become more significant if another downscaler gets added into the mix. You cannot run it with Bicubic but it works with SSim? What error are you getting? |
23rd May 2016, 20:17 | #310 | Link |
The image enthusyast
Join Date: Mar 2015
Location: Brazil
Posts: 270
|
MisteryX wrote:
"SSim uses fStr=.5 and fSoft=false by default." Change fStr to 1: people doesn't matter with a few rings if sharpness and detail maintenance is bigger! MisteryX wrote "maybe" I could change the syntax so that SSim uses fB instead of fStr and fC instead of fSoft (0 or 1)" MisteryX wrote In Bicubic, "b" is relative to softness and "c" to sharpness. I think you will make trouble in user's head if you put the SSIM parameters in way you told. MisteryX wrote "You cannot run it with Bicubic but it works with SSim? What error are you getting?" There's was a time when SSIM ran; there's was a time when it didn't run; with Bicubic, never run.
__________________
Searching for great solutions |
24th May 2016, 04:07 | #311 | Link | ||
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Quote:
Using fB and fC arguments for both kernels isn't different from the way other shared resizers work such as ResizeX, where you have 2 parameters to configure whatever kernel is selected. Quote:
And that way, it's lot easier to implement other resizers. |
||
25th May 2016, 14:42 | #313 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Version 1.4.4 is ready!
What's new: - Renamed SSimDownscaler to ResizeShader - Removed fStr and fSoft arguments. With SSim, fB = Strength (0 to 1), fC = Soft (0 or 1) - Renamed fDownscaler argument to fKernel and Downscaler to Kernel - fKernel and Kernel default value is now Bicubic - DLL now specifies its supported MT modes to AviSynth+ so SetFilterMTMode is no longer necessary |
2nd June 2016, 04:46 | #314 | Link | |
Registered User
Join Date: Feb 2004
Location: NYC
Posts: 124
|
Quote:
I ask because it a resize is supposed to be done before color matrix processing when using Dither. Last edited by bilditup1; 2nd June 2016 at 05:01. Reason: explained why I'm asking this. |
|
2nd June 2016, 05:55 | #315 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
AviSynthShader needs to convert from YUV to RGB to process anything anyway. If you want to downscale the image, you might as well use SSim and convert colorspace at the same time. This will convert from Rec601, resize using SSimDownscaler, and convert back using Rec709
Code:
ResizeShader(Width, Height, Kernel="SSim", MatrixIn=601") |
2nd June 2016, 08:13 | #316 | Link | ||
Registered User
Join Date: Feb 2004
Location: NYC
Posts: 124
|
Quote:
Code:
ResizeShader(Width, Height, Kernel="Bicubic", MatrixIn="709", MatrixOut="601") Also: should this be done before or after deinterlacing? After, is what I'd guess. One more thing - Quote:
Last edited by bilditup1; 2nd June 2016 at 09:40. |
||
2nd June 2016, 11:21 | #317 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
De-interlace first.
The difference between ColorMatrixShader and ResizeShader is that the various Shader functions allow processing the color correction at the same time without any performance penalty. And since the bottleneck is in memory transfers, performing various operations at once is a great performance benefit. Use ColorMatrixShader only when you don't need any of the other functions to perform that operation alone. |
2nd June 2016, 12:19 | #318 | Link | |
Registered User
Join Date: Feb 2004
Location: NYC
Posts: 124
|
Quote:
|
|
3rd June 2016, 11:11 | #319 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Version 1.4.5 is ready!
What's new: - DitherTools (lsb_in/lsb_out) support was broken for the various functions and has been fixed - ConvertToShader and ConvertFromShader now use Bicubic for chroma resizing when lsb=true - ConvertToShader and ConvertFromShader now give an error if lsb=true and Precision=1 Note: There is still an issue where the x64 version takes over twice as much memory When processing YV12 data, there is a slight loss of chroma data during the ConvertToYV24 conversion. If you want maximum quality, you should first convert to YV24 using DitherTools and set lsb_in and lsb_out to true. However, this may degrade performance by half because memory transfers are the bottleneck. Code:
Dither_convert_8_to_16() Dither_resize16(Width, Height/2, kernel="Bicubic", csp="YV24") SuperResXBR(5, 1, 0.15, XbrStr=2.7, XbrSharp=1.3, MatrixIn="601", lsb_in=true, lsb_out=true) Dither_resize16(Width, Height/2, kernel="Bicubic", csp="YV12") DitherPost() So the rule of thumb is: with the smaller image, try to preserve as much of the details before extrapolating it. With the larger image, you can trade quality for performance as the loss of details is only extrapolated data anyway. |
6th June 2016, 11:05 | #320 | Link |
Soul Architect
Join Date: Apr 2014
Posts: 2,559
|
Version 1.4.6 is ready!
What's new: - Minor performance improvements - Removed ColorMatrixShader - ConvertFromShader no longer uses 'invks' when converting to YV12 using DitherTools About ColorMatrixShader, it was designed to shift the color matrix in 16-bit to avoid banding. However, because it was calling ConvertToYV24 and ConvertTo12, rounding occured there which nullify any advantage over the standard ColorMatrix function or over the DitherTools conversion method. As a work-around, I could make ColorMatrixShader convert between YV12 and YV24 using DitherTools, but if it depends on DitherTools, it has no advantage over simply doing it the DitherTools way. Thus, I removed this function. The best way to do shift the color matrix is to do it while calling another function such as SuperResXBR; or to use the standard methods (ColorMatrix or DitherTools). If you want to avoid rounding errors (loss of data) when processing YV12, first convert it to 16-bit LSB format using DitherTools (Dither_convert_8_to_16) and call the shader method with lsb_in=true, lsb_out=true. It will then automatically perform the conversion between YV12 and YV24 in high-bit-depth. ConvertToShader/ConvertFromShader will then internally convert using these functions Code:
Dither_resize16nr(Width, Height/2, kernel="Spline36", csp="YV24") Dither_resize16nr(Width, Height/2, kernel="Spline36", csp="YV12") |
Thread Tools | Search this Thread |
Display Modes | |
|
|