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

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

 

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

Reply
 
Thread Tools Search this Thread Display Modes
Old 12th October 2020, 17:56   #21  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
I'm 99.9% sure that the so called studio range RGB is nothing but a mistake made by unprofessional engineers in the earlier days, because:
a) no television system transmits video in RGB space, so it makes no sense to preserve some "headroom" from the 8-bit range for some metadata that does not exist in the first place.
b) YUV<->RGB conversions are ALWAYS defined on full range RGB, this limited range RGB could not be properly displayed (without some non-standard scaling applied first), or properly converted to YUV by any standard. it's an abomination
feisty2 is offline   Reply With Quote
Old 12th October 2020, 18:14   #22  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by feisty2 View Post
I'm 99.9% sure that the so called studio range RGB is nothing but a mistake made by unprofessional engineers in the earlier days, because:
a) no television system transmits video in RGB space, so it makes no sense to preserve some "headroom" from the 8-bit range for some metadata that does not exist in the first place.
b) YUV<->RGB conversions are ALWAYS defined on full range RGB, this limited range RGB could not be properly displayed (without some non-standard scaling applied first), or properly converted to YUV by any standard. it's an abomination
Maybe - but these standards exist, you should be aware of them, and we have to live with it because it's still used today. A lot of it is historical, where they had to deal with broadcast compromises with bandwidth and equipment issues

For broadcast, the transmission is not in YUV, but the display is not in YUV either. A normal HDTV in your living room uses limited range RGB by default. A comptuer display/montior uses sRGB, no surprise, so computer range YUV<=>RGB equations are typically used in the latter. But not in the former

YUV<=> RGB conversions have a "full" and "limited" parameter, correct ?

When you use "full" range equations, that produces limited range RGB - that is (almost) studio range RGB (there is a slight offset to actual "studio RGB" , they are not exactly equivalent), but range is the same.

Pros/cons - there is no range contrast expansion in the full range equations - it's 1:1 mapping 0-255 to 0-255. So in some ways it's better, in others it's worse. (Any range scaling is technically worse)

This is how broadcast checks are done for r103 ; they specify using full range equations for the RGB check (where <1% illegal is ok) , and that is "limited range RGB"

Last edited by poisondeathray; 12th October 2020 at 18:17.
poisondeathray is offline   Reply With Quote
Old 12th October 2020, 18:43   #23  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by poisondeathray View Post

For broadcast, the transmission is not in YUV, but the display is not in YUV either.
I'm not sure what you meant by "transmissions not in YUV", display is always in RGB, it's the only colorspace (or should I say type of colorspaces) that directly corresponds to how display devices work in the physical world

Quote:
YUV<=> RGB conversions have a "full" and "limited" parameter, correct ?
there is no mentioning of limited range RGB anywhere in Rec.601. In fact, the quantization equations on page 4 already suggest that RGB must be full range, so E'y, E'cb and E'cr would also be range full as appeared in the equations. If certain programs support conversions between limited range RGB and YUV, it's a non-standard support for an illegal format.

Quote:
A normal HDTV in your living room uses limited range RGB by default.
I don't know about this and I don't care, no one of my generation watches TV anyways
feisty2 is offline   Reply With Quote
Old 12th October 2020, 18:59   #24  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by feisty2 View Post
I'm not sure what you meant by "transmissions not in YUV", display is always in RGB, it's the only colorspace (or should I say type of colorspaces) that directly corresponds how display devices work in the physical world
Sorry typo

That's correct. Transmission in YUV, display in RGB. That's the reason for the limited range RGB check

Your TV (if you had one...) uses limited range RGB.

Your graphics card should have a toggle for limited and full range RGB output - why ? Because a TV uses limited range RGB


Quote:
there is no mentioning of limited range RGB anywhere in Rec.601. In fact, the quantization equations on page 4 already suggest that RGB must be full range, so E'y, E'cb and E'cr would also be range full as appeared in the equations. If certain programs support conversions between limited range RGB and YUV, it's a non-standard support for an illegal format.
r103 specifies limits for Y,R,G,B as 16-235

The full range equations are used for the YUV=>RGB portion of the check



