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. |
25th July 2003, 12:38 | #1 | Link |
·
Join Date: Jan 2002
Posts: 1,729
|
Idea: YToRGB()
With all the mask stuff and colorspace conversions, I've come up with an idea. When I have a greyscale mask (or want to make one), I need to ConvertToRGB32() which is slow and lossy. Now my idea is to simply copy the Y channel into the R, G and B channels (not caring about green weight or clamping or all that stuff), so I have a greyscale RGB image. The logical road back of course is either RToY() (if it's greyscale all RGB channels will have the same value) or RGBToY(), which would just copy the average values of R, G and B into Y (more processor intensive than just copying R to Y). I don't care about color reproduction or anything like that, just internal processing so I can use the alpha channel until AVISynth has AYUV support (will it ever?). Maybe something like CopyToRGB(), which would just double the UV sizes and copy Y U and V into R G and B might also be interesting. A CopyToYV12() would be needed as well then of course .
Any thoughts? |
25th July 2003, 20:51 | #3 | Link | |
·
Join Date: Jan 2002
Posts: 1,729
|
Quote:
|
|
25th July 2003, 22:47 | #4 | Link |
Registered User
Join Date: Sep 2002
Location: France
Posts: 432
|
That's what I tried to propose to Avisynth community with Masktools, without success. I hadn't time to put up part of the newer versions (for my very own purpose) which consists in a YV12 layer function, but I'll try to take time to do it (considering mfToon is 2 times to 3 times faster without the supersampled sharpening by using it).
|
26th July 2003, 00:59 | #5 | Link |
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
@mf
YUVA is not a problem, I can do it easily for the 3.0 I can make a GrayScale colorspace too, it should come in handy to handle masks, no ? In fact anything you want is possible (motions vectors, different precision, planar RGB, interleaved YUV, YUV 4:4:4)... Just ask for what you want/need. |
26th July 2003, 05:18 | #7 | Link |
developer wannabe
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
|
Well if we're gonna create a new YUV colorspace, my vote goes to 4:4:4:4 YUV + alpha. Deciding whether to make it planar or packed is another matter -- with 4 "colors" maintaining a pointer to each uses up a lot of registers, but it also allows single-channel manipulations to be very quick. We could even have a hybrid, e.g. YUV in one plane and the alpha in another.
|
26th July 2003, 09:10 | #8 | Link |
Programmer
Join Date: Mar 2003
Location: Ekaterinburg, Russia
Posts: 112
|
Isn't that a lot easier to create "layer" plugin that will accept three clips instead of two with third clip used as alpha-channel?
something like "layer2(clip1, clip2, alphaclip)" This should work with any colorspace, no matter planar and interleaved - just go through the clip, multiply-add-divide or whatever three values, write result as output... why do you need alpha within clip itself? With alpha as separate clip you can also transform alpha-clip independently with existing filters, no need to add new ones or rewrite old ones... |
26th July 2003, 11:31 | #9 | Link |
·
Join Date: Jan 2002
Posts: 1,729
|
Whoah.. Feedback . I've read about some AYUV colorspace on MSDN, which apparently is a 4:4:4 colorspace with alpha. So that satisfies both of our needs. That's what I was talking about.
@Kurosu: I know mfToon can be faster, I absolutely hate the colorspace conversions I have to do in it. As I was making it, I was seeing it grow slower by the hour. If you're interested in making it any faster, I still have an idea lying around for a "piecemeal supersampler" which should speed up the sharpening by a fewfold (think tenfold or more). The only thing is, AVISynth doesn't support loops so I couldn't script it myself . |
26th July 2003, 19:40 | #11 | Link |
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
@Richard Berg
Maybe we can do both packed and planar, that's not a problem for me. Adding planar YUV 4:4:4 is just a 5 line modification (just change the reported plane size in the colorspace, videoframe use that info to init themselves), another plane is not much either. And for packed AYUV, it's just like RGB32. A few days ago, esby suggested to me to allow plugins to add colorspaces to the core. I replied I didn't see any real interest in that since it was really easy to add new ones, but maybe it was me being short-minded. Any comment ? |
26th July 2003, 20:36 | #12 | Link | |
·
Join Date: Jan 2002
Posts: 1,729
|
Quote:
|
|
27th July 2003, 22:54 | #13 | Link |
developer wannabe
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
|
Now that I've thought about it some, I'm starting to wonder why the alpha channel came about at all. It's convenient at the CPU level, where you can deal with [power of 2] channels at a time; and it's convenient at the GUI application level, where you construct a video out of several layers. In Avisynth, though, we're not afraid of creating dozens of intermediate clips when necessary (which is what GUI apps do too, behind the scenes), so it seems most logical to deal with alpha masks as clips in their own right. Let's consider WarpEnterprises' three Mask operations from the other thread:
#LumaToAlpha: as does Mask # should be written mask=CreateMask(clip) #AlphaToAlpha: copy Alpha # should be written mask2=mask #AlphaToLuma: the same as ShowAlpha # should be written clip=ShowMask(mask) #We'll need some helper functions to deal with "legacy" RGBA mask=CreateMask(clip, from_alpha=true) # requires RGB32 source clip=ShowMask(mask, write_alpha=true) #And lest we forget... clip=Layer(src1, src2, mask) # src1,src2 = any colorspace, mask = 8-bit All we need is a single-channel 8-bit colorspace, some easy filters, and you've created the ability to manipulate masks with the scripting language itself, not relying on C code that can parse out the alpha channels. And of course, it works with any colorspace, once we write the above filters. I haven't gone back and read your MaskTools thread, Kurosu, but does this sound similar? (This is just one use of this proposed colorspace; I'm sure there are others). BTW, I'm not completely happy with the above filter names, feel free to suggest alternatives. @Bidoche You can feel free to add any/all of this to the new framework; for now I'm interested in the 2.x codebase even if it's quick-n-dirty. |
27th July 2003, 23:31 | #14 | Link |
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
For coherence, the function names should be, supposed this 8 bit mask colospace is called GreyScale :
mask = clip.ConvertToGreyScale() #convert clip Y to a mask clip = mask.ConvertToXXX() #convert mask into Y mask = ExtractAlpha(clip) #where clip must be RGB32 And for implementation in 2.x, you can probably just make it as YV12 without UV. Last edited by Bidoche; 27th July 2003 at 23:35. |
28th July 2003, 15:22 | #15 | Link |
C64
Join Date: Apr 2002
Location: Austria
Posts: 830
|
1) Please NO MORE COLORSPACES
2) Why not only syntactically DEFINE the alpha channel as being the Y channel for YUY2 and YV12, the luma for RGB32 and RGB24? Then we don't need a new colorspace and the existing syntax can be expanded as written above. A clip then is a mask if it is USED as a mask. 3) Layer will have three clip arguments, so we could assume: 2 args -> old version, mask clip must be RGB32 with correct A 3 args -> new version, mask clip is separate clip, Y/lum is used 4) The same goes with the Mask or other functions (the number of args switches from old to new syntax) |
28th July 2003, 15:27 | #16 | Link |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
@WarpE: What you are saying is exactly what I'm hearing from many users.
1) No more colorspaces. Use RGB32 if extreme precision is important. 2) Exactly. 3-4) Exactly - I have written a preliminary design doc for "Overlay" (new name instead of "Layer2").
__________________
Regards, sh0dan // VoxPod |
28th July 2003, 18:20 | #17 | Link |
developer wannabe
Join Date: Nov 2001
Location: Brooklyn, NY
Posts: 1,211
|
I agree. YV12 should be the preferred format for storing pure masks since you don't have to unpack the Y/alpha information, but it should work with anything. We now have 4 ways of storing masks: as alpha in RGB32, or as luma in RGB/YUY2/YV12. Thus our suite of functions looks something like this (correct me if I misunderstand):
# Getting masks mask = ConvertToXXX(clip) # if mask = luma mask = Mask(clip) # if mask = alpha; need to modify Mask to support all colorspaces # Copying masks mask2 = mask # if mask = luma mask2 = CopyAlpha(mask) # if mask = alpha # Viewing masks return mask # if mask = luma in YUV return GreyScale(mask) # if mask = luma in RGB; could also use ConvertToYV12 + BlankClip + YToUV return GetAlpha(mask, out_colorspace="xxx") # if mask = alpha # Using masks Layer(clip1, clip2.CopyAlpha(mask), ...) # if mask = alpha Layer(clip1, clip2, mask.ConvertToYUY2 or YV12) # if mask = luma; should do conversion to YUV (if necessary) first so Layer code can be clean & fast |
28th July 2003, 18:44 | #18 | Link |
Avisynth 3.0 Developer
Join Date: Jan 2002
Location: France
Posts: 639
|
I think it still make more sense to have a new Colorspace to store those masks.
But for users to not be bothered by the detail of it, Layer and other mask functions could implicitly do the appropriate conversion. That way, for simple task you don't even have to know about it while retaining possibility to do complex ones with a compact format. |
28th July 2003, 20:15 | #19 | Link |
C64
Join Date: Apr 2002
Location: Austria
Posts: 830
|
@bidoche: can you sketch an easy example how to use built-in colorspace conversion in a plugin?
Some care is missing to assure the color is white when "showing" a YUV/YV12 mask. Maybe we should create a "complete" document (at the wiki?) where to discuss the whole set before starting to implement. These functions are very important but difficult to understand, too, so they should be as "beautiful" as possible (for the enduser) |
Thread Tools | Search this Thread |
Display Modes | |
|
|