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. |
|
|
Thread Tools | Search this Thread | Display Modes |
15th July 2019, 18:43 | #1 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
CropResize - Cropping & resizing function (Avisynth & VapourSynth versions)
From the version dated 2023-09-28:
There's now a native VapourSynth flavour of CropResize. A new TCRatio argument (Top Cropping Ratio) has been added. See the CropResize Changes text file for details. Support for resizing based on a sample aspect ratio in frame properties has been added. Some other minor updates are listed in the CropResize Changes text file. CropResize 2023-10-28.zip The purpose of the script The main goal of CropResize is to crop and resize without having to worry about calculating aspect error or distorting the picture. Rather than distort the picture as traditional resizing does when the input and output aspect ratios don't match, the script crops or adds borders instead. It can apply sub-pixel cropping when required. Despite the numerous options, basic usage is fairly straightforward. The pictures in post #2 illustrate CropResize usage. Last edited by hello_hello; 28th October 2023 at 22:12. |
15th July 2019, 18:44 | #2 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
The easiest way to demonstrate CropResize is with some pictures
Some of these examples also demonstrate using the wrapper functions supplied with CropResize to easily enable the default cropping preview or set Info=true, and some also use the abbreviated function name of CR(). The (home made) PAL 16:9 source used for the following examples Basic usage Simply specify a width (or height) and the desired cropping (or enable auto-cropping), along with the input display aspect ratio if the source is anamorphic, and let CropResize take care of the rest, here resizing to "square pixel" dimensions. The abbreviated function name CR() can be used instead of CropResize() if the wrapper functions script is loaded. CropResize(832,0, 4,32,-6,-32, InDAR=16.0/9.0, Info=true) or CR(832,0, 4,32,-6,-32, InDAR=16.0/9.0, Info=true) Cropping according to the output dimensions When specifying both an output width and height, and borders aren't enabled, the script crops accordingly to prevent aspect error (although specifying an OutDAR takes precedence over the cropping and output display aspect ratio). Simply to demonstrate, here 16:9 output dimensions are specified. CropResize(832,468, 4,32,-6,-32, InDAR=16.0/9.0, Info=true) Adding borders according to the output dimensions When specifying both an output width and height, and borders are enabled, the script adds pillarbox or letterbox borders as required instead of cropping picture (a small amount of extra cropping may still be applied to prevent aspect error). As for the previous example, 16:9 output dimensions are specified. CropResize(832,468, 4,32,-6,-32, InDAR=16.0/9.0, Borders=true, Info=true) MeGUI support MeGUI was used to crop the source, adding it's global DAR variables and cropping to the script. CropResize then takes care of the resizing and any extra cropping required to prevent aspect error. global MeGUI_darx = 71 global MeGUI_dary = 36 Crop(4,32,-6,-32) CropResize(832,0, Info=true) Specifying an output display aspect ratio and adding borders Cropping and resizing to NTSC dimensions with an mpeg4 display aspect ratio of 20:11 (including the added borders). CropResize(720,480, 4,32,-6,-32, InDAR=16.0/9.0, OutDAR=20.0/11.0, Borders=true, Info=true) Cropping according to the output display aspect ratio When an output display aspect ratio is specified and borders aren't enabled, the script adjusts the cropping to crop to that display aspect ratio and resizes to the specified width and height. Here the picture is cropped to 16:9 and resized to NTSC 720x480 dimensions. Exactly the same result can be achieved with the appropriate output sample (pixel) aspect ratio instead of a display aspect ratio. In this case it'd be 32:37. CropResize(720,480, 4,32,-6,-32, InDAR=16.0/9.0, OutDAR=16.0/9.0, Info=true) or CropResize(720,480, 4,32,-6,-32, InDAR=16.0/9.0, OutSAR=32.0/27.0, Info=true) Resize Width Only For the purists, there's a "Resize Width Only" mode, preventing height resizing. It's mainly intended for anamorphic sources and supports anamorphic input/output, but here there's no output display aspect ratio specified, so the script is automatically cropping and resizing the width to "square pixel" dimensions. The function name is preceded with "i" to set Info=true iCR(0,0, 4,32,-6,-32, InDAR=16.0/9.0, ResizeWO=true) No Resizing Resizing can also be disabled completely so the function only crops (it can still add borders though). CropResize(0,0, 4,32,-6,-32, InDAR=16.0/9.0, NoResize=true, Info=true) Color conversion Probably a bit hard to see the difference here, but in addition to automatic color correction, the ColorMode argument permits specifying a color conversion. CropResize(832,0, 4,32,-6,-32, InDAR=16.0/9.0, ColorConvert="HDRMatrix", ColorMode="709-601", Info=true) Cropping previews Output dimensions of 16:9 are specified without borders enabled (832x468) but the specified cropping is not enough to crop the picture to 16:9, so the script must crop extra from the sides. The yellow lines show the cropping specified by the user. The blue lines show any additional cropping applied by the script to prevent aspect error. The default cropping preview can be enabled by preceding the function name with "p". pCropResize(832,468, 4,32,-6,-32, InDAR=16.0/9.0) or pCR(832,468, 4,32,-6,-32, InDAR=16.0/9.0) or CropResize(832,468, 4,32,-6,-32, InDAR=16.0/9.0, CPreview=1) Also note: Preceding the function name with "pi" enables both the default cropping preview and sets Info=true, assuming the wrapper functions script is loaded. CropResize(832,468, 4,32,-6,-32, InDAR=16.0/9.0, CPreview=2) CropResize(832,468, 4,32,-6,-32, InDAR=16.0/9.0, CPreview=3) An AvsPmod style preview. FrostyBorders CropDAR used to force a cropping of 4:3, with 16:9 output dimensions to demonstrate adding FrostyBorders. CR(832,468, 4,32,-6,-32, CropDAR=4.0/3.0, InDAR=16.0/9.0, Frosty=true) Last edited by hello_hello; 19th November 2022 at 15:33. |
16th July 2019, 00:49 | #3 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
As is always the case, I found a minor gremlin not long after creating this thread. Sometimes Info=true wasn't displaying the output sample aspect ratio when resizing was disabled. The link in the opening post has been updated. The fixed version is dated 2019-07-17.
|
7th August 2019, 20:57 | #4 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
There's a new version of CropResize (2019-08-08). The link in the opening post has been updated.
The changes are aimed at making the script's behaviour more predictable, although there's not a lot of them. The cropping and resizing functionality remains the same. There's a list of changes in the zip file. |
7th August 2019, 22:14 | #5 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,032
|
Thank you!!
Just one thing: Quote:
That's just what I had in mind, anyway, nice resizing script, thank you! |
|
7th August 2019, 23:13 | #6 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
Quote:
As I prefer it though, I added it back to a version of the script for myself. It still only converts between HD and SD with ColorMatrix.dll, but unlike the previous version it doesn't convert when the source or destination resolution exceed 1080p. Because it was for me I didn't add an argument for it, but I included a way to disable it by changing a line about 12 lines from the bottom of the script, along with some of the other defaults. It looks like this: function CR_ColorCorrect() { return true } If you want a version with a function argument, it shouldn't be too hard to add it back. Anyway, here's a link for my ColorMatrix version. Edit. Link removed. See post #8. Aside from the color conversion, everything else is the same, including the function name. So you know what the rules are, it automatically color converts when downscaling if the source "display" width is > 1056 or the source height is >= 600 and the destination "display" width is <= 1056 and the destination height is < 600. Upscaling the rules are the same for source and destination width and height. Info=true will still tell you when color conversion is taking place. Last edited by hello_hello; 9th August 2019 at 00:15. |
|
9th August 2019, 00:12 | #8 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
FranceBB,
as it turns out, you talked me into it. Color conversion has been added back to the "official" version. It's now dated 2019-08-09. I'll update the link in the opening post shortly. I've added back the ColorCorrect argument, but rather than true or false, 0 is disabled, 1 converts with ColorMatrix.dll, and 2 converts with DitherTools. Conversion between SD, HD and UHD colorimetry is now supported. I don't think there's a 64 bit version of ColorMatrix with Rec.2020 support, but the included 32 bit version has it. It supports YV12 & YUY2. DitherTools supports Rec.2020 and YV12, YV16, YV24, YV411, and Y8. The function for setting the default can still be found near the end of the script, and now looks like this. function CR_ColorCorrect() { return 0 } So you can enable either conversion method as the default and use ColorCorrect=0 to disable it, or leave it disabled by default and use ColorCorrect=1 (or 2) as required. I've updated the help file Feel free to check my work. I'm new to converting with DitherTools. The color conversion section is about halfway down the script. |
9th August 2019, 09:03 | #9 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
Damn!
Sorry folks, I just noticed a silly in the definition of SD, HD and UHD resolutions for color conversion. I used "or" when I should have used "and" and "and" when I should have used "or". I'll fix it shorty and update link in the opening post and change the version date to 2019-08-10. |
9th August 2019, 11:27 | #11 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
The opening post is updated again now. I didn't change the version date again as the link was only active for a few minutes before I pulled it to upload a version that also checks for bitdepth when using Avisynth+, as currently only 8 bit video is supported for automatic color correction. Now I remember why I removed it originally.
I don't actually know how to color convert video with bitdepths greater than 8 bit, but I've come this far.... What's used for color conversion these days (I won't bother with stacked 16 bit, but for native Avisynth+ bitdepths > 8)? Maybe I should also add an argument for specifying an output bitdepth? Cheers. |
9th August 2019, 15:42 | #13 | Link | ||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,032
|
Quote:
Quote:
|
||
9th August 2019, 17:23 | #14 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
Quote:
There's an included resizing wrapper function (CR_Resize16X) that uses the ResizeX script and DitherTools to resize in 16 bit, and it can be configured to output a stacked 16 bit clip, but even that would throw a spanner in the works as the script decides whether to add borders and color correct after resizing, and it'd probably calculate the wrong DAR for MeGUI even though it'd still crop and resize correctly. Given stacked 16 bit is a legacy format, I'm not sure it's worth accommodating. I looked at avsresize, but the order in which the script does things would probably require a bit of adjusting because it'd be silly to not have it do both the resizing and color conversion. Plus it appears not to run on XP (I assume that's the problem). I'll check out HDR Tools at some stage though, when I'm not bored with looking at the script. If it'll simply color convert any native Avisynth+ bitdepth as ColorMatrix does for 8 bit, then I can probably add the color conversion without having to worry about the input/output bitdepth as such. Assuming it runs on XP? If not, I'll have to modify the script and ask you to test it for me. PS And what about HDR video? Should I think about that or is it impossible to have the script handle it automatically (in respect to color correction)? Last edited by hello_hello; 9th August 2019 at 18:04. |
|
10th August 2019, 15:04 | #15 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,032
|
Right, 16bit stacked or interleaved output MSB and LSB stacked or interleaved one with the other, so it would screw up the calculation made by the script as the resolution would be wrong. As to HDRTools by JPSDR, I can tell you that it works absolutely fine on Windows XP, however it might require a lot of RAM for UHD sources and BT2020 to be processed with 16bit precision and that's an issue for 32bit systems 'cause it would have to be split using MPPipeline in order to avoid to hit the maximum memory available per single process. Anyway, as to HDR, that's not an easy task, as you are no longer dealing with resolutions and color matrices, but with color curves. Hence, there isn't a perfect mathematical formula to go from a curve to another and the way you would be bringing something to something else would be according to what looks best for you and once you have done it, there's no way to go back. What I mean by this is that you should think about PQ, HLG and BT709 linear as curves and in order to go from a curve to another you need a function that takes some values in input and outputs some other values... however, from our Calculus class we know that functions can be 1 to 1 or onto and if they are both 1 to 1 and onto then they are bijective. Viewing this in a linear algebra setting means that the matrix of linear transformation associated with our function is an isomorphism which basically means that we can go back and forth between the input and the output losslessly 'cause we can invert them, but when you are dealing with PQ, HLG and BT709 linear, there's no way to have an isomorphism and to go back to where you started losslessly.
I've been talking about this more in depth in my "FranceBB LUT Collection" as I thought that it was an interesting topic for linear algebra lovers and because companies were selling matrices of linear transformation for 200 bucks each while I really wanted to make mine open source and offer them for free. Anyway, back to our original topic, I think that using HDRTools to deal with UHD would require a not so hard modification to the code as you can see the command for the conversion between BT2020 SDR and BT709 SDR in the very first page of Jean Philippe's topic. As to HDR, I would be very reluctant about including it 'cause: - There's no way to know whether an HDR source is HDR except for the metadata that you would have to check from the indexer if the indexer does pass them, as Avisynth doesn't know anything about color curves. - even if you manage to get the information from the indexer 'cause it passes it, there's no way to be 100% sure that whoever encoded the file actually included the right metadata. I've seen far too many files wrongly flagged by either Studios or NLE, or cameras. - it's not just PQ and HLG, there are many other color curves like C-log, log-C, Slog1, Slog2, Slog3, F-log, D-log... - There isn't a clear mathematical connection between curves and the function that it's used to go from one to another and you will always have to make sure that the conversion is both mathematically correct and it looks good according to your taste which the user might not like (linear transformation, tonemapping algorithms like Hable, Möbius and Reinhard etc). For all these reasons, I would not include HDR conversion in the script. Trust me, it's a far too big subject that still makes us (broadcast encoder) think... Last edited by FranceBB; 10th August 2019 at 15:10. |
11th August 2019, 19:26 | #16 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
FranceBB,
Thanks for all the info! There's a couple of things that I don't quite understand though. The HDR Tools docs say: "If you want a true correct precise/perfect conversion, I would advise you to use a resampler and feed directly to YV24." Does "resampler" mean something other that the built in Avisynth Convert function? Also, there's two types of Rec.601. Color=3 (BT601_525) and Color=4 (BT601_625). My understanding is the PAL and NTSC colorimetry is the same in digital-land, so I don't understand the distinction here when everyone else only refers to a single flavour of Rec.601. I experimented a little and it's doing my head in. My Source is rec.709 and I'm downscaling it. Converting between rec.709 and rec.601 seems consistent for each method, aside from HDR Tools causing some banding above the guy's head on the right. You might have to run it full screen to see it. A ConvertYUVtoXYZ(Color=2).ConvertXYZtoYUV(Color=3, pColor=2, OutputMode=2) B Dither_convert_yuv_to_rgb(matrix="709", slice=false).Dither_convert_rgb_to_yuv(matrix="601", output="YV12") C ColorMatrix(mode="Rec.709->Rec.601", clamp=0) Keep in mind these are all being converted to RGB using rec.601 on playback, but I don't think that should prevent the result being the same each time. DitherTools and ColorMatrix agree on rec.709 <-> rec.2020 conversions but HDR Toiols doesn't. I copied the syntax from the help file. D ConvertYUVtoXYZ().ConvertXYZtoYUV(Color=1, pColor=2, OutputMode=2) E Dither_convert_yuv_to_rgb(matrix="709", slice=false).Dither_convert_rgb_to_yuv(matrix="2020", output="YV12") F ColorMatrix(mode="Rec.709->Rec.2020", clamp=0) DitherTools and ColorMatrix don't agree on rec.601 <-> rec.2020 conversions, and I still couldn't get anything sensible out of HDR Tools. G ConvertYUVtoXYZ(Color=1).ConvertXYZtoYUV(Color=3, pColor=1, OutputMode=2) H Dither_convert_yuv_to_rgb(matrix="2020", slice=false).Dither_convert_rgb_to_yuv(matrix="601", output="YV12") I ColorMatrix(mode="Rec.2020->Rec.601", clamp=0) All the above was done with classic Avisynth on XP, but a quick look indicated it's the same for Avisynth+. By the way, I may have missed it, but what does the XYZ in ConvertXYZtoYUV etc actually stand for? Cheers. Last edited by hello_hello; 11th August 2019 at 23:29. |
12th August 2019, 16:10 | #17 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
I was hoping I'd uploaded the last version, aside from sorting out the color correction, but a bug managed to slip past the keeper.
Fixed an incorrect output display aspect ratio calculation when NoResize=true and an input sample aspect ratio was specified. The script was still cropping correctly, but the output display aspect ratio calculation was wrong. New version in the opening post dated 2019-08-12. Last edited by hello_hello; 12th August 2019 at 16:15. |
13th August 2019, 17:49 | #18 | Link | ||
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,032
|
Quote:
This is because HDRTools allows you to do the conversion in either RGB or XYZ and then it allows you to convert back to YUV. In the screenshot you posted about BT2020 SDR, I would trust HDRTools as it's normal that colors look off if you view it with a player and a display that don't know anything about BT2020. For instance, this is sample in BT709 yv12 8bit planar: This is the conversion to BT2020 XYZ: And this is the final output of the BT2020 yv24: This is another example: BT709 yv12: BT2020 XYZ: BT2020 YUV: Of course if you playback the file on a good player, let's say MPV, and on a screen that's capable of representing the BT2020 SDR colorspace, then you're gonna see colors in the right way. Even if you use MPV on a BT709 only capable display, you're very likely gonna see the right colors as MPV is gonna convert it back to BT709 SDR by inverting the process and re-mapping the BT2020 into BT709. This is the ATP Masters 1000 Montreal, Canada, which is currently on air on Sky Sports: BT709 yv12: BT2020 XYZ: BT2020 yv24: This is simply done by using: Code:
ConvertYUVtoXYZ() ConvertXYZtoYUV(Color=1,pColor=2) Quote:
I gotta be fair, though, I've never used HDRTools for BT601 to BT2020 conversion, but only for BT709 SDR to BT2020 SDR and vice-versa and I gotta say that I'm pretty sure that it's doing a good job in that, but I have no idea about how it's handling BT601. I've also been using it to apply tone-mapping to my source to go from HDR PQ and HLG to BT709 and I tried the three tone-mapping algorithms and I found out that Reinhard was the best one (I made a long post about the comparison), anyway, once again, I've never used it for BT601 to BT2020 conversion, however these differences are unexpected. I mean, I expected similar results when going from a color matrix to another... There must be something wrong, but I don't know what. |
||
14th August 2019, 17:49 | #19 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,898
|
Thanks for the info again FranceBB!
So XYZ is an actual colorspace? I'll have to research it. I'll probably take some more screenshots and start a new thread rather than bog this one down with the color conversion stuff. I still think the result should be the same each time, even if the Avisynth output is always being converted to RGB by MPC-HC with rec.601 when viewing it. Even if it looks completely wrong, I'd have assumed the wrongness should be the same no matter which program is doing the conversion. Thanks again. |
14th August 2019, 18:44 | #20 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 3,032
|
Sure! Link
Too bad that it isn't actually officially supported by Avisynth+ 'cause it's used in Digital Cinema; for instance, I was trying to convert things to it a few days ago when I was trying to encode a DCP (Digital Cinema Package) encoded in Motion JPEG 2000 XYZ. Well, yes, that's what I expected as well, which is why I don't understand what's going on and why we're getting those very different results. Last edited by FranceBB; 14th August 2019 at 18:47. |
Thread Tools | Search this Thread |
Display Modes | |
|
|