Quote:
Originally Posted by feisty2 View Post

I don't know about this and I don't care, no one of my generation watches TV anyways
Sure, that's why you weren't aware - but some people still do

That's what this thread is supposed to be about - "broadcast safe", at least what the 1st post mentioned
poisondeathray is offline   Reply With Quote
Old 12th October 2020, 19:20   #25  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
also regarding fp32 YCbCr, it is obvious that this format corresponds directly to E'y, E'cb and E'cr defined on page 3 of Rec601, so the range should be [0, 1] and [-0.5, 0.5] accordingly. There is no definition of limited range E'y, E'cb and E'cr.

Last edited by feisty2; 12th October 2020 at 19:29.
feisty2 is offline   Reply With Quote
Old 12th October 2020, 20:10   #26  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by feisty2 View Post
also regarding fp32 YCbCr, it is obvious that this format corresponds directly to E'y, E'cb and E'cr defined on page 3 of Rec601, so the range should be [0, 1] and [-0.5, 0.5] accordingly. There is no definition of limited range E'y, E'cb and E'cr.
f2 - maybe some confusion over terminology over what "range" refers to. It does not refer to absolute range. It refers to black and white point

1) "Limited range RGB" means 16-235 black to white (in 8bit). It does not mean that you cannot have RGB code value of 1. It describes the black to white range only . When you apply full range equations, with broadcast range input (legal range) YUV video Y 16-235 - You get limited range RGB 16-235. If you had a Y'CbCr overshoot of 236,128,128 the resulting RGB value would be 236,236,236 . It's still called "limited range RGB", because the black to white point is RGB 16-235. The 236 value doesn't get clipped

A large part of why we have "legal range video" in the first place is for historical broadcast reasons - 0,255 are reserved for sync , and the equipment/ bandwidth issues mentioned earlier



2)
"Full range RGB" means 0-255 black to white. This is what you're used to. Computer RGB. Y 16-235 => RGB 0-255. This is limited range equation application . Range expansion


But of you started with full range video (Y 0-255) , you would get clipping of Y <16, Y>235 values when limited range equation to RGB is applied. In this case, that same YCbCr 236,128,128 value does get clipped in the RGB conversion



If you look at BT.709 If you look under 4.6 - R,G,B,Y (not just Y) black level and nominal peak are listed as 16, 235 (and 64, 940 for 10bit) . Both full and limited range equations are valid for BT.709, but only the full range equation results in RGB 16-235 from legal range Y input . That's the default BT709 specification. Not surprisingly, r103 guidelines mirror that range for R,G,B,Y

https://i.postimg.cc/2jtZk1Nc/BT709-4-6.png



Hypothetically, you had unlimited bandwidth and if fp32 was a transmission format, and you still had restrictions (pretty stupid if you had unlimited bandwidth, that's the main reason for the existence of full vs. limited ranges in the first place. We'd just use RGB for everything) , then the concept of full and limited Y range would still be valid . But as mentioned earlier limiting in fp32 never exists in a real scenario. It's always done at the end

Last edited by poisondeathray; 12th October 2020 at 20:36.
poisondeathray is offline   Reply With Quote
Old 12th October 2020, 20:31   #27  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
I know exactly what range means. if you're talking about 8-bit limited range, any behavior on (236,128,128) is undefined because it is not in the (definition) domain.
Quote:
If you had a Y'CbCr overshoot of 236,128,128 the resulting RGB value would be 236,236,236 . It's still called "limited range RGB", because the black to white point is RGB 16-235. The 236 value doesn't get clipped
this is called analytic continuation, basically you have extended the domain of the original definition, and whatever happens in the extended domain has nothing to do with the original definition. do you know that the sum of all natural numbers converges to -1/12?
feisty2 is offline   Reply With Quote
Old 12th October 2020, 20:47   #28  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by feisty2 View Post
I know exactly what range means. if you're talking about 8-bit limited range, any behavior on (236,128,128) is undefined because it is not in the (definition) domain.

this is called analytic continuation, basically you have extended the domain of the original definition, and whatever happens in the extended domain has nothing to do with the original definition. do you know that the sum of all natural numbers converges to -1/12?

