Compression Setting...
 
Notifications
Clear all

Compression Settings... "Accepted colorspace:"  

Page 1 / 2
  RSS

Cat
 Cat
(@cat)
Active Member
Joined: 4 years ago
Posts: 6
17/12/2016 1:42 am  

 So if you go to "Compression settings..." -> "Input and format settings" -> "Accepted colorspace:" you usually have 2+ options. Let's take the settings for "MagicYUV - RGB" for example, the two options you have are either "All supported" or "RGB". I'd like to know what the difference between the two are. Thanks for reading and sorry if it's a dumb question.


Quote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 4 years ago
Posts: 207
17/12/2016 2:12 am  

Thanks for asking, that's a good question.

Well, in that particular case, there is no difference, as RGB only has one "supported" category for accepted input colorspace (RGB), so there it is equivalent. But good point, maybe in those cases where there is only one option, it should be more clear that All supported is equivalent to the single option.

In case of the "MagicYUV - YUV 4:2:0" variant however, there are 4 options (+ "All suported"). Here if you select for example "YUV 4:2:2 - (YUY2,YUYV...)" then the codec will only accept YUV 4:2:2 category pixel formats as input (like YUY2, YUYV, etc.), and reject all others like RGB, YV24 (which is YUV 4:4:4), YV12 (which is YUV 4:2:0), etc.

The reason why YUV 4:2:0 has more options there is that the codec only does down-sampling or down-conversion during encoding. So to encode RGB, you only have one option, the "highest level" color space: RGB. But for YUV 4:2:0, you have all categories as options which are "higher" than that, as the codec can automatically do conversion from higher to lower color space during encoding (like encode YUY2 input as YUV 4:2:0 doing automatic conversion).

The order of color spaces are: RGB > YUV 4:4:4 > YUV 4:2:2 > YUV 4:2:0 > YUV 4:0:0 (greyscale).

Does that roughly answer your question?

P.S.: About dumb questions, a good friend of mine once said: "Those who ask are dumb, but those don't: remain dumb". Since then I try ask as many questions as I can 🙂


ReplyQuote
Cat
 Cat
(@cat)
Active Member
Joined: 4 years ago
Posts: 6
17/12/2016 2:48 am  

Yea, that's great. Thanks for the answer!


ReplyQuote
Richard Bushell
(@richard-bushell)
Active Member
Joined: 4 years ago
Posts: 11
19/12/2016 5:11 pm  

Just for absolute clarity, should that have read:

But for YUV 4:2:0, you have all categories as options which are "higher than or equal to" that.

Rather than just "higher than"?

Just want to be sure I'm understanding it correctly...


ReplyQuote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 4 years ago
Posts: 207
19/12/2016 7:40 pm  

Yes, "higher than or equal to" is what I should have written, thanks for the correction!


ReplyQuote
Richard Bushell
(@richard-bushell)
Active Member
Joined: 4 years ago
Posts: 11
19/12/2016 7:48 pm  

Thanks, that's now entirely clear.

I assume the output file is only LOSSLESS (against the original) if the INPUT COLORSPACE and OUTPUT COLORSPACE are EXACTLY EQUAL?

If the INPUT COLORSPACE is HIGHER than the OUPUT COLORSPACE I assume you are losing quality with the conversion? e.g. a 4:2:2 input would lose quality with a 4:2:0 output.

And clearly there is no point offering a LOWER LEVEL INPUT than the OUTPUT LEVEL as you'd end up with identical quality but in a larger filesize than necessary

Apologies for more dumb questions, just want to get this clear in my own understanding.


ReplyQuote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 4 years ago
Posts: 207
19/12/2016 8:04 pm  

Yep, that is all correct 🙂 - if by INPUT you actually mean "raw/uncompressed input" and by OUTPUT you mean "compressed output", so talking about the compression side.


ReplyQuote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 4 years ago
Posts: 207
19/12/2016 8:06 pm  

As an added note, if you want to see how apps are actually communicating with the codec, so to see what kind of conversions are actually happening, turn on logging in the global MagicYUV VFW config dialog, and look at the logfiles. It sometimes surprises me too what some apps are doing.


ReplyQuote
Richard Bushell
(@richard-bushell)
Active Member
Joined: 4 years ago
Posts: 11
19/12/2016 8:30 pm  

OK, thanks, I've not got access to my Editing PC at the moment to test the LOG option, but that'll be interesting.

