Transforms Pack v1.0 RC18

[Dogway]

Why do you need visual difference to be accurate? I don't want a half baked color space function, that's why I made this and also as a learning reference.

Some other additions are ACES spaces, custom chroma resamplers for the YUV<->RGB conversion, or PC/TV range input/output for this conversion.

I will release v1.0 final for SDR, and target v2.0 for HDR (uncharted territory for me).

[StvG]

I appreciate your work and the time you spared but saying "half baked color space function" about zimg is not serious and someone reading this would get completely wrong impression (about zimg).

That precision you're talking about it would matter when you can get the final result in float (still questionable - no visible difference) but in the end you have to go lower integer and to use some rounding.

Also... you have intermediate result with source bit depth (the output from YCbCrToRGB and the intput in RGBToYCbCr) that wipes the precision you're trying to achieve if the input clip is not in float (input bit depth -> float -> input_depth -> float -> input_depth):

YCbCrToRGB(YCbCrToRGB_mat("601")).RGBToYCbCr(RGBToYCbCr_mat("709"))

avsresize equivalent would be (assuming 8-bit input) (8-bit -> float -> 8-bit -> float -> 8-bit);

z_ConvertFormat(pixel_type="rgbp", colorspace_op="601:709:709=>rgb:709:709", resample_filter="spline36")
z_ConvertFormat(pixel_type="yv12", colorspace_op="rgb:709:709=>709:709:709", resample_filter="spline36")

But here you have intermediate result in float and this leads to final result with higher precision than above examples (input bit depth -> float -> input_depth):

z_ConvertFormat(colorspace_op="601:709:709:l=>709:709:709:l",resample_filter="spline36",  dither_type="none")

For ColorSpace("601","709","spline36","spline36",true,false) again the intermediate result is in input_depth.

[Dogway]

Sorry if it sounded like that, I wasn't talking about any particular plugin but my own code. Why would I limit myself to what others have done? If I'm not bringing anything new to the table there's no meaning in the project. As I noted above, new color spaces, new algos, range conversion, and so on. I have used zimg library before through ImageMagick and it's a great tool, I simply don't like how it has been presented as avs+ plugin.

About the precision:
You can use ConvertBits() to use any precision on your chain, I find this a feature and not a detriment, you can see how precision makes a difference for color space conversions.
RGB will turn into RGBP16 for ConvertBits(16), which is 16-bit integer, "is it the same as float?" NO, but that's the point of the project, it scales with improvements on the avs+ side (looking forward to 16 half float). Meanwhile I'm currently working on 32-bit float support.

I'm in the process of updating a bunch of scripts to replace masktools2 to Expr() (check my Github), and the same principle applies, any performance improvement over Expr() will automatically translate into the scripts running faster. Currently the only hindrance is convolutions (mt_edge, mt_xxpand, etc), there aren't fast alternatives for avs+ like in VS and thus it presents the bottleneck of most scripts.

[kedautinh12]

RC6: https://github.com/Dogway/Avisynth-S....v1.0.RC1.avsi

[Dogway]

I released RC9, this is a good candidate for 1.0 final so some feedback would be good, specially on argument coherency and chroma placement accuracy.
Recently added chroma placement option from/to RGB, linear_in/out options, and format out conversion.

The goal here is not speed as I can't compete with highly accelerated plugins but accuracy and reliance. The script is very straight forward, easy to use and easy to understand so it can be easily debugged. Also I want to make it a reference for accuracy, where all others compare against, for that I derived all the constants I could (except for RGB<->XYZ transforms), namely chroma placement shifts, kr, kb, kg coefficients, Pb, Pr, Nb and Nr coefficients, offset values for piecewise gamma function, etc.

Originally Posted by StvG

Shouldn't ColorSpace("601","709","spline36","spline36",true,false) be the same as YCbCrToRGB(YCbCrToRGB_mat("601")).RGBToYCbCr(RGBToYCbCr_mat("709")) ?

Now back to the hot topic, is RGB a color space? as I said, I don't think so. I call RGB a color format, although in fact it is a color "model", just like YUV. This is independent from color spaces, if you think about it all color space conversions happen through RGB (and XYZ) space, if you work with Nuke, Resolve, Photoshop, Blender... they are RGB based and color management aware at the same time.

Following some quotes I found while researching for a side project.

tftcentral:

Nearly every capture - or display device nowadays uses an RGB color model to describe the color for every pixel. (...). This data has a little meaning though without a color space assigned to it. A pixel with 8-bit color depth per channel with RGB value [255; 0; 0] would obviously be red. But without a color space assigned there would be no way to tell what the chromaticity for red should be.

Wikipedia: RGB:

The RGB color model itself does not define what is meant by red, green, and blue colorimetrically, and so the results of mixing them are not specified as absolute, but relative to the primary colors. When the exact chromaticities of the red, green, and blue primaries are defined, the color model then becomes an absolute color space, such as sRGB or Adobe RGB; see RGB color space for more details.

[Arx1meD]

Dogway, earlier versions of the script had a WhitePoint function. I haven’t found information about this feature. Is it correcting the white balance? Can you explain what she does?

[Dogway]

Yes, I moved it to Grade Pack since it is a less technical and more a look function. In Transforms Pack there's only c_adaptation() which does chromatic adaptation of known color spaces, defined by the "source" and "target" arguments.

WhitePoint() doesn't correct anything per se, it is similar to the Tweak() internal function but instead of the HUE wheel it modifies color based on the daylight correlated color temperature (ie. cooler or warmer white point) as a mathematically accurate function, unlike most other solutions I have seen.

I also want to add that current RC17 of Transforms Pack is very outdated and not representative of final version. I'm finishing development of v1.0, it's actually finished but in debug stage so I hope to release it in less than a week time.

[Arx1meD]

Dogway, thanks.
Can your Transforms Pack be used to change the white balance?

[Dogway]

Use WhitePoint() for that in Grade Pack. It requires Transforms Pack though for the matrix functions and it's developed a bit ahead so you need to remove all the ", fulls=fs)" references.

EDIT: Topic moved to Filters Packs thread.