You can call it undefined, but it happens, and those code values can exist.

Do you see why limited range RGB exists, and why limiting functions are sometimes used ? It's to conform to 709 specs , and r103

But the problem is many of those "illegal" broadcast values are illegal combinations of Y,Cb,Cr that result in negative or >1 values in RGB in the [0,1] definition (they lie outside the RGB color cube) . They lie in the middle of the range and cannot be addressed by simple min/max compression or clipping adjustments

Simple manipluations like resizing, chroma subsampling can result in those illegal values.
poisondeathray is offline   Reply With Quote
Old 12th October 2020, 20:49   #29  |  Link
feisty2
I'm Siri
 
feisty2's Avatar
 
Join Date: Oct 2012
Location: void
Posts: 2,633
Quote:
Originally Posted by poisondeathray View Post
You can call it undefined, but it happens, and those code values can exist.
you know I had a hard time convincing my 10-year-old cousin that 1+2+3+... = -1/12
feisty2 is offline   Reply With Quote
Old 12th October 2020, 21:13   #30  |  Link
Cary Knoop
Cary Knoop
 
Cary Knoop's Avatar
 
Join Date: Feb 2017
Location: Newark CA, USA
Posts: 397
Quote:
Originally Posted by feisty2 View Post
this is called analytic continuation, basically you have extended the domain of the original definition, and whatever happens in the extended domain has nothing to do with the original definition.
A good example of this is when you convert a linear video to log and there are negative code values (due to the noise floor being set to zero).
Without extending the domain to the (principal) complex plane you will get errors that can no longer be corrected by subsequent operations.
Cary Knoop is offline   Reply With Quote
Old 16th February 2021, 08:08   #31  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
"the idea is to automatize clipping to get a broadcast safe output in Limited TV Range (0.0-0.7mV).

8bit sources will be limited to 16 - 235 luma and 16 - 240 chroma"

That is not great idea and looks like misunderstanding the Rec.601. Rec.601 warning about possible walking restored RGB 'out of gamut' if even YUV is in valid (1..254) range. So Rec.601 recommends to check YUV (actually Y Cr Cb) if additional limits required to keep RGB-restored 'gamut in range'. And to distort image data as low as possible if actual limiting will be applied it recommends to distort saturation in the first place.

So limiting may be applied after analysing of YUV triad data (being checked in RGB-space for gamut limits) - not by simple checking every luma and chroma data channel separately. Because simple checking and applying to each channel separately it introduce many more unnecessary distortions. And clipping to nominal YUV levels may be even not guaranteed results to be actually RGB-gamut limited.

So the actual limiter may be best to work internally in HSB color system to have ability for Saturation degrading in the first.

Also all these additional limits requirements may be just 'shadows of the past' where real data receivers where very cheap and poor 8bit integer processors and can not handle 'out of 601 gamut' RGB properly.

Quote:
Originally Posted by feisty2 View Post
there's no limited range RGB.
Limited range RGB is exact 4:4:4 member of Rec.601.

It looks like misunderstanding of system RGB data encoding and physical display RGB data encoding.

System RGB must be always in limited data range (in integer encoding) to handle over/under shoots (negative under the 'black'). It is valid in numbers (math), not physics of positive-only brightness.

Physical display RGB is the end of system and for data_to_brightness operation conversion negative under_the_black levels are not valid and consumes some useful data range of low-bit encodings. So display YUV to RGB conversion is usually done to 'full' range with zero black. Also it is correctly done after scaling data to actual display size. It is final system conversion and it is not required to be 'math safe' for processing signals with limited spectrum. So only at the End of System we have right to cut-out under_the_black undershoots in RGB without degrading. Also display RGB with 'full range' is no more valid for correct signal data processing in between samples in space.

And system RGB data is just one form of describing data of limited spectrum and may be any times later scaled and other processed so it must be in math safe bipolar range against 'black' for keeping undershoots under black and also must have some headroom above nominal and better even above highest objects levels for keeping overshoots.

