Alpha preservation when converting RGB32->YUV

[qyot27]

See:
https://forum.doom9.org/showthread.php?p=1979439#post1979439

Generally: ConvertToYUVAxxx functions which preserve alpha from the source or a parameter in the normal ConvertToYUV functions which keeps the alpha from the source format.

[pinterf]

I made the following considerations:

• ConvertToYUV444 is the generalization of ConvertToYV24
• Applying ConvertToYUV444 on old formats such as RGB32 must preserve the original behaviour (like ConvertToYV24) and result in YV24 (YUV444P8) and not YUVA444P8
  So no, there is no alpha preservation in this case.

(answered here: https://forum.doom9.org/showthread.php?p=1979488#post1979488)

[qyot27]

This probably should have been marked as a feature request, since it ended up being a suggestion for adding a set of ConvertToYUVA functions and/or a parameter to the existing Convert that would enable keeping alpha (defaulting to false to preserve current behavior).

[pinterf]

I see now. Suggestions welcome.

[Reel-Deal]

I think adding the ConvertToYUVA4xx functions is the better option. That way both ConvertToRGBA/ConvertToYUVA would have similar behavior:

• copy alpha plane when source has one.
• create a blank (set to max pixel value) alpha channel when source does not have one.

Right now I have the ConvertToYUV4xx functions documented as "The final output color format depends on the input clip, for example if the source is 16-bit then the output will be YUV444P16. If the source has an alpha channel then it would be YUVA444P16."

Maybe even make ConvertToYV12/16/24 a synonym for ConvertToYUV4xx. ConvertToYVxx are limited to 8-bit I/O but if they were to become a synonym then you could use it on a clip with a bitdepth >8 and still end up with the same result as if you would of used ConvertToYUV4xx. It would not break anything since only the ConvertToRGB24/32/48/64 do any actual bitdeph conversion.