color difference using Watermark filter to overlay image

[renevane]

While running some tests with the Watermark filter overlaying logo images on videos I noticed a color/brightness difference in the overlayed image. I am assuming that the Watermark filter itself is not supposed to change anything if the Opacity slider is set to its maximum value of 257?

Included in this report are the files needed to reproduce the observed behavior. The assets have been zipped.

'colored_1280x720.mp4': a 720p25 video, duration 5 seconds, no audio, displaying the color #F0505A, used as input for FFAStrans
'colored_489x489_square_on_1280x720_transparent_background': the image used in the Watermark filter; it displays the same color as the video
'Watermark color discrepancy.json': the FFAStrans workflow definition

The expected FFAStrans output is a video with the overlayed square blending in perfectly with the background.
The actual output however is a video with a clearly visible square. 'colored_1280x720 (processed).MP4' is included for reference.

If my assumption about the Watermark filter is correct then this post may serve as a bug report.

[FranceBB]

Uhm... It's either a colormatrix conversion problem or a limited Vs full range problem. Let me turn on my computer and I'll get back to you.

[FranceBB]

Ok, so I'm in front of my computer now.

This is the video as it has been indexed:



As you can see it's just a yv12, so 4:2:0 8bit BT709 Limited TV Range as we can see from here:



Now, here's the image as it's indexed by ImageSource:



It's RGB 24bit + Alpha channel, so RGB 32bit, not yuv, therefore you can't mix and match those two as they both have to be the same, so yv12 needs to be converted to RGB before the two are overlayed and here the problem happens.

Of course, the video is limited tv range, therefore, while converting to RGB, levels must be expanded to Full Range from Limited TV Range and zlib (AVS Resize) comes in our help.
At this point it's just as easy as:



so:

Code: Select all

LWLibavVideoSource("Z:\assets\colored_1280x720.mp4")
z_ConvertFormat(pixel_type="RGBP8", colorspace_op="709:709:709:limited=>rgb:709:709:full", dither_type="none")
video=last

ImageSource("Z:\assets\colored_489x489_square_on_1280x720_transparent_background.png", pixel_type="RGB32")
Crop(420, 120, -420, -120)
image=last

Overlay(video, image, greymask=true, pc_range=false, opacity=1.0, x=400, y=120)

in fact:




Anyway: as a last remark we have the question: is this a bug?
To which my answer is: no.
The overlay filter is a very basic filter and we can't work around any possible matrix and levels conversion, therefore we expect the user to provide the files ready to be overlayed. This means that you can't feed FFAStrans with a Limited TV Range video and a Full Range Picture and expect it to convert levels and overlay them correctly.
You can however work around the whole thing via a custom made Avisynth Script.



EDIT: Ok, I've discussed the issue with Steinar and maybe we can do something so that we can handle some of those kind of conversions to make life easier for users. After all, we're FFAStrans not Avisynth, so we can build a logic around what the Overlay() function gets, however don't hold your breath just yet as we have to try to automatize this and see how it goes.

[renevane]

Thank you very much for explaining exactly how and where the color difference occurs.

EDIT: Ok, I've discussed the issue with Steinar and maybe we can do something so that we can handle some of those kind of conversions to make life easier for users. After all, we're FFAStrans not Avisynth, so we can build a logic around what the Overlay() function gets, however don't hold your breath just yet as we have to try to automatize this and see how it goes.

That would be awesome! Trying not to hold my breath!

[admin]

Hi renevane,

Just took a quick look at your workflow again and I think we can fix it by adding the "Color conversion" filter like so:

color_conv.png (15.37 KiB) Viewed 8236 times

Please try and let us know the result.

-steinar

[renevane]

Unfortunately this doesn't address the issue; the Color conversion filter only changes the color of the video to match the color of the 'Watermarked' image. It's the Watermark filter where the unwanted color change occurs where it wasn't expected...

[FranceBB]

Well, but that's correct, 'cause since the image is Full Range and the video is Limited TV Range, either we convert the image to Limited TV Range and the overlay it to the video (but we would lose the alpha channel unless we're really careful), or we can convert the video from Limited TV Range to Full Range and then overlay the image on it.

I'll discuss with Steinar which way is the best and we'll come back to you, but if you see the picture different in the final video is almost certainly 'cause the final video has become Limited TV Range.

[admin]

Hi again renevane,

I did some new tests and it turns out there is a bug with the inbuilt "Color conversion" filter. So, converting source to 601 and everything back to 709 works in the upcoming 1.2.2 but not in the current 1.2.1. That means we hit a bug thanks to your reporting!
That means, in 1.2.2 you should have little problems with this as long as you do some color conversions. Can you please take a look at the attached mp4 and see if it's ok? It's been converted with 1.2.2 with color conversions.

Thanks!

-steinar

[renevane]

Yes, the 1.2.2-version looks correct! And you're welcome

Thank you both very much!

[renevane]

A quick question regarding the need for color conversions in the new (1.2.2) version: if the overlay image is created in the 709 color space and saved with the 709 color profile embedded in it (Photoshop let's you do this), and the video being already in 709 (Premiere Pro takes care of that), will (or should) there still be a need to do conversions? Maybe I still do not fully understand the limited tv range-stuff.