Same as the processing of edges of actual physical display have special workarounds against Gibbs ringing because typical moving image data is usually not conditioned against Gibbs ringing at the edges nowdays. It is applied to thread https://forum.doom9.org/showthread.php?t=182276 where it is recommended to use Avisynth AddBorders() to expand 4:3 to 16:9. Because special display workarounds applied only to actual image data buffer edges - adding 'unconditioned' borders with AddBorders() will cause Gibbs-ringing at the transition to added borders if data levels of old frame edge and new border do not match. For 'broadcast safe' levels transition operation the Avisynth's filter AddBorders() need to be fixed too. For example based on ITU-R-BT.1212 idea of using Blackman impulse response for simple conditioning for channel or any other conditioning for channel with Gibbs-distortion depressed. But still no hero to do this and core developers are busy with other things. I read some user-defined scripts exist for workaround.

>there is no mentioning of limited range RGB anywhere in Rec.601.

https://www.itu.int/dms_pubrec/itu-r...3-I!!PDF-E.pdf
4:4:4 member of system - TABLE 4:

8) Correspondence between
video signal levels and
quantization level for each
sample:
– scale - 0.00d to 255.75d

– R, G, B or luminance
signal(1) - 220 (8-bit) or 877 (10-bit) quantization levels with the black level
corresponding to level 16.00d and the peak white level corresponding
to level 235.00d. The signal level may occasionally excurse beyond
level 235.00d or below level 16.00d

>Without extending the domain to the (principal) complex plane

Negative is simple real number. Not yet higher magic like complex numbers. Any video signal code value below 16 limited is actually 'negative' without any processing difficulties. In fp32 with correctly designed filters as was mentioned here there must be no difference in processing if data have some 'constant level shift'. And this shift may move all or part of data range to negative numbers too.

Last edited by DTL; 16th February 2021 at 09:48.
DTL is offline   Reply With Quote
Old 16th February 2021, 10:41   #32  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Some example what is going wrong when hardlimiting undershoots to 16 applied:

Giving some 'sharpness corrected' 1 video detail with local (blacker than black) undershoot samples sequence (16), 16, 7, 3, 120, 235, 3, 7, 16, (16):

It have good enough depressed Gibbs ringing and T-size in physical display RGB positive-only brightness about 3.1T at 0.1 level above physical zero brightness.

After hard-limiting under16 samples to 16:

It have increased 0.1-level T-size to 3.2T (less sharp) and some far Gibbs ringing brought in (if using signal restoration DAC with large enough kernel taps value) near black level having positive (visible) values.

Last edited by DTL; 16th February 2021 at 10:56.
DTL is offline   Reply With Quote
Old 18th February 2021, 02:32   #33  |  Link
Emulgator
Big Bit Savings Now !
 
Emulgator's Avatar
 
Join Date: Feb 2007
Location: close to the wall
Posts: 1,531
Applause, DTL.
__________________
"To bypass shortcuts and find suffering...is called QUALity" (Die toten Augen von Friedrichshain)
"Data reduction ? Yep, Sir. We're that issue working on. Synce invntoin uf lingöage..."
Emulgator is offline   Reply With Quote
Old 19th February 2021, 05:02   #34  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
http://downloads.bbc.co.uk/rd/pubs/reports/1987-22.pdf - the publication of Devereux, 1987 mentioned at ITU-Rep BT.629-4-1990 page 7 about possible implementation of YUV limiter keeping most of hue and luminance unchanged. I think in 2021 it may be easy enough designed as good speed Avisynth plugin but as a script it is hard and slow.

Also I see it (may not) do not try to keep the spatial spectrum of non-linearly limited YUV to be Nyquist-limited and anti-Gibbs conditioned. So the new implementation in 2021 and later may be even a bit better.
DTL is offline   Reply With Quote
Old 23rd February 2021, 16:02   #35  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
Quote:
Originally Posted by DTL View Post
So Rec.601 recommends to check YUV (actually Y Cr Cb) if additional limits required to keep RGB-restored 'gamut in range'. And to distort image data as low as possible if actual limiting will be applied it recommends to distort saturation in the first place.

So limiting may be applied after analysing of YUV triad data (being checked in RGB-space for gamut limits) - not by simple checking every luma and chroma data channel separately. And clipping to nominal YUV levels may be even not guaranteed results to be actually RGB-gamut limited.

