How does Premiere and Photoshop handle color conversions?

[Hypersonic1]

I read that converting from YUV to RGB loses color detail. However, I read that I need to convert to RGB when I apply modifications. How am I suppose to work with video like that?

[LMotlow]

People make these conversions all the time without a great deal of damage. Unfortunately Adobe never did get the proper hang of it, so if their software is your mainstay and you can't use anything else, you have to take your losses. You don't always get what you pay for.

In Avisynth, use the correct color matrix and notation for interlaced or progressive video.

ConvertToRGB32(matrix+"rec601",interlaced=true)  #<- (or interlaced =false, whichever applies)

Even better is Avisynth's Dither plugin:

Dither_convert_yuv_to_rgb(matrix="601",interlaced=true,tv_range=true,cplace="MPEG2",lsb_in=false,output="rgb32")

Adobe doesn't do so well getting back to YV12 from RGB, either. Maybe some Adobe gurus can offer more help, but I avoid Adobe for a lot of operations even though I use AfterEffects and Premiere for other jobs. Color conversion and resizing, no.

You're doing all this with lossless media, of course.

[poisondeathray]

I read that converting from YUV to RGB loses color detail. However, I read that I need to convert to RGB when I apply modifications. How am I suppose to work with video like that?

What kind of "modifications" are you doing specifically ? Not all "modifications" require converting to RGB - unless you NEED to convert to RGB , you should avoid doing it. Premiere can work in YUV, has YUV filters.

[Hypersonic1]

I would prefer to use a video editor. Is there a video editor other than Premiere Pro that is better for handling this problem?

What kind of "modifications" are you doing specifically ? Not all "modifications" require converting to RGB - unless you NEED to convert to RGB , you should avoid doing it. Premiere can work in YUV, has YUV filters.

Does the motion and opacity effects require converting to RGB? Those are built-in effects. Also, filters like Unsharp Mask do not have a YUV and 32-bit version.

How will I know if the video editor is converting to RGB?

[poisondeathray]

I would prefer to use a video editor. Is there a video editor other than Premiere Pro that is better for handling this problem?

Not really.

Does the motion and opacity effects require converting to RGB? Those are built-in effects. Also, filters like Unsharp Mask do not have a YUV and 32-bit version.

How will I know if the video editor is converting to RGB?

Yes motion and opacity work in YUV, if your source is treated as YUV

If you need YUV sharpening, you can use avisynth . If that's all you need for your project you could cut in premiere, sharpen with avisynth and that's a pure YUV workflow

If there is no YUV name or it has a RGB label, then assume that section you've applied it to is converted to RGB. Only that section is converted (whole video isn't necessarily converted) .There is no way to know directly, but if you apply an RGB filter, that section usually has a red render bar . It's not a perfect indicator because there are many other reasons that can cause red render bar. Another indirect way is to use a full range YUV testclip, and look at the YC waveform as you apply something. It will be clipped to IRE100 (Y=235) when converted to RGB. But that's not perfect either, because 32bit RGB effects can access YUV before the RGB conversion (ie. they are not clipped immediately)

When Adobe works in 32bit you will have access to superbrights and darks (they will be accessible) even though it's converted to RGB (in most other software, those values will be clipped with a "normal" RGB conversion) - thus it's a good habit to "legalize" levels in YUV before you do anything else to be safe. That's true of everything in general, not just Adobe. Preventing clipping of superbrights/darks is the biggest avoidable loss for YUV/RGB conversions. The other lossess you can't do anything about if you have to convert between YUV/RGB

To be 100% sure, you can do some tests e.g. export it out , examine it => thats the best way IMO as you should be testing the validity of your workflow end to end, because there are other places not on the timeline where you might incur a conversion.

[Hypersonic1]

What is the difference between converting from YUV -> RGB32 -> YUV and just keeping it YUV? Since it uses 32-bit floating point numbers, and the rounding errors are tiny, the color loss is insignificant. Right?

Also, would there be any difference between 24 bit and 32 bit? What about Render at Maximum Depth?

At the bottom there is a setting called Use Maximum Render Quality, which I have heard it has been tested, and it results in no improvement in quailty while significantly increasing render times?

[poisondeathray]

What is the difference between converting from YUV -> RGB32 -> YUV and just keeping it YUV? Since it uses 32-bit floating point numbers, and the rounding errors are tiny, the color loss is insignificant. Right?

The difference is colorspace conversion. They are non overlapping color models (There isn't a solvable 1:1 representation of all values), so there is always some loss , also from rounding which is minimized if you use higher bit depths. Eitherway there is measureable, observable loss. Whether or not you can "see" the difference with your own eyes on your type of project or footage is a different matter. For some people the loss is negligible, others feel they have to use best practices. Only you can answer what workflow is suitable for your goals

Also, would there be any difference between 24 bit and 32 bit? What about Render at Maximum Depth?

Those selections in your screenshot mean 24bit total (ie 8bit per channel or 8bit ie. 8 red, 8 green, 8 blue if working in RGB. 8 Y, 8U, 8V if working in YUV). 32bit isn't 32bit per channel, it's an added alpha channel if you have a valid one , otherwise a dummy channel is added .

At the bottom there is a setting called Use Maximum Render Quality, which I have heard it has been tested, and it results in no improvement in quailty while significantly increasing render times?

Yes, MRQ is much slower but it enable certain operations like better resizing algorithms (modified bicubic instead of bilinear), 32bit processing on the CPU instead of 8bit - It might or might not be worth it depending on your situation and project specifics. Certain effects , situations definitely benefit like effects on gradients