Just a quick suggestion... It would be great to put the best information from this forum on a Q&A page (or Facts page) on the MagicYUV website, or else use a STICKY ANSWERS section on this Forum with answers and information that only you can edit. Those answers can be regularly tweaked or improved for further clarification if required, and will answer the most often asked questions. It'll save you an enormous amount of time and effort in re-answering many posts over time, and we'll all have access to the very clearest information with the "perfect" answer to each question.


ReplyQuote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 4 years ago
Posts: 207
19/12/2016 8:38 pm  

Yes, that would be the plan! I just don't know what would be the best place for it, the site or here...


ReplyQuote
Richard Bushell
(@richard-bushell)
Active Member
Joined: 4 years ago
Posts: 11
19/12/2016 9:03 pm  

Whichever I suppose, just include a permanent link from one to the other. That'll be a great resource, what's obvious to you with many years of learning is often unclear or on the fringes of our (limited) understanding of color spaces and pixel formats. Thanks again.

Just one further clarification of your last answer, you mentioned raw/uncompressed input and compressed output. Just to be clear, our workflow from a NLE might be to round-robin a specific clip into another application. We use Vegas Pro, which I understand uses an Internal sRGB Color Space.

So our workflow would therefore be:

LONG-GOP INTER-FRAME MP4 FILE (8-bit 4:2:0 YUV Color Space) off our Video Camera, into...

Vegas Pro NLE (must internally convert that YUV input to it's INTERNAL sRGB Colour Space (tiny rounding errors I presume), out to...

MagicYUV AVU file for external use - I assume we should only use the RGB(24) output setting if we want Lossless file to take into another application.

Is that right?

So, when you say: raw/uncompressed input that would come from Vegas Internal sRGB,

and compressed output: that would be the Mathematically Compressed (Lossless) MagicYUV output file.

Again, is that right?


ReplyQuote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 4 years ago
Posts: 207
19/12/2016 9:41 pm  

OK, good remarks, thanks!

About MP4 -> MagicYUV: ideally, you would need a program which encodes to MagicYUV without going through sRGB, ie. directly in YUV 4:2:0, such as VirtualDub (though even there you must be careful and set up decoded format explicitly). This is needed if you want to transcode just the source.

LONG-GOP INTER-FRAME MP4 FILE (8-bit 4:2:0 YUV Color Space) off our Video Camera, into...

Vegas Pro NLE (must internally convert that YUV input to it's INTERNAL sRGB Colour Space (tiny rounding errors I presume), out to...

MagicYUV AVU file for external use - I assume we should only use the RGB(24) output setting if we want Lossless file to take into another application.

Is that right?

Yes, in this case if you want to be absolutely lossless, that is the way to go.

So, when you say: raw/uncompressed input that would come from Vegas Internal sRGB,

and compressed output: that would be the Mathematically Compressed (Lossless) MagicYUV output file.

Again, is that right?

Correct.

 

ReplyQuote
Richard Bushell
(@richard-bushell)
Active Member
Joined: 4 years ago
Posts: 11
19/12/2016 10:42 pm  

With VirtualDub using YUV 4:2:0 directly as you suggest, I assume this would be a *Lossless* Transcode of the YUV420 source file to the YUV420 output file?

And of course, I assume this would also result a smaller output AVI than if we went through the NLE and created a RGB24 AVI output file?

p.s. During your development, did you ever compile/find a list of NLE & Imaging Applications stating what INTERNAL PROCESSING Colour Spaces they use natively?


ReplyQuote
Balázs
(@ignus)
MagicYUV Author Admin
Joined: 4 years ago
Posts: 207
19/12/2016 10:52 pm  

Yes, that's the best way for initial transcode (in both quality, disk space and performance).

I didn't compile an exhaustive list, but in my experience most apps simply request RGB from the codec, and also present RGB for encoding, so the conversion is up to the codec to do. Internally they almost always work in RGB, either 8/16bit or float, but that depends on the app. Adobe AE has 3 modes for example, Vegas I think 2.


ReplyQuote
Richard Bushell
(@richard-bushell)
Active Member
Joined: 4 years ago
Posts: 11
20/12/2016 12:44 am  

But would that initial transcode through VirtualDub using YUV 4:2:0 be Lossless if the source is YUV 4:2:0?


ReplyQuote
Page 1 / 2