So the actual limiter may be best to work internally in HSB color system to have ability for Saturation degrading in the first.
You're actually right, in fact although clipping the out of range values makes luma legal, it's not the same for chroma.
For instance, it's entirely possible to have 16-240 chroma, which is made of legal values, but it's represented as out of range in the scope.
The reason for this is relative to the intensity and not the code values in which the signal spans, in fact if you take this 12bit input: https://i.imgur.com/lhdv3Ag.png we can see that luma is slightly lower than 256, sitting at around 210, so, it's slightly out of range, and chroma slightly above 3935, so it's out of range as it's supposed to be 3840, however, if I limit the values to Limiter(min_luma=256, max_luma=3760, min_chroma=256, max_chroma=3840) the luma is gonna be in range but the chroma is still gonna be out of range, especially in the green component and it takes a tweak(sat=0.90) to bring it in range. https://i.imgur.com/pc3Nu0G.png The fact is that, technically speaking, there's nothing wrong with the current Avisynth implementation of clipping, I mean, Limiter does what is supposed to do, namely limit the range to the correct values (in this case Limited TV Range), however, that is not enough for chroma as it not only has to be in that range in terms of values in which the signal is spanning, but it also has to be inside the 75% relative intensity as per standard, so it's still out of range despite being limited to span the correct values. I agree with you that a much better implementation is needed for chroma which should also be able to de-saturate the input signal by a certain percentage according to the specs instead of just getting rid of the illegal values and hope for the best.

