Yet another color issue (import in Magix NLE, YUV vs. RGB, Rec709 / Rec601)

[abolibibelot]

This is driving me nuts... AGAIN !
Just a year ago I had an issue with shifted colors when importing files into Magix Video Deluxe (AKA Magix Movie Edit). I thought that the colors were correct for the native .m2ts files, and wrong when importing an Avisynth processed lossless intermediate in original YUV colorspace. So the replies I had were based on that assumption. The proposed explanation was that this software was importing YUV lossless files with the incorrect Rec601 matrix, and therefore I should export those files as RGB, by adding a ConvertToRGB(matrix="Rec709") command at the end of the Avisynth scripts. That's how I proceeded from then on.
Tonight I resumed editing that same project in MVD, imported one of the RGB lossless intermediates (created with VirtualDub2), and noticed that the colors were shifted again... So I made several tests, with a video I created which includes at some point a still picture which I took of a red car, with green leaves in the background, thus ideal for that kind of comparison.

– MVD display with the original untouched straight-from-camera JPG still picture on the timeline :

You can see that the car is supposed to be red-orange, not deep red.
– MVD display with an excerpt (cut with mp4box so direct stream copy) from the MP4 video which includes that picture (edited with Magix Video Deluxe, then exported as lossless RGB, then encoded with MeGUI, via an Avisynth script specifying “ConvertToYUV(matrix="Rec709")”) :

The colors are wrong !
– MVD display with an excerpt from the same video cut with VirtualDub2 and exported as Lagarith YUV :

The colors are correct ! (The picture is a little brighter than the original, most likely because I increased the gamma a little when editing that movie – which was probably unnecessary for that particular picture. But the color shades seem accurate.)
– MVD display with an excerpt from the same video cut with VirtualDub2 and exported as Lagarith RGB :

The colors are wrong !
– VLC Media Player screenshot from the MP4 video :

The colors are wrong...
– SMPlayer screenshot from the MP4 video :

The colors are correct...

Another example :
– MVD display with native .m2ts file

– MVD display with Lagarith YUV export :

– MVD display with Lagarith RGB export :

– VLC Media Player screenshot from the original .m2ts file :

– SMPlayer screenshot from the original .m2ts file :


Here I don't have a reliable point of reference (unless I ask my mother to show me that red shirt at the same spot and the same hour ! ), but judging from the pattern in the test above, the correct presentation of colors seems to be the one with the lightest shade of red, so it would be the YUV Lagarith export, and the other two are wrong, while, again, VLC is wrong and SMPlayer correct. What is surprising here is that the seemingly correct presentation is excessively bright, with less detail in the shadows.

And yet, looking at the screenshots I made a year ago, it would seem like the display was correct with the .m2ts files then – but I made those screenshots with VLC Media Player, which seems consistently wrong, so I can't rely on that.

So what sense can I make of all this ? Is it possible that this software treats original files with the wrong colorspace conversion matrix and lossless YUV files with the correct matrix ? But how can it display the wrong colors for lossless RGB, explicitly converted with the Rec709 matrix ? Could this be caused somehow by the system codec configuration, since I tinkered with that recently ? (And I had to tweak it again, by deactivating LAV filters for Lagarith, because that was somehow causing MVD to import Lagarith files incorrectly : the frames would appear out of order, some of them would appear corrupted... yet another unexpected screw-up...) What other tests could I make to be 100% sure of the diagnostic, and what would be the remedy ?

