Take an mp4/h264/YUV420 movie
https://c.gmx.net/@1155842887640945833/o46DBll3QqiL0KZkxjFo4g
Open with MPC-HC or VirtualDub2
Export 1st frame (PNG)
Open movie with ADM.
Export 1st frame.
Result:
ADM frame is significantly (Not randomly, but overall) darker.
When recoding the movie with same settings (h264/YUV420/crf18)
the difference seems to be the same/ maybe stronger.
This is kind of importance as doing a detailed comparison
I often use frame export.
There are multiple pixel format and color range conversions involved, at least mpv screenshot seems to agree with JPEG export from Avidemux here (on macOS), but yes, it is generally a mess.
Thank you :) - after all I do know now what's going on.
@eumagga0x2a:
This (https://forum.doom9.org/showthread.php?p=2000450#post2000450) might be an issue for you, as in my tests ADM generates the same (wrong) colors as ffmpeg.
In short: unsufficient flags for swscale.
EDIT:
Maybe not use swscale at all but zscale?
Update:
Meanwhile I made the experience that the unwanted changing of color (slightly less red/ more blue/ darker)
mostly isn't due to ffmpeg's swscale, but of wrong color space used:
If the actual color space is Rec.709 (HD), but there is no entry in the meta data for this,
most applications (ADM too) take Rec. 609 (SD) table for all kind of conversions;
even if movie dimensions are HD obviously.
This wrong color color table seems to be the true cause for the color changes.
Although we don't have any influence at the color space entry in movie meta data (correct or missing at all)
we (ADM) could make an automatic check:
Read and write a frame, then compare both.
If characteristic color change: change color space until frames matches.
I think this should help prevent MANY unwanted degradation of movies.
Unnotified mostly, as you have to do an A-B-comparision to recognize.
Super idea, or complete nonsense?
However, eager for a new version of ADM to come :) :)
Quote from: guju on August 12, 2024, 05:06:00 PMmost applications (ADM too) take Rec. 609 (SD) table for all kind of conversions
Avidemux defaults to BT.709 unless the decoder says otherwise.
Quote from: guju on August 12, 2024, 05:06:00 PMAlthough we don't have any influence at the color space entry in movie meta data (correct or missing at all)
we (ADM) could make an automatic check:
Read and write a frame, then compare both.
How should it compare? How should it know whether colors on the screen are right or not quite right?
The idea is like that:
If the color table in movie's meta data is wrong,
or if it's BT609 but there's no entry for it...
then ADM assumes the wrong matrix for some OPs.
Right?
If you now do such an OP (which uses color table),
for example transcode (?), and save that,
then the orig frames and transcode frames should
be quite similar, if you assumed the right color table.
If you assumend the wrong color table, the frames
will differ in a special manner (see first post).
So you know the true color table of the movie...
(God, don't led me be wrong with that idea).
Actually I experience exactly that:
Doing same say sharpen on a movie and transcode it,
the movie is slightly more bluish, less red, darker.
When I change manually the color table,
the resulting frames are OK.
Maybe my knowledge isn't correct with that issue...
I thought that choosing the wrong color type (Rec. 601 vs. Rec. 709)
would "both ways" change the color in the sketched way.
But now I read that choosing 709 is always better,
even if the orig movie is of 601.
However I made the experience that the other way round
- using 601 for a 709 movie - does the color changing for sure.
As I use ADM for reliability and VD2 for special filters,
most probable VD2 uses 601 if there is no meta data entry.
(As when I change it manually to 709 the color change is gone).
Once again I've to agree to you...
Quote from: eumagga0x2a on November 13, 2023, 12:06:05 AM... but yes, it is generally a mess.
As conclusion the effect caused by darkening frames by ADM
most be due some other reason (see mentioned link (https://forum.doom9.org/showthread.php?p=2000450#post2000450)).
Sorry for the confusion.