Quote:
Originally Posted by DTL View Post
Also all these additional limits requirements may be just 'shadows of the past' where real data receivers where very cheap and poor 8bit integer processors and can not handle 'out of 601 gamut' RGB properly.
Sadly no, they're not from the past as they affect very much what we perceive today. Although it's true that the effect of airing out of range stuff is way less catastrophic today than how it was years ago with CRT TV, it's also true that the TV is supposed to convert the input signal to RGB and most of them blindly trust the flag, which means that if it's flagged as Limited, it will convert to RGB (which is always full, as feisty said before and we agreed to) assuming that the black is 16 and the peak white is 235. What this means is that nothing below 16 or above 235 is displayed. What I've seen most of the times, is cameras being out of range, not in the sense of being Full Range, no no, their black was starting correctly, at 16, but their peak white exceeds 235. This is bad as anything above 235 will NOT be displayed by the TV which performs the conversion and a soft highlights rollback is therefore needed. Besides, some watchdogs are more permissive, some other are less permissive and may be prone to make a complaint to broadcasters airing out of range stuff, depending on the nation you're airing in. As to chroma, the same thing applies, however from my experience watchdogs tend to be far more permissive on chroma than on luma (don't ask me why), but it's very much an issue today as it was in the past and it's something that we can't ignore and that we MUST get right.

Quote:
Originally Posted by DTL View Post
Physical display RGB is the end of system and for data_to_brightness operation conversion negative under_the_black levels are not valid and consumes some useful data range of low-bit encodings. So display YUV to RGB conversion is usually done to 'full' range with zero black.
Precisely, from Limited TV Range YUV the TV converts to Full Range RGB, but if there's something below 16 and above 235 for luma and 240 for chroma, the TV will almost certainly not display it as it would return a math error. As you said, if 16 is mapped to 0, 15 can't be mapped to -1 which is not valid.

Quote:
Originally Posted by DTL View Post
And system RGB data is just one form of describing data of limited spectrum and may be any times later scaled and other processed so it must be in math safe bipolar range against 'black' for keeping undershoots under black and also must have some headroom above nominal and better even above highest objects levels for keeping overshoots.
Correct.

Quote:
Originally Posted by DTL View Post
For 'broadcast safe' levels transition operation the Avisynth's filter AddBorders() need to be fixed too. For example based on ITU-R-BT.1212 idea of using Blackman impulse response for simple conditioning for channel or any other conditioning for channel with Gibbs-distortion depressed. But still no hero to do this and core developers are busy with other things. I read some user-defined scripts exist for workaround.
I didn't know about AddBorders(), but I too believe that we should have those broadcast safe values respected right in the core, probably with a better implementation of Limiter, but for now I'm just thinking about a way to implement it as a plugin. It shouldn't be too hard to do, after all we "only" need to de-saturate accordingly, but I have no idea of how much I have to desaturate according to the detected value, nor how I should detect that value. I'm pretty sure that there are some ways to detect it, just like what Histogram("color2") uses to display these things, but I have to think about it and write some logic around it.


Quote:
Originally Posted by Emulgator View Post
Applause, DTL.
Yep. I always said that Russian guys are good at this and he's no exception! Well done for pointing it out, DTL

Last edited by FranceBB; 23rd February 2021 at 16:06.
FranceBB is offline   Reply With Quote
Old 23rd February 2021, 18:38   #36  |  Link
DTL
Registered User
 
Join Date: Jul 2018
Posts: 1,041
Quote:
Originally Posted by FranceBB View Post
this means is that nothing below 16 or above 235 is displayed.
I do not know where do you take about limiting max brightness display value to 235 Y code value. My poor-people 4k TV set from about 2015 branded 'philips' do display Y code levels up to 254. Do not as good as I think math with gamma 2.4 says like 20% brighter in compare with 235 code level, but about 16% brighter. May be because of poor driving of LCD panel at extreme code values.



I understand there may be at the consumer's side badly designed displays clipping brightness values to 235 or even upscaling 234+ code values to 236+ and with truncating high bits without saturation to 8bit ends up with 0..1+ code values and display black dots instead of 'superwhite'. But it is still badly designed examples of digital display devices. For CRT with no error any bit data processing inside tube it is also no problem do display some over-normal brightness values. As I remember at time of analog TV the 'superbright' still non-clipped value was about 130%, not 109% as currently with digital coding.
DTL is offline   Reply With Quote
Old 23rd February 2021, 18:50   #37  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
I mean they physically represent the whole range, even if they're TVs, if the stream is flagged as full but they won't if it's flagged as limited and since everything is flagged as limited in broadcast, you see my point...
As to full range streams properly flagged as full range, it's not mandatory for manufacturers to be able to display those values so it's honestly a lottery as the TV may or may not support it. In your case, your TV correctly decodes Full Range YUV to Full Range RGB, so you're lucky, but that doesn't solve the problem with streams flagged as limited but with luma out of range I'm afraid...
FranceBB is offline   Reply With Quote
Old 24th February 2021, 10:34   #38  |  Link
Sharc
Registered User
 
Join Date: May 2006
Posts: 3,997
You may find this interesting. They introduce "preferred min./max. values".
https://tech.ebu.ch/docs/r/r103.pdf

Last edited by Sharc; 24th February 2021 at 10:39.
Sharc is offline   Reply With Quote
Old 1st March 2021, 12:51   #39  |  Link
vcmohan
Registered User
 
Join Date: Jul 2003
Location: India
Posts: 890
I am looking for a color conversion code using template for all uint and float formats. Something like
Code:
template <typename T>
void RGB_YUV( T*YUV, T* RGB)
and
template <typename T>
void YUV_RGB(T* RGB, T* YUV)
can you guide me? I tried to code but became messy and needed more inputs like nbits, min, max, int/float
__________________
mohan
my plugins are now hosted here
vcmohan is offline   Reply With Quote
Old 2nd March 2021, 11:31   #40  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 2,309
Quote:
Originally Posted by vcmohan View Post
I am looking for a color conversion code using template for all uint and float formats. Something like
Code:
template <typename T>
void RGB_YUV( T*YUV, T* RGB)
and
template <typename T>
void YUV_RGB(T* RGB, T* YUV)
can you guide me? I tried to code but became messy and needed more inputs like nbits, min, max, int/float
It will be complex, plus you'll need the YUV-RGB conversion matrix as well (e.g. bt.601, bt.709 etc..)
edit: one can dig into avsresize which is not only a resizer but a most powerful format and color space converter as well.
It's parameter set is quite complex. http://avisynth.nl/index.php/Avsresize

Last edited by pinterf; 2nd March 2021 at 11:37.
pinterf is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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

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

Forum Jump


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


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