What's bugging me is that, a year ago, an imported RGB lossless file would be displayed with the same colors as the original .m2ts, yet I did those tests tonight because it was no longer the case, but those tests showed that this is indeed the case...
Wait, it gets crazier ! When comparing the colors of the RGB lossless vs. the colors of a newly imported .m2ts, I get the same colors (wrong), but when comparing either the RGB lossless or the newly imported .m2ts with the .m2ts which was already in the timeline when I opened the project (it's the exact same source file), I get different colors : the colors are correct with the latter, i.e. the movie object which was already in the timeline. Apart from the stabilization, no processing was applied. But if I reinitialize all video effects... the colors become incorrect, just like with the newly imported file !

– MVD display for the newly imported .m2ts :

– MVD display for the .m2ts which was in the timeline already, with only stabilization applied (hence the slight zoom-in) and no other treatment :

– MVD display for the .m2ts which was in the timeline already, all video effects reinitialized (if I only remove the stabilization it doesn't change the colors) :


Does that make any sense at all ? Or am I really going crazy ?


----------------------------------

Another unrelated issue (I haven't much hope for this one to be solved, considering how Magix products are unpopular over here and noone seems to have a specific experience with them). I wanted to try the Magix stabilizer again, to compare it with Deshaker, and ran into yet another malfunction : that module is supposed to allow tracing the analyze area with the mouse pointer, but this doesn't work, the white rectangle can't be reshaped. (And it's not possible either to modify the parameters by editing the parameters.)

It definitely used to work with a former version of that software, but if I remember correctly I already had this problem before with that version. I only found it mentioned in this thread, although no solution is proposed :
https://www.magix.info/us/forum/mep-2018-magix-image-stabilization--1202979/
In general, what could prevent the interaction with that kind of overlay ? Could there be some setting to tweak in the general parameters to get this feature to work as it should ? Or is it most likely a bug with that particular version ? But I'm using v. 2016, so such an egregious bug wouldn't have been corrected in two years, seems weird...

[poisondeathray]

So what sense can I make of all this ? Is it possible that this software treats original files with the wrong colorspace conversion matrix and lossless YUV files with the correct matrix ? But how can it display the wrong colors for lossless RGB, explicitly converted with the Rec709 matrix ? Could this be caused somehow by the system codec configuration, since I tinkered with that recently ? (And I had to tweak it again, by deactivating LAV filters for Lagarith, because that was somehow causing MVD to import Lagarith files incorrectly : the frames would appear out of order, some of them would appear corrupted... yet another unexpected screw-up...) What other tests could I make to be 100% sure of the diagnostic, and what would be the remedy ?

You can't make any sense of it until you know your software is accurate. At the very least , you're showing inconsistent results with MVD. You can't make a valid observation, unless you can repeat that observation. So how does anyone know the screenshots you're showing are even correct ?

Even a jpg reference shot can be problematic. You need to verify the jpg display too. Because there are different types of jpg (most of them are acutally
YUV usually with subsampling internally), and some of them have metadata that can affect what you see. Just like PNG can have metadata that affect the display (do you remember that ffmpeg screenshot thread ? ) . Is MVD displaying jpg correctly ?

It's never a good idea to mess with codecs or configurations during a project, especially a long one. Did you also update the program itself ? Like a version update ?

Wait, it gets crazier ! When comparing the colors of the RGB lossless vs. the colors of a newly imported .m2ts, I get the same colors (wrong), but when comparing either the RGB lossless or the newly imported .m2ts with the .m2ts which was already in the timeline when I opened the project (it's the exact same source file), I get different colors : the colors are correct with the latter, i.e. the movie object which was already in the timeline. Apart from the stabilization, no processing was applied. But if I reinitialize all video effects... the colors become incorrect, just like with the newly imported file !

Is the "exact same source file" , really exactly the same, as in the same physical location too? Or is it a copy of the file in a another directory ?
You might be having some sort of cache issues. It might be referencing the old cache files. See if there is a way to delete the cache , or force a reimport of assets . One way to do that in other programs is to move the physical files to a different directory. The program will think "missing file"... where are you my precious?!... Then you relink the files to the new directory and usually that will force a re-import. But beware , some cheaper editors don't have re-link functions. You might have to manually show the path for each reference instead of "automatic". So make sure you back up your project if you decide to try this...

What is "reinitialize all video effects" besides stabilization ? Did you have any color filters for example ?

[_Al_]

If anything pops on your screen and source is YUV, it got transferred yet again to RGB. You have always one more transfer from YUV going on. Software/player might have different preferences to get color matrix. Codec, resolution, color format etc. JPG would be last thing to try to figure out correct color space from if you think that way. JPG is YUV and mostly gotten as a screen grab which was RGB, so perhaps messy transfers possible.

Use avsPmod with Avisynth script or Vaporsynth and Vapoursynth Editor to see your colors, if in doubt all the time , you might have HD camcorder that is shooting wrong color space but that you'd probably know already.

[poisondeathray]

Use avsPmod with Avisynth script or Vaporsynth and Vapoursynth Editor to see your colors, if in doubt all the time , you might have HD camcorder that is shooting wrong color space but that you'd probably know already.

Exactly .




And avspmod writes PNGs untagged, so it displays the same way in every program (for the most part, some mac programs still have a gamma issue). So this is known, validated , consistent behaviour. Whereas if you recall that ffmpeg thread, I demonstrated proof where there are cases where ffmpeg can write out PNG's where the gAMA and cHRM tags cause different display colors in different applications.

Remove all the flaky variables and stick with known entities, at least at first for a starting point. Also control every conversion that you can by specifying it directly. So the first thing I would do is use ffms2 or lsmash, open that reference MP4 and make a screenshot by using ConvertToRGB, using Rec601 , another with Rec709. Those are your 2 known reference points. Nothing about whether they are "right or wrong" now. Just known observation references for now that you can use to compare later on

Because when you write stuff like "– MVD display with an excerpt from the same video cut with VirtualDub2 and exported as Lagarith RGB :" , there are bunch of other variables. Such as - did lagarith do the RGB conversion? Did vdub do the conversion? Did the vdub source filter do the conversion ? Which source filter in vdub? What matrix ? You need to know the exact steps and lineage, otherwise the observation is not very useful

[abolibibelot]

You can't make any sense of it until you know your software is accurate. At the very least , you're showing inconsistent results with MVD.

Apparently it is not accurate in this case... And yes it's inconsistent, I'm trying to understand why, and hopefully fix it.
My description of the issue may be a little confusing because I completed it several times while I was doing further testing and coming up with new findings. I preferred to let it that way, presented in chronological order, because trying to rewrite everything in a more streamlined way would have been based on possibly wrong assumptions, thus eliciting possibly wrong suggestions.

You can't make a valid observation, unless you can repeat that observation. So how does anyone know the screenshots you're showing are even correct ?

Well, because I spent about two hours making those tests and double-checking everything... Other than that, indeed, noone can be sure of anything in this world. And as Mark Twain wrote, “you can't depend on your eyes when your imagination is out of focus”.

Even a jpg reference shot can be problematic. You need to verify the jpg display too. Because there are different types of jpg (most of them are acutally
YUV usually with subsampling internally), and some of them have metadata that can affect what you see. Just like PNG can have metadata that affect the display (do you remember that ffmpeg screenshot thread ? ) . Is MVD displaying jpg correctly ?

Yes I remember, but silly me, I still rely on PNG screenshots, as a reflex... But if neither PNG nor JPG are reliable, then what is ? Is at least BMP 100% reliable ?
MVD is displaying the JPG picture just the same as Windows 7 image viewer, or XnView : the car is red-orange rather than deep-red, and the leaves are not flashy-green.

It's never a good idea to mess with codecs or configurations during a project, especially a long one. Did you also update the program itself ? Like a version update ?

I never expected this one to be this long... And I didn't figure that such a complex piece of software as a video editor could possibly be affected when I messed with codec settings for totally unrelated reasons – I mean, it should be designed to work the same on every computer and with every system configuration. (But in fact I already know that it is dependant on system codecs because at some point it failed to import raw YV12 from AVFS-mounted Avisynth scripts, which was solved by installing ffdshow 64bit.)
I upgraded MVD once since I began that project, because of an issue whereby exporting in 29.97 FPS would result in a progressive desynchronization, with MVD 17 from 2010 ; resuming the project in version 2016 solved that. I haven't upgraded the software since, but I've upgraded the computer ; but that was more than a year ago, since then I haven't noticed that kind of issue (granted, that doesn't mean that it wasn't there).

Is the "exact same source file" , really exactly the same, as in the same physical location too? Or is it a copy of the file in a another directory ?

I had moved the .m2ts files (or the drive's letter changed, or both) before resuming that project, and MVD, although being on the cheap end of the spectrum in the grand scheme of video editors, conveniently asked where the precious files had gone, and re-linked them automatically. It creates .H0 and .HDP index files in the same directory as the source files, which I kept and moved along when I moved the source files. Normally if I remove/rename those files it has to re-import the source files. But in this case, I obtain the expected behaviour with the files, or rather the movie objects, which were already in the timeline, and an unwanted behaviour for the newly added files.
And yes, in those tests, the movie objects which were there already in the project do refer to the very same files in the same location as the newly added movie object. I did those tests first inside the project in question, then in a newly created project.

What is "reinitialize all video effects" besides stabilization ? Did you have any color filters for example ?

This is a feature in MVD, when right-clicking on a movie object, there's a “Video effects” field in the contextual menu, which opens a drop-down sub-menu, and one option is “Reinitialize video effects...”. But as I said, the only effect applied on this particular movie object I used for those tests (which I chose because it prominently shows a red “object”) was stabilization, I didn't apply any color filter / gamma / saturation tweaking or anything ; there's a list of the effects currently applied right after the name of each object, for that particular video object it only shows (translated) : “Stabilization image X Stabilization image Y Stabilization width Stabilization heigth” – nothing else. And yet, when I click on “Reinitialize video effects...” it immediately changes the colors, in exactly the same way as the newly imported movie object created from the very same file on the same location is displayed.

[poisondeathray]

But if neither PNG nor JPG are reliable, then what is ? Is at least BMP 100% reliable ?
MVD is displaying the JPG picture just the same as Windows 7 image viewer, or XnView : the car is red-orange rather than deep-red, and the leaves are not flashy-green.

Not necessarily; BMP is only more reliable because of the reduced probability of an application , or user writing tags. They can still have colorspace tags, gamma channel tags, ICC profile tags, render tags to name a few

As you know, nothing is 100% foolproof . Also BMP's are painful to share . You'd have to zip them up for courtesy

But when I mentioned jpg, I meant display of the jpg. You wrote "– MVD display with the original untouched straight-from-camera JPG still picture on the timeline ". The jpg was direct from camera. But many cameras write metadata and tags to their files. Not all applications display camera photos correctly. Is MVD decoding the jpg correctly, and displaying it correctly? I don't know how reliable Win7 image viewer or XnView are, but at least you have 3 applications that display the jpg the same way, but that's better than nothing. If the camera was a consumer level camera, there is a higher likelihood that it will display correctly in most applications too.

What is "reinitialize all video effects" besides stabilization ? Did you have any color filters for example ?

This is a feature in MVD, when right-clicking on a movie object, there's a “Video effects” field in the contextual menu, which opens a drop-down sub-menu, and one option is “Reinitialize video effects...”. But as I said, the only effect applied on this particular movie object I used for those tests (which I chose because it prominently shows a red “object”) was stabilization, I didn't apply any color filter / gamma / saturation tweaking or anything ; there's a list of the effects currently applied right after the name of each object, for that particular video object it only shows (translated) : “Stabilization image X Stabilization image Y Stabilization width Stabilization heigth” – nothing else. And yet, when I click on “Reinitialize video effects...” it immediately changes the colors, in exactly the same way as the newly imported movie object created from the very same file on the same location is displayed.

One explanation for a change in color with an applied effect (that normally doesn't change color), might be that newer versions might work in YUV, but that stabilization effect is running in RGB.

I'm still thinking there is some old cobwebs or references going on

They might have changed the color behavior between versions for YUV<=>RGB conversions. Add on top your fiddling with decoders, system codecs, and it's a mess

[abolibibelot]

@_Al_

If anything pops on your screen and source is YUV, it got transferred yet again to RGB. You have always one more transfer from YUV going on. Software/player might have different preferences to get color matrix. Codec, resolution, color format etc. JPG would be last thing to try to figure out correct color space from if you think that way. JPG is YUV and mostly gotten as a screen grab which was RGB, so perhaps messy transfers possible.
Use avsPmod with Avisynth script or Vaporsynth and Vapoursynth Editor to see your colors, if in doubt all the time , you might have HD camcorder that is shooting wrong color space but that you'd probably know already.

But... that JPG picture, which as I said is straight from the camera, what determines how it should be displayed ? How is it converted to RGB, with regards to colors ? I just tried opening it in AVSPMod with ImageSource("pathname\filename.jpg"), it's displayed just like in MVD, XnView or the image viewer in Win7, so at least that is consistent.
The problem is an inconsistency in the way video is displayed, I made tests with that picture and video representations of that picture, because I thought that this would be a stable and reliable starting point, but you're saying that it is not ?


@poisondeathray

And avspmod writes PNGs untagged, so it displays the same way in every program (for the most part, some mac programs still have a gamma issue). So this is known, validated , consistent behaviour. Whereas if you recall that ffmpeg thread, I demonstrated proof where there are cases where ffmpeg can write out PNG's where the gAMA and cHRM tags cause different display colors in different applications.

Here I made all the screenshots from MVD with XnView).

Remove all the flaky variables and stick with known entities, at least at first for a starting point. Also control every conversion that you can by specifying it directly. So the first thing I would do is use ffms2 or lsmash, open that reference MP4 and make a screenshot by using ConvertToRGB, using Rec601 , another with Rec709. Those are your 2 known reference points. Nothing about whether they are "right or wrong" now. Just known observation references for now that you can use to compare later on

With :

FFVideoSource("pathname\filename.mp4")
ConvertToRGB(matrix="Rec601")

I get the wrong colors as expected (deep red).

With Rec709 or no ConvertToRGB line, I get the correct colors (light red, like the JPG picture straight from camera as it's displayed everywhere I tried, including in MVD).

(Screenshots made by AVSPMod this time.)

Because when you write stuff like "– MVD display with an excerpt from the same video cut with VirtualDub2 and exported as Lagarith RGB :" , there are bunch of other variables. Such as - did lagarith do the RGB conversion? Did vdub do the conversion? Did the vdub source filter do the conversion ? Which source filter in vdub? What matrix ? You need to know the exact steps and lineage, otherwise the observation is not very useful

To export as YUV, I clicked on “Pixel format”, and selected “No change”, which here means “YUV420”. To export as RGB I didn't change the default setting which is RGB24. But when I first noticed the issue, that was with files created from AVS scripts containing a ConvertToRGB(matrix="Rec709") command, and the pattern was identical : those files would be displayed differently than the movie objects referring to .m2ts files which were already in the project when I re-opened it, but later I found out that newly created movie objects were displayed the same as the RGB ones created with a specific Rec709 Avisynth conversion. (Sorry for the convoluted sentence, but I don't know how to express this elegantly and with no ambiguity at the same time... Plus I'm tired...)

[poisondeathray]

But... that JPG picture, which as I said is straight from the camera, what determines how it should be displayed ? How is it converted to RGB, with regards to colors ? I just tried opening it in AVSPMod with ImageSource("pathname\filename.jpg"), it's displayed just like in MVD, XnView or the image viewer in Win7, so at least that is consistent.

Image metadata tags can affect how it's displayed. If you were to examine the jpg at a lower level, very likely it's actually YUV . If you're interested , you might use exiftool or jpegview . YUV encoded Jpegs are usually stored at full range and converted to RGB at full range , usually with 601 by convention. But some applications can retrieve the original YUV data. e.g. FFMS2 or JPEGSource can eturn YUV for YUV encoded JPEG 's instead of "auto" converting to RGB

But on the behaviour of tags, even in avisynth , different image source filters can behave differently. ImageSource can behave differently than CoronaSequence in terms of image tags.

@poisondeathray

And avspmod writes PNGs untagged, so it displays the same way in every program (for the most part, some mac programs still have a gamma issue). So this is known, validated , consistent behaviour. Whereas if you recall that ffmpeg thread, I demonstrated proof where there are cases where ffmpeg can write out PNG's where the gAMA and cHRM tags cause different display colors in different applications.

Here I made all the screenshots from MVD with XnView).

The reason I mentioned ffmpeg is because it's a frequently used tool, and still unreliable for some common things like screenshots in some situations. So how reliable is XnView ? Is there other processes going on ? Other conversions ? Did you test it thoroughly ?

(Screenshots made by AVSPMod this time.)

That's a reliable starting point. Lots of experience debugging issues like this says so.

To export as YUV, I clicked on “Pixel format”, and selected “No change”, which here means “YUV420”. To export as RGB I didn't change the default setting which is RGB24.

For lagarith, the default RGB24 setting actually means YUV if you send it YUV . So if you opened a YV12 file directly, and vdub served it correctly, the lagarith file would actually be YV12 when you have the lagarith configuration set to RGB24 (Default) . If you don't believe me just check it with ffmpeg for example. A prime example of why you should be controlling everything. If you wanted RGB lagarith, I suggest you convert it with avisynth and stipulate which matrix, which settings so there is no room for error. You need to take control , be a control freak.

Yeah, I know, how is user supposed to know lagarith behaves that way... it just does.

Verify each step, the output of each step, and verify again. One wrong assumption , and everything else is faulty

[abolibibelot]

One explanation for a change in color with an applied effect (that normally doesn't change color), might be that newer versions might work in YUV, but that stabilization effect is running in RGB.

As I said, if I remove only the stabilization processing (by opening the stabilization dialog and clicking on “Remove stabilization”), it doesn't change the colors, they stay “correct”, only when I click on “reinitialize video effects” does it suddenly change the colors, and display the “wrong” Rec601 colors.
I just tried with a part of footage for which absolutely no effect / processing at all was applied : same result.
– movie object already in the project :

[Attachment 47563 - Click to enlarge]
– movie object newly created by importing the same source file from the same location :

[Attachment 47564 - Click to enlarge]
– movie object already in the project, after clicking on “Reinitialize video effects” (again, no effect was officially / intentionally applied) :

[Attachment 47565 - Click to enlarge]
(It's more subtle here, but look at the red excavators in the background, and the red scarf.)

I'm still thinking there is some old cobwebs or references going on

I'm not sure of what you mean here...

They might have changed the color behavior between versions for YUV<=>RGB conversions. Add on top your fiddling with decoders, system codecs, and it's a mess

When I investigated a similar issue a year ago, I'm pretty sure that the results were reversed, and I was using the same version. If you look at the two screenshots in the first post of the one-year-old thread I mentioned, which show the complete MVD display, including the timeline, you can see that the red tones appear lighter and the green tones darker on the original .m2ts file, compared with the .avi file, which was most likely exported as lossless YUV, since it was meant to illustrate what I described above in that same post. Now I'm observing exactly the opposite, with the same version, and lossless files explicitly created as Rec709 RGB no longer appear as they should. If I look at the exact same frame as on those screenshots (on the timeline currently saved in the project), the colors are the same as on the .m2ts screenshot I made then (lighter red tones). If I re-import the source file and find that same frame, the colors are different (darker red tones). But for some reason “Reinitialize video effect” does nothing for that one : the colors stay correct. But I noticed that this file was effectively re-imported contrary to the others tested before : another .H0 file was created, named “20131224_145353_m2ts_001.H0” (with the same size as “20131224_145353_m2ts.H0”, but totally different contents). I have no idea of what to make of all this.

For lagarith, the default RGB24 setting actually means YUV if you send it YUV . So if you opened a YV12 file directly, and vdub served it correctly, the lagarith file would actually be YV12 when you have the lagarith configuration set to RGB24 (Default) . If you don't believe me just check it with ffmpeg for example.

Where / how should I look with ffmpeg ? If I just type “ffmpeg -i filename.avi”, it reports a few informations like resolution, FPS, bitrate, but I see no mention of colorspace (I don't know what “gbrp” is).
For a Lagarith file created with VirtualDub2 using the RGB setting from a M2TS source, MediaInfo reports the colorspace as “RGB”.
For a Lagarith file created with VirtualDub2 using the RGB setting from a MP4 source, MediaInfo reports the colorspace as just “Y”, but the file size is almost double that of the file created using the no change / YUV setting (99MB vs. 170MB for 8 seconds), so it can't be the same colorspace, right ?
Since the begining of the week I have created 144GB of intermediate files but haven't progressed one bit toward the completion of that nightmare...

Yeah, I know, how is user supposed to know lagarith behaves that way... it just does.
Verify each step, the output of each step, and verify again. One wrong assumption , and everything else is faulty

That's what I tend to do more and more, but doing so it gets easy to lose track of the main goal and get overwhelmed by the amount of detail nitpicking it entails. There are already so many things to think about to get everything right at one level, without having to consider all the intricacies that are going on at the level below, and the one below that one... I'm sure that many people working on video professionally have no clue about those issues, and just expect everything they use (hardware & software) to work reliably, let someone else do the guesswork in the gloomy underground of technical matters.

A prime example of why you should be controlling everything. If you wanted RGB lagarith, I suggest you convert it with avisynth and stipulate which matrix, which settings so there is no room for error.

That's how I proceeded before I encountered this issue. Then I used VirtualDub2 only to create test files, just because it was quicker, and I thought that it would produce the same outcome, i.e. YUV when it says YUV and RGB when it says RGB. It's like going into a cab and asking the driver to go to the city hall, then having to check every ten seconds that he's not in fact bringing you to an abandoned warehouse !

You need to take control , be a control freak.

As if I needed to be even more of that ! When I was 18, some guy I barely knew and whose name I don't even remember walked in on me while I was exercising with a pair of dumbbells, and he just said something I could translate as : “You're too strict with yourself, that'll be your downfall” – then walked away (it's possible that I never saw him again which makes it even more eery in retrospect).

I still don't know what I could actually try to solve this issue and get back to where I was before – which was not far from square one.

[poisondeathray]

I'm still thinking there is some old cobwebs or references going on

I'm not sure of what you mean here...

I mean there are some mismatches going on , because you switched project files, years, locations, program versions . In some other editors (at least in the past, ahem Adobe ... cough) , unexplained buggy weirdness like you are experiencing was because of referencing old cache files or references . It tended occurred more frequently when you did version switches instead of doing everything with the same program, same computer, same setup. That issue plagued Adobe for many years, but things improved dramatically the last few versions

For example, if you start from scratch with your current configuration, setup, software, I bet it would be consistent behaviour with what you have now. (Until you revisit the project a few years down the road to complete it with a new computer, new version again....)

They might have changed the color behavior between versions for YUV<=>RGB conversions. Add on top your fiddling with decoders, system codecs, and it's a mess

When I investigated a similar issue a year ago, I'm pretty sure that the results were reversed, and I was using the same version. If you look at the two screenshots in the first post of the one-year-old thread I mentioned, which show the complete MVD display, including the timeline, you can see that the red tones appear lighter and the green tones darker on the original .m2ts file, compared with the .avi file, which was most likely exported as lossless YUV, since it was meant to illustrate what I described above in that same post. Now I'm observing exactly the opposite, with the same version, and lossless files explicitly created as Rec709 RGB no longer appear as they should. If I look at the exact same frame as on those screenshots (on the timeline currently saved in the project), the colors are the same as on the .m2ts screenshot I made then (lighter red tones). If I re-import the source file and find that same frame, the colors are different (darker red tones). But for some reason “Reinitialize video effect” does nothing for that one : the colors stay correct. But I noticed that this file was effectively re-imported contrary to the others tested before : another .H0 file was created, named “20131224_145353_m2ts_001.H0” (with the same size as “20131224_145353_m2ts.H0”, but totally different contents). I have no idea of what to make of all this.

Any control over the decoding pathway ? Does the m2ts use internal decoder ? or rely on external/system codec
Is it the same version exaactly ? or a point version release that might have fixed/altered behaviour
Is the program GPU accelerated ? What about system / GPU drivers and settings ?

Where / how should I look with ffmpeg ? If I just type “ffmpeg -i filename.avi”, it reports a few informations like resolution, FPS, bitrate, but I see no mention of colorspace (I don't know what “gbrp” is).
For a Lagarith file created with VirtualDub2 using the RGB setting from a M2TS source, MediaInfo reports the colorspace as “RGB”.
For a Lagarith file created with VirtualDub2 using the RGB setting from a MP4 source, MediaInfo reports the colorspace as just “Y”, but the file size is almost double that of the file created using the no change / YUV setting (99MB vs. 170MB for 8 seconds), so it can't be the same colorspace, right ?
Since the begining of the week I have created 144GB of intermediate files but haven't progressed one bit toward the completion of that nightmare...

Which "RGB setting" are you referring to?

What was the difference between the M2TS and MP4 ? You should be testing the same input file, not different

gbrp is planar RGB - that would be correct for one way of decoding RGB . Lagarith in AVI is usually packed, but ffmpeg prefers planar formats. Functionally they should be the same. But the file size difference suggests they are different

I'm not sure how you did it, your description isn't entirely clear. But to be perfectly clear, I'm talking about the lagarith configuration dialog box. When you have lagarith selected in the vdub compression menu, push the "configure" button . The lagarith configuration will pop up and it will say which lagarith version. When you have that set to RGB (default), if vdub is sending YV12 directly (e.g. when open the video directly and the source filter is sending YUV correctly, or an YUV avs script) , it will not be RGB, it will be YV12 lagarith

Mediainfo should be able to distinguish between lagarith variants, maybe you need a newer version?

Color space                              : RGB
Bit depth                                : 8 bits

Color space                              : YUV
Chroma subsampling                       : 4:2:0

ffmpeg should indicate "gbrp" for lagarith RGB, and yuv420p for YUV 4:2:0 (or YV12) lagarith variant

That's what I tend to do more and more, but doing so it gets easy to lose track of the main goal and get overwhelmed by the amount of detail nitpicking it entails. There are already so many things to think about to get everything right at one level, without having to consider all the intricacies that are going on at the level below, and the one below that one... I'm sure that many people working on video professionally have no clue about those issues, and just expect everything they use (hardware & software) to work reliably, let someone else do the guesswork in the gloomy underground of technical matters.

If you are trying to debug this weird behaviour in your program, you have to be precise with your observations, otherwise your tests are going to be less useful

When I was 18, some guy I barely knew and whose name I don't even remember walked in on me while I was exercising with a pair of dumbbells, and he just said something I could translate as : “You're too strict with yourself, that'll be your downfall” – then walked away (it's possible that I never saw him again which makes it even more eery in retrospect).

That guy wasn't "strict" enough . A "real warrior" would be hitting the gym more consistently. He's probably at McDonalds everyday "bench pressing" burgers and fries. That's why you don't see him in the gym anymore

I still don't know what I could actually try to solve this issue and get back to where I was before – which was not far from square one.

I'm guessing the Magix forum for MVD isn't helpful ?

You can probably salvage it by deciding how you want it to look and render it out like that. Adjust footage to match (709<=>601 is "easy" in the sense that there are established ways). Plan ahead for the path of least resistance. Try to salvage as much as prior work as you can. Then import the footage into a proper editor

[abolibibelot]

Did some more testing, in a new MVD project :
– source M2TS file from its original location (thus using the already created .H0 file, I guess) :
=> wrong colors
– copy of this file to another location :
=> wrong colors
– Lagarith AVI file created with VDub2 in “fast recompress” mode through an Avisynth script specifying “ConvertToRGB(matrix="Rec709")” :
=> correct colors
– Lagarith AVI file created with VDub2 in “fast recompress” mode through an Avisynth script with no colorspace conversion :
=> correct colors
– Lagarith AVI file created with VDub2 in “full processing” mode through an Avisynth script with no colorspace conversion, “Pixel format” = RGB24 :
=> wrong colors => same if that file is opened in AVSPMod => apparently VirtualDub2 is using the incorrect matrix by default
– Lagarith AVI file created with VDub2 in “full processing” mode through an Avisynth script with no colorspace conversion, “Pixel format” = YUV420 / no change :
=> correct colors
– Lagarith AVI file created with VDub2 in “full processing” mode, M2TS file loaded directly, “Pixel format” = YUV420 / no change :
=> correct colors
– Lagarith AVI file created with VDub2 in “full processing” mode, M2TS file loaded directly, “Pixel format” = RGB24 :
=> wrong colors

[poisondeathray]

– source M2TS file from its original location (thus using the already created .H0 file, I guess) :
=> wrong colors
– copy of this file to another location :
=> wrong colors

Also
a) Copy the m2ts to a different location (without any of the preexisting accessory .H0 files or whatever), rename the file as well, then test

b) Rewrap to a different container, say MP4, and rename the file and move location for good measure , then test

– Lagarith AVI file created with VDub2 in “fast recompress” mode through an Avisynth script specifying “ConvertToRGB(matrix="Rec709")” :
=> correct colors

as expected

– Lagarith AVI file created with VDub2 in “fast recompress” mode through an Avisynth script with no colorspace conversion :
=> correct colors

Double check what kind of lagarith file was actually produced; with mediainfo, and ffmpeg .

If it was 4:2:0 lagarith, you would expect wrong colors , because most programs would be using Rec601 by default to convert back to RGB for the display (and/or timeline)

Is default system lagarith decoder official , or lav , currently ?

– Lagarith AVI file created with VDub2 in “full processing” mode through an Avisynth script with no colorspace conversion, “Pixel format” = RGB24 :
=> wrong colors => same if that file is opened in AVSPMod => apparently VirtualDub2 is using the incorrect matrix by default

Whenever you let something else do the colorspace conversion, by default, unless otherwise specified - 99% of the time Rec601 is used. So this is an expected result. This is true for vdub too. There are ways to specify the actual conversion in vdub2

– Lagarith AVI file created with VDub2 in “full processing” mode through an Avisynth script with no colorspace conversion, “Pixel format” = YUV420 / no change :
=> correct colors
– Lagarith AVI file created with VDub2 in “full processing” mode, M2TS file loaded directly, “Pixel format” = YUV420 / no change :
=> correct colors

you would expect the opposite in most programs, if the default lagarith decoder was used

you would expect the recieving program/editor to use Rec601 , and thus get wrong colors for those 2 cases

media players are slightly different case than editors. Some have logic based on certain height or width dimensions, then use 709, otherwise 601

– Lagarith AVI file created with VDub2 in “full processing” mode, M2TS file loaded directly, “Pixel format” = RGB24 :
=> wrong colors

expected result because VDub2 is using Rec601, unless you took measures otherwise

[abolibibelot]

Any control over the decoding pathway ? Does the m2ts use internal decoder ? or rely on external/system codec

There's a long list of import modules, each can be selected or not :

Is it the same version exaactly ? or a point version release that might have fixed/altered behaviour

Same exactly.

Is the program GPU accelerated ? What about system / GPU drivers and settings ?

That I don't know. System is relying on the graphic chip from the Intel i7 6700K, no dedicated graphic card.

Which "RGB setting" are you referring to?

In “Pixel format”.

What was the difference between the M2TS and MP4 ? You should be testing the same input file, not different

Both are currently displayed with wrong colors when imported into MVD. M2TS are source files needed for this project. I did some tests with this MP4 because it shows that picture which I think I know how it should be displayed.

I'm not sure how you did it, your description isn't entirely clear. But to be perfectly clear, I'm talking about the lagarith configuration dialog box. When you have lagarith selected in the vdub compression menu, push the "configure" button . The lagarith configuration will pop up and it will say which lagarith version. When you have that set to RGB (default), if vdub is sending YV12 directly (e.g. when open the video directly and the source filter is sending YUV correctly, or an YUV avs script) , it will not be RGB, it will be YV12 lagarith

Right, there are two buttons next to each other (“Configure” & “Pixel format”), which open dialogs containing options to select between RGB / YUV / YV12 / YUY2... Having only a vague understanding of these notions (it's improving but slowly) it's quite confusing. In all my tests earlier, “Mode” was set to “RGB (default)” in “Configure”, and I changed the setting in “Pixel format”, so my observations are indeed consistent with what you're stating here. And it's weird indeed – why is there such a setting if it does nothing ? And so is it a specific Lagarith issue ?

You can probably salvage it by deciding how you want it to look and render it out like that. Adjust footage to match (709<=>601 is "easy" in the sense that there are established ways). Plan ahead for the path of least resistance. Try to salvage as much as prior work as you can. Then import the footage into a proper editor

I could also decide that noone else will see the difference, but the need to control is... beyond my control... And I've spent too much time on this to be satisfied with an end result plagued by that kind of defect. Anyway, there's not much of the original footage left “active” in the current state of the project, I might as well convert everything as lossless intermediates with Avisynth to control the colorspace conversion, including those parts which don't need any pre-processing, but that's a rather clunky workaround, not a proper solution. As for “proper editor”, do you know one which doesn't have any issue ? You mentioned yourself that even the almighthy Adobe released troublesome products for a long time...

[poisondeathray]

Any control over the decoding pathway ? Does the m2ts use internal decoder ? or rely on external/system codec

There's a long list of import modules, each can be selected or not :

m2ts isn't explicitly listed, but I suspect it would fall under "MPEG import module"

It would probably a lot of testing runs, to learn what your software is actually doing, how it's decoding, where the conversions are actually occurring. Not sure if you want to spend the time at this point

why is there such a setting if it does nothing ? And so is it a specific Lagarith issue ?

It's been like that forever. As long as I can remember using lagarith. I don't know why. It's just one of the quirks.

It's different for most other codecs. Typically if you select RGB, most codecs will convert to RGB with 601 if YUV data was sent

Also in older versions of vdub (origial vdub) , if you didn't explicitly select video=>fast recompress, it would convert YUV input to RGB using 601 as well . (The default was full processing mode which always converted YUV to RGB with 601)

I could also decide that noone else will see the difference, but the need to control is... beyond my control... And I've spent too much time on this to be satisfied with an end result plagued by that kind of defect. Anyway, there's not much of the original footage left “active” in the current state of the project, I might as well convert everything as lossless intermediates with Avisynth to control the colorspace conversion, including those parts which don't need any pre-processing, but that's a rather clunky workaround, not a proper solution. As for “proper editor”, do you know one which doesn't have any issue ? You mentioned yourself that even the almighthy Adobe released troublesome products for a long time...

It was more of a joke hence the smiley. But seriously every software has quirks and issues, and various workarounds that are needed. (Adobe PP has fixed most of the nagging issues and big deal breakers; but it's been around for a long time it should have reached this state years ago.)

For me - I always do some small end to end tests (with any software) before I commit any real time to a project. I learned the hard way that every software has quirks, and sometimes you have to learn by making mistakes or the "gotchas" . Little bugs and things like: lagarith behaves this way, or the editor handles this type of colorspace this way etc.. etc.. aren't always listed in the manual or instructions. So I check every step, every stage and verify. That extra time testing and learning quirks of a new workflow or software at the beginning of a project, will save you lots of headache later. Trust me, even if you "waste" a few hours, it will be worth it.


In 2018 - I don't know how any editor can get native HD camera files "wrong colors" . Seriously. It was excusable during early HD days, like a decade ago. But not now. Adobe CS4 was guilty of this too (2008)

[abolibibelot]

a) Copy the m2ts to a different location (without any of the preexisting accessory .H0 files or whatever), rename the file as well, then test

This I did several times, wrong Rec601 colors in any case.

b) Rewrap to a different container, say MP4, and rename the file and move location for good measure , then test

Converted the test M2TS file to MP4 with ffmpeg -c copy, then imported into MVD, result is kinda funky :

Actually the first 15 frames are displayed correctly, while the framerate is reported (incorrectly) as 14.99 FPS (MediaInfo says 29.97). More weirdness...
MP4 created with mp4box : appears corrupted too but differently : many black frames with a few patches of pixels in the upper border, and the very first frame duplicated every 18 frames...

mp4box -add "G:\20131224 M2TS\20151226_111341.m2ts" -new "H:\20151224 Avisynth\20151226_111341.mp4"
Unknown registration descriptor HDMV
[MPEG-2 TS] Stream type (0x90) for PID 4608 not supported
Importing MPEG-2 TS (PID 4113)
Unknown registration descriptor HDMV
[MPEG-2 TS] Stream type (0x90) for PID 4608 not supported
MPEG-4 AVC/H264 Video import (TS PID 4113)
Movie timescale (600) not precise enough to store edit (media timescale: 90000)
Timeline offset: 0 ms
Importing MPEG-2 TS (PID 4352)
Unknown registration descriptor HDMV                 | (00/100)
[MPEG-2 TS] Stream type (0x90) for PID 4608 not supported
Dolby AC3 Audio import - SampleRate 48000 Channels 2 Language  (TS PID 4352)
Timeline offset: 0 ms
Saving H:\20151224 Avisynth\20151226_111341.mp4: 0.500 secs Interleaving

EDIT : VLC can play the ffmpeg-converted file properly, but the mp4box-converted file appears very weird ; same for SMPlayer.
MKV (created with MKVMerge) : do not want (can't import).

If it was 4:2:0 lagarith, you would expect wrong colors , because most programs would be using Rec601 by default to convert back to RGB for the display (and/or timeline)

For that file MediaInfo says : YUV 4:2:0. If I remember correctly, it was indeed the opposite a year ago, I had wrong colors with YUV Lagarith, which is why I created that other thread in the first place... Hard to be 100% sure... (Well, I still have my older SSD, which I haven't used since I migrated the system to a NVMe thingy this summer – which itself seems to have caused some unexpected issues (*) –, before I messed with the system codecs, so I could try booting from it and see how MVD behaves there... for the sake of science... if I really have nothing better to do at this time of the year...)
When I check (in MVD's timeline) the properties of the movie object for that file (and AVI lossless files in general) there's an extra “metadata” tab which says :
FCC .............. LAGS
Decoder ....... AVI Decompressor
Colorspace ... RGB24
Stereo3D ..... Standard (2D)
In the “general informations” tab, “import module” is reported as “AVI Import module”. For M2TS and MP4, it's “MPEG Import module” (and there's no “metadata” third tab).

Is default system lagarith decoder official , or lav , currently ?

I'm not sure where to look for that information...
In ffdshow video decoder configuration, Lagarith is not listed (Huffyuv is for instance).
In LAV Video Decoder settings, Lagarith is disabled (before I disabled it Lagarith files were displayed incorrectly in MVD ; I also removed “avi” in LAV Splitter settings, don't know which one did the trick).
In GraphStudioNext, the decoding path appears as :
[file.avi] => “AVI Splitter” => “AVI Decompressor” => “Color Space Converter” => “Video Renderer”
For a M2TS file, video goes straight to “ffdshow Video Decoder”, then “Video Renderer”


(*) Since then I upgraded Intel storage drivers : I definitely have less crashes, but still more than before, and the wake-up time from hibernation is still abnormally high (>5min.).

[poisondeathray]

For the re-wrap to MP4 testing , another approach is to demux it first (e.g. tsmuxer) then mux the elementary streams with mp4box. But some editors don't like AC3 audio in MP4 . I suspect even if it worked, the colors would be "wrong"


For most windows editors, they will actually be using VFW for AVI imports using 3rd party codecs, such as lagarith. So if you recall the vdub file=>file information exercise ? That will report which VFW decoder is being used. Make sure the AVI driver is selected in the import dialog box for "files of type" . Use x64 if your MVD is x64, x86 if MVD is x86.

[abolibibelot]

(Another system crash later... )

Wait... I've got sumthin'... In MVD's program parameters, in the display options tab, the “video mode” option was set to “Alternative mode 2 (Video Mixing Renderer 9)” ; if I change this to either “Compatibility mode (VideoForWindows)” or “Default mode (hardware acceleration, Direct3D)”, the M2TS (newly imported in a new project) is displayed with the correct colors. And the default mode also fixes the stabilizer issue : now I can reshape the analysis area. I feel like Chuck Norris killing two stones with one bird.




But I found a screenshot I made on December 24th 2017 (looks like I had nothing better to do that day either) which says that the correct functionality of the “GammaHDR” feature, which was broken and displayed wonky results with the default mode, was restored precisely by switching to that “Alternative mode 2” – and indeed that's still the case. The compatibility mode shows a correct aspect with the Gamma HDR feature, but doesn't allow the normal interaction with the stabilization module.

(Gamma HDR applied with video mode = default / Direct3D)
So both features can't be used normally at the same time (at least on my current system – the Gamma HDR feature probably worked normally with the default settings on my former computer, or I would have noticed it earlier), or one has to switch the “video mode” when using one or the other. Normally it shouldn't affect the actual rendering, right ? Do you happen to know the differences between those three modes, and have an explanation or at least a hypothesis for their respective effects with regards to color reproduction and interaction with a video overlay ?

What I haven't tried before is exporting a file right after it's been imported, with either of those options. If I understand this correctly, this setting only controls the display aspect, so the output should be the same, right ?
I just tried exporting in Lagarith RGB from MVD : indeed, the colors are correct (when played in VLC) for all three modes, even the “alternative mode” which results in MVD's own player displaying wrong Rec601 colors.

For the re-wrap to MP4 testing , another approach is to demux it first (e.g. tsmuxer) then mux the elementary streams with mp4box. But some editors don't like AC3 audio in MP4 . I suspect even if it worked, the colors would be "wrong"

Yes, I should have remembered that AC3 is not standard in MP4...
But if re-encoding the audio to AAC with ffmpeg, the display is still abnormal in MVD.
TSMuxer says : “Frame rate: 59.9401 (pulldown)”, although it's supposed to be 29.97 FPS. If I demux with TSMuxer and convert to MP4 with the AC3 transcoded as AAC, same result when imported into MVD. Interestingly ffmpeg also reports the framerate as 59.94 :

ffmpeg -i "H:\20151224 Avisynth\20151226_111341.track_4113.264" -i "H:\20151224 Avisynth\20151226_111341.track_4352.ac3" -c:v copy -c:a aac "H:\20151224 Avisynth\20151226_111341 TSMuxer ffmpeg aac.mp4"
ffmpeg version N-92266-gbf324359be Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 8.2.1 (GCC) 20181017
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enabl
e-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amr
wb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enab
le-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --
enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc -
-enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --e
nable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
  libavutil      56. 20.100 / 56. 20.100
  libavcodec     58. 33.102 / 58. 33.102
  libavformat    58. 19.102 / 58. 19.102
  libavdevice    58.  4.106 / 58.  4.106
  libavfilter     7. 37.100 /  7. 37.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Input #0, h264, from 'H:\20151224 Avisynth\20151226_111341.track_4113.264':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: h264 (High), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], 59.94 fps, 59.94 tbr, 1200k
tbn, 119.88 tbc
[ac3 @ 00000000031d0dc0] Estimating duration from bitrate, this may be inaccurate
Input #1, ac3, from 'H:\20151224 Avisynth\20151226_111341.track_4352.ac3':
  Duration: 00:00:58.56, start: 0.000000, bitrate: 192 kb/s
    Stream #1:0: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #1:0 -> #0:1 (ac3 (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, mp4, to 'H:\20151224 Avisynth\20151226_111341 TSMuxer ffmpeg aac.mp4':
  Metadata:
    encoder         : Lavf58.19.102
    Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], q=2-31,
59.94 fps, 59.94 tbr, 1200k tbn, 1200k tbc
    Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s
    Metadata:
      encoder         : Lavc58.33.102 aac
[mp4 @ 0000000002fe67c0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the
future. Fix your code to set the timestamps properly
frame= 1755 fps=0.0 q=-1.0 Lsize=   56682kB time=00:00:58.57 bitrate=7927.6kbits/s speed=77.7x
video:55698kB audio:922kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.109521%
[aac @ 000000000043f900] Qavg: 336.998

For most windows editors, they will actually be using VFW for AVI imports using 3rd party codecs, such as lagarith. So if you recall the vdub file=>file information exercise ? That will report which VFW decoder is being used. Make sure the AVI driver is selected in the import dialog box for "files of type" . Use x64 if your MVD is x64, x86 if MVD is x86.

Oh, right. For both x86 and x64 VirtualDub2, AVI Information says :
“Decompressor: Lagarith Lossless Codec (LAGS)”

[poisondeathray]

In MVD's program parameters, in the display options tab, the “video mode” option was set to “Alternative mode 2 (Video Mixing Renderer 9)” ; if I change this to either “Compatibility mode (VideoForWindows)” or “Default mode (hardware acceleration, Direct3D)”, the M2TS (newly imported in a new project) is displayed with the correct colors. And the default mode also fixes the stabilizer issue : now I can reshape the analysis area.
.
.
So both features can't be used normally at the same time (at least on my current system – the Gamma HDR feature probably worked normally with the default settings on my former computer, or I would have noticed it earlier), or one has to switch the “video mode” when using one or the other. Normally it shouldn't affect the actual rendering, right ? Do you happen to know the differences between those three modes, and have an explanation or at least a hypothesis for their respective effects with regards to color reproduction and interaction with a video overlay ?

What I haven't tried before is exporting a file right after it's been imported, with either of those options. If I understand this correctly, this setting only controls the display aspect, so the output should be the same, right ?

What I haven't tried before is exporting a file right after it's been imported, with either of those options. If I understand this correctly, this setting only controls the display aspect, so the output should be the same, right ?
I just tried exporting in Lagarith RGB from MVD : indeed, the colors are correct (when played in VLC) for all three modes, even the “alternative mode” which results in MVD's own player displaying wrong Rec601 colors.

The renderer affects how things are displayed, and in many cases, how the RGB conversion is done. You can can get completely different colors, levels, with different renderers . Some are GPU accelerated, some are CPU only. GPU ones can tricky , because the GPU drivers and settings also play a role.

You can "play" with different renderers in MPCHC for example (or any video player), and see how it can produce different results . Of course there it doesn't affect the underlying video. In your video editor, I don't know. I suspect it does in your case; because you have to be able to "see what you get" in order to make color corrections, etc. But some video editors have multiple display configurations; one can be set display a certain way, one can have a viewing LUT to display another etc... and those can be set to only displays; ie not affecting the video. So I would do some quick tests to verify (and not rely on VLC only , because some media players do not display RGB formats correctly; some actually go back to 4:2:2 with 601, then back to RGB, causing a color shift again)

But at least you have more understanding of how MVD works, and that's some progress... This is exactly what I meant about doing some test runs to learn that particular software's various quirks. The manual won't have this type of information spelled out

[abolibibelot]

You can "play" with different renderers in MPCHC for example (or any video player), and see how it can produce different results . Of course there it doesn't affect the underlying video. In your video editor, I don't know. I suspect it does in your case; because you have to be able to "see what you get" in order to make color corrections, etc.

Tested exporting a short video with Gamma HDR applied in “default” video mode : although it looks garbled when editing, as soon as the rendering begins it shows the normal aspect in the preview window, then goes back to garbled once it's finished. So it doesn't respect the “see what you get” rule in this case, but does somehow “land on its feet” at the rendering stage. Could it be due to some parameter of the graphic driver, which would be automatically disabled when exporting a video ?

(Default video mode, Gamma HDR applied – looks normal when rendering / exporting a video)

But some video editors have multiple display configurations; one can be set display a certain way, one can have a viewing LUT to display another etc... and those can be set to only displays; ie not affecting the video. So I would do some quick tests to verify (and not rely on VLC only , because some media players do not display RGB formats correctly; some actually go back to 4:2:2 with 601, then back to RGB, causing a color shift again)

Why is the world so complicated... é_è Do you have a professional training, or did you learn all that in autodidact mode, by painstaking trial-and-error ?
And so what can be used to test those things reliably ? Avisynth / AVSPMod again ?

But at least you have more understanding of how MVD works, and that's some progress... This is exactly what I meant about doing some test runs to learn that particular software's various quirks. The manual won't have this type of information spelled out

There's not even a single mention of colorspace, Rec601 / Rec709, etc. in the integrated help...

And no, the Magix forum wasn't of much help... é_è

(To be fair, I got this when I typed a wrong link, then when doing a research properly with “colorspace” or “wrong colors” I got a few hits although none was relevant – but I've started collecting peculiar “Error 404” pages, and this one is among the most hilarious I've found... When I was 8 years old I was collecting minerals, and dreamed of having one piece of every single species of mineral in the world – damn, my ambitions have seriously dwindled...
“For the child enamoured with world maps and drawings
Universe is equal to his large appetite.
Ah ! the world looks so big when viewed under a lamp
But in the memories, how small it really is.” – Charles Baudelaire)

[poisondeathray]

Tested exporting a short video with Gamma HDR applied in “default” video mode : although it looks garbled when editing, as soon as the rendering begins it shows the normal aspect in the preview window, then goes back to garbled once it's finished. So it doesn't respect the “see what you get” rule in this case, but does somehow “land on its feet” at the rendering stage. Could it be due to some parameter of the graphic driver, which would be automatically disabled when exporting a video ?

I don't know... you'd have to keep on doing tests/observations and make notes

But some video editors have multiple display configurations; one can be set display a certain way, one can have a viewing LUT to display another etc... and those can be set to only displays; ie not affecting the video. So I would do some quick tests to verify (and not rely on VLC only , because some media players do not display RGB formats correctly; some actually go back to 4:2:2 with 601, then back to RGB, causing a color shift again)

Why is the world so complicated... é_è Do you have a professional training, or did you learn all that in autodidact mode, by painstaking trial-and-error ?
And so what can be used to test those things reliably ? Avisynth / AVSPMod again ?

All of the above ; and you better believe it's way more complicated than 601/709 only. 2020, STMPE ST 2084/HDR are becoming prevalent - and there are major headaches and growing pains with the latter because it's "new". Just like 10 years ago "709" was "new" with it's own growing pains

Acquistion isn't so simple beyond consumer world; there are way more than Rec601/709/2020. You might shoot in various logarithmic modes for example, for higher dynamic range. Pro cameras have dozens of acquisition modes that have corresponding LUTs that "map" to various output targets.

A video editor's working space is not necessarily the same as an asset's acquisition colorspace. Also the display you are using most likely is sRGB , 8 or 10bit. A colorist might be using DCI, or Adobe RGB, or wide gamut, or something else. The "quick" transforms typically used are technical viewing LUTs ; basically they "map" one thing to another for a quick preview . But that isn't necessarily what is actually being used "underneath" in the actual working space; it's just a preview. You might have multiple targets that require different "mapping." e.g. something for film out requires 12bit XYZ, but HD would require 8 or 10bit 709, the HDR version would require ST 2084, etc...

eg. So if you shot in LogC , you might use a viewing LogC to transform to sRGB/709 - so you can "see" it. Otherwise the colors would be messed up if you view logC data on a sRGB display natively. If you look at a HDR 10bit UHD HDR blu-ray - same thing; it has to be tone mapped down if viewing on a 8bit sRGB display