Have we had DVD colors wrong this whole time?

[flossy_cake]

Also I was thinking about remastered versions of shows, they change the colour grading so it's not really a "ground truth" per se. The ground truth would be what the creators signed off on back when the show was first produced. Still, I think there are reference colours that the remastered versions colourist targets like the red of Picard's suit is a known colour and the yellow of the Simpsons skin is a reference colour that they target for the remastered Simpsons even though other colours and white balance may be different the yellow is still a reference point of what shade of yellow it should be

[flossy_cake]

MadVR's saturation control appears to work differently to Avisynth's one - the former seems to preserve perceptual luminance while the latter is just your traditional multiplier on the chroma channels, which is how the Colour control on a TV typically works.

Comparison
https://imgsli.com/NDAwMjc5
https://imgsli.com/NDAwMjg5
https://imgsli.com/NDAwMjkw

With the Avisynth example above we're basically just looking at the Y channel, which isn't linked to the perceptual brightness of colours.

I think Avisynth's chroma multiplier might be more in line with how 1990's equipment would be used to correct NTSC chroma issues back then. Coincidentally the results on actual images look better to me in these examples below.

So here I have picked the worst scene I could find from season 1 of each series where the main character's face appears pushed when decoded with 470M, and desaturated it to 90% with the Avisynth's Tweak() filter.

TNG S01E05 Where No One Has Gone Before 12:00
https://imgsli.com/NDAwMjgw

DS9 S01E12 Vortex 30:30
https://imgsli.com/NDAwMjgx

Voyager S01E11 Heroes and Demons 36:33
https://imgsli.com/NDAwMjgz

Also I read 470M uses YIQ instead of YUV and the "I" channel encodes orange-teal axis so maybe we could look at just doing a multiplier on the I-channel since the oranges and teals are what seem to pop the most with 470M decoding.

The Avisynth article gives a tutorial on that but I need more time to figure it out: http://avisynth.nl/index.php/Tweak#YUV_to_YIQ_conversion

[flossy_cake]

Alright let's play a game. I've randomly taken 10 screenshots, a few from each of the 3 series, and you've got to guess which gamut I used to decode each one (either 170M or 470M). Or alternatively just say whether you think the image was decoded with the "right" gamut or the "wrong" one. No colour corrections were performed. Good luck and don't cheat!

https://c.l3n.co/i/D5SuCZ.png
https://d.l3n.co/i/D5SDzP.png
https://a.l3n.co/i/D5SNwm.png
https://b.l3n.co/i/D5Sf1i.png
https://a.l3n.co/i/D5SFKo.png
https://b.l3n.co/i/D5SUf9.png
https://a.l3n.co/i/D5SX02.png
https://c.l3n.co/i/D5Sbqv.png
https://a.l3n.co/i/D5SwYC.png
https://c.l3n.co/i/D5Sxh5.png

edit: btw I didn't include any pilot episodes as those are notorious for having mastering errors, not just with Star Trek but in general with older shows

[flossy_cake]

Here is a comparison of what I'm getting with MadVR's 470M decoding vs the same frame in OP's 470M decode, which I presume was done with ffmpeg's zscale?

https://imgsli.com/NDAwNDAx

But I don't think it's a valid comparison, because even when both are 170M, the video levels don't match between my copy and OP's. I seem to recall reading a thread a while ago about how VLC mucks up the gamma and brightens it by 0.2 or something like that, I forgot the details. So if OP took the screenshot in VLC maybe that's it. Or, it could be the encoder of the copy I've got put a contrast curve on it (I doubt it, but I'm aware there are groups like UTR which do that and it's a big no-no in my books). edit: have checked 2 encodes from separate groups (one is QxR who doesn't muck with the levels) and they both have the same levels so it's not my copy that is defective I don't think. Probably something went wrong with the application generating the screenshot.

[flossy_cake]

By the way, because of OP's discovery of 470M I now plan on buying the region 1 NTSC DVDs. The colours are so much better at 470M it really transforms the show and makes it worth purchasing to me. The colours seem magical at times, it's almost like 470M has it's own signature "look and feel" to it or something, I really dig it.

[flossy_cake]

But I don't think it's a valid comparison, because even when both are 170M, the video levels don't match between my copy and OP's.

Ah but in the TNG example in OP the 170M decodes DO match, so we should now be able to see the difference between OP's (zscale?) 470M decode vs MadVR's 470M decode:

https://imgsli.com/NDAwNDE0

edit: for better visualisation on mobile devices here's just the 470M bit
https://imgsli.com/NDAwNDE1

[huhn]

Here is a comparison of what I'm getting with MadVR's 470M decoding vs the same frame in OP's 470M decode, which I presume was done with ffmpeg's zscale?

https://imgsli.com/NDAwNDAx

But I don't think it's a valid comparison, because even when both are 170M, the video levels don't match between my copy and OP's. I seem to recall reading a thread a while ago about how VLC mucks up the gamma and brightens it by 0.2 or something like that, I forgot the details. So if OP took the screenshot in VLC maybe that's it. Or, it could be the encoder of the copy I've got put a contrast curve on it (I doubt it, but I'm aware there are groups like UTR which do that and it's a big no-no in my books). edit: have checked 2 encodes from separate groups (one is QxR who doesn't muck with the levels) and they both have the same levels so it's not my copy that is defective I don't think. Probably something went wrong with the application generating the screenshot.
vlc has a history... and even mpv has issue with screenshoot meta data. microsoft doesn't make this easy...

even madVR does this wrong you have to define bt 709 to even have a chance of accurate dvd playback and mpc-hc writes meta data that is interpreted by microsoft as "do nothing this is fine" while objectively been wrong but getting the correct result(please don't change this).

the madVR screen is also far more feasible then what ever the zscale image is but again no source so what ever now.

[DS9Redefined]

Thanks for continuing to investigate this!

A note, I haven't decoded DS9 season 1 with zscale (yet). Those from the LaserDiscs, with ld-chroma-decoder's chroma gain set to 1.25, subjected to however After Effects interpreted it, with the HD upscale version treated with Lumetri, with shadows at +25 and saturation at 115. It gets surprisingly close to 470m but without the chroma shifting.

I loaded up the DVD with Emissary, and it says:

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 4
dwPictAspectRatioY: 3
dwControlFlags: 0x2a0d2581
- VideoChromaSubsampling: 5 (MPEG-2)
- NominalRange : 2 (16-235)
- VideoTransferMatrix : 2 (BT.601)
- VideoLighting : 3 (dim)
- VideoPrimaries : 8 (SMPTE C)
- VideoTransferFunction : 5 (BT.709)
dwReserved2: 0x00000000

So... that's interesting!

[Sunspark]

MadVR's saturation control appears to work differently to Avisynth's one - the former seems to preserve perceptual luminance while the latter is just your traditional multiplier on the chroma channels, which is how the Colour control on a TV typically works.

Comparison

I took a look at these.. as there is a true difference between convert to greyscale and desaturate (especially with colours like yellow) and as I have a hotkey defined to switch into greyscale (not desaturate) it makes it easy for me to look at the original bars and see which of the two between madvr and avisynth is closer to a greyscale conversion.

avisynth's desaturate is closer to greyscale/more accurate than madvr is. It's not perfect, because it's not actually a conversion so there's differences but yeah, avisynth is the better one of the two here.

To try it out for yourself, go to Windows colour filters in the control panel, set it to greyscale and turn on the checkbox for the hotkey ctrl-windows-c which will allow you to easily toggle it on and off.

[Sunspark]

Alright let's play a game. I've randomly taken 10 screenshots, a few from each of the 3 series, and you've got to guess which gamut I used to decode each one (either 170M or 470M). Or alternatively just say whether you think the image was decoded with the "right" gamut or the "wrong" one. No colour corrections were performed. Good luck and don't cheat!

edit: btw I didn't include any pilot episodes as those are notorious for having mastering errors, not just with Star Trek but in general with older shows

Ok I'll play.

https://c.l3n.co/i/D5SuCZ.png 170
https://d.l3n.co/i/D5SDzP.png 470
https://a.l3n.co/i/D5SNwm.png 170
https://b.l3n.co/i/D5Sf1i.png 470, correct
https://a.l3n.co/i/D5SFKo.png 170
https://b.l3n.co/i/D5SUf9.png 470, correct
https://a.l3n.co/i/D5SX02.png 470, incorrect
https://c.l3n.co/i/D5Sbqv.png 170
https://a.l3n.co/i/D5SwYC.png 470
https://c.l3n.co/i/D5Sxh5.png 470

[Sunspark]

I seem to recall reading a thread a while ago about how VLC mucks up the gamma and brightens it by 0.2 or something like that, I forgot the details.

This highly depends. On my Linux device I have VLC set up as the primary player partly because of audio filters but using OpenGL for video output (you can do this in Windows too). If you go into advanced settings>video>output>opengl then you have a variety of options that can be changed. 4 different rendering intents, 10 different display primaries, 10 different display gamma/transfer functions, 6 different tone-mapping algos (this works on SDR too) along with values you can set, 4 different dithering algos along with the values you can set.

If you want to try my values from what I set in Linux where I don't have colour management set up or any profile, and my monitor is straight sRGB, you will get decent output with these settings on (modern content, not the old stuff we're talking about here).

Rendering intent: Relative
Display primaries: BT.709
Display gamma: Unknown (yes, it makes a difference setting unknown)
Tone-mapping: Mobius
Tone-mapping parameter: 0.30
Dithering: Bayer
Dither depth override: 0
Tone-mapping desaturation coefficient 0.70

My monitor's panel is set to 1.8 gamma, and the desktop is at default 1.00, so you may need to set a value of display gamma instead of Unknown if it's too dark on your display, but there are 10 to choose from.

So maybe the default settings aren't right, but if you just change it to opengl, then you can change all this stuff similar to madvr.

If you use software scaling mode instead then there are 10 different scaling filters you can set, but that's not recommended by me because it hits the CPU, so just let opengl use its scalers but you can set all the rest as I listed.

[huhn]

you just said that your display is straight sRGB so it is approximated 2.22 which looks very different from 2.22 and then you say it is set to 1.8 so it has nothing to do with sRGB because the only difference between sRGB and bt 709 is the transfer function. and if the display would be even remotely accurate it 1.8 would make it look matt like a display with absolutely no CR at all.

if you need to change that to get a screenshoot with untouched SDR transfer function it failed as a video renderer.

[flossy_cake]

Ok I'll play.

https://c.l3n.co/i/D5SuCZ.png 170
https://d.l3n.co/i/D5SDzP.png 470
https://a.l3n.co/i/D5SNwm.png 170
https://b.l3n.co/i/D5Sf1i.png 470, correct
https://a.l3n.co/i/D5SFKo.png 170
https://b.l3n.co/i/D5SUf9.png 470, correct
https://a.l3n.co/i/D5SX02.png 470, incorrect
https://c.l3n.co/i/D5Sbqv.png 170
https://a.l3n.co/i/D5SwYC.png 470
https://c.l3n.co/i/D5Sxh5.png 470

You got most of them right, and I'll give others a chance to place their guess before revealing the answers :D

[flossy_cake]

I compared Avisynth's z_ConvertFormat (http://avisynth.nl/index.php/Avsresize) doing the 470M>709 conversion vs MadVR's 470M>709 conversion... seems to be slightly different, but not massively

https://imgsli.com/NDAwNTUz

[flossy_cake]

Thanks for continuing to investigate this!

A note, I haven't decoded DS9 season 1 with zscale (yet). Those from the LaserDiscs, with ld-chroma-decoder's chroma gain set to 1.25, subjected to however After Effects interpreted it, with the HD upscale version treated with Lumetri, with shadows at +25 and saturation at 115. It gets surprisingly close to 470m but without the chroma shifting.

I loaded up the DVD with Emissary, and it says:



So... that's interesting!

Thanks for clearing that up

[Sunspark]

you just said that your display is straight sRGB so it is approximated 2.22 which looks very different from 2.22 and then you say it is set to 1.8 so it has nothing to do with sRGB because the only difference between sRGB and bt 709 is the transfer function. and if the display would be even remotely accurate it 1.8 would make it look matt like a display with absolutely no CR at all.

if you need to change that to get a screenshoot with untouched SDR transfer function it failed as a video renderer.

I know this sounds wrong, but the reason I have to do this is because even though software like f.lux claims it has 100% srgb coverage, if I have it at PC then I find everything a bit too dark.. I need the mid-tones boosted up a bit. With madvr I compensate for this. I do have the calibration set to 1.8 in there, but on gamma processing I have it at 1.85 to darken it a touch. It does seem to be close enough to 2.2. Videos aren't blown out or crushed. Very ad-hoc I know, but the output is fine. One of these days I will get a calibrator. I have an ancient spyder colourimeter but I don't think it's worth using because it's already probably 20 years old and these things wear out.

[huhn]

sorry but if you have a gamma or select a gamma in a display you don't have sRGB because that's the difference between bt 709 and sRGB sRGB doesn't use a gamma curve.

[huhn]

it is 2.4 after a linear part it is not a gamma curve.
there is also bt 709 transfer which is similar using 2.2 and again is not a gamma curve.

[flossy_cake]

@huhn are you gonna guess on my screenshots?

[huhn]

i do not know the source material so no.

[flossy_cake]

i do not know the source material so no.

That's the problem - we don't know the gamut of the source material, we are forced to guess. A blind test is useful because it takes bias out of the equation. If I told you they were all 470M would you believe me?

[huhn]

except for 1 i was under that assumption.

[flossy_cake]

except for 1 i was under that assumption.

But how can you assume it if you don't know the source material?

[huhn]

because they all have burned sun face syndrome just on 8(looks completely fake)
and yes i can not guess correctly because maybe they are all supposed to be sunburn victims. this is some kind of space stuff.

[flossy_cake]

because they all have burned sun face syndrome just on 8(looks completely fake)
and yes i can not guess correctly because maybe they are all supposed to be sunburn victims. this is some kind of space stuff.

They don't look sunburned on my calibrated S90D at all, the hue and saturation is correct, the scene lighting looks correct to me. It looks like it is revealing the truth that was hidden the whole time. Decoding with 170M looks completely wrong, green hues everywhere, all actors faces sickly and pale. But that's how all Hollyweird movies look these days so that's probably what seems normal to most. Don't be afraid of a bit of colour, it won't kill ya. I challenge you to watch S01E01 of Deep Space Nine at 470M.

[huhn]

i recommend to you again to stop using de 00 and use itp on such a display.

[flossy_cake]

i recommend to you again to stop using de 00 and use itp on such a display.

I would recommend you stop using itp or de and instead just target xyY as closely as possible. Neither de or itp says anything about what direction of error is subjectively better or worse, it's like a radar gun that doesn't say whether you were 10kph over or under the speed limit, only that it was a difference of 10 from the target. What meter do you use and is it profiled?

[huhn]

i have a s90c that's why i tell you that this thing comes out of the box pretty much with a de 00 below 2 and it is still very very inaccurate.

it's i1d3 profiled by the same c-200 as yours.
don't tell me about xyY if you are the person that said his device is calibrated below de 00 of 2.

[flossy_cake]

don't tell me about xyY if you are the person that said his device is calibrated below de 00 of 2.

I only mentioned DE because I thought other people value it. ITP is for HDR / wide gamut so it's not very relevant here. All of these delta models suffer from the same problem where they say nothing about which direction of error is more subjectively pleasing. Is a green skin tone more preferable to a magenta one? Is it better to be undersaturated or oversaturated? Is it better for gamma to be too low or too high? At what stimulus level? etc. That's why telling you my delta-xyY is not useful either, because I would still have to justify why I allowed the error to go in one direction rather than the other, and you would be under no obligation to agree with me. I don't know what your preference is so all I can say is to target xyY as close as possible and the direction of error I leave up to you.

[flossy_cake]

I compared Avisynth's z_ConvertFormat (http://avisynth.nl/index.php/Avsresize) doing the 470M>709 conversion vs MadVR's 470M>709 conversion... seems to be slightly different, but not massively

https://imgsli.com/NDAwNTUz

Found the reason... z_ConvertFormat doesn't change the white point to 470M's more magenta white balance of x=0.310 y=0.316.

https://imgsli.com/NDAxMTQ1


# grayscale
Tweak(sat=0.0)

# decode the source as 470m and convert it to 709
z_ConvertFormat(
\ pixel_type="YV12", /* output pixel type YV12 = YCbCr 4:2:0, same as source */
\ colorspace_op="601:601:470m:limited=>709:709:709:limited",
\ dither_type="ordered")
\ .Prefetch(1) /* put it in its own thread for better performance */

LanczosResize(1440,1080)

__END__

[flossy_cake]

If they were mastered as 170M inside a 470M container, then we should see on histogram or vectorscope the red and green values hardclipping above a certain value. Avisynth has histogram filter so I will do some investigation http://avisynth.nl/index.php/Histogram

[flossy_cake]

If they were mastered as 170M inside a 470M container, then we should see on histogram or vectorscope the red and green values hardclipping above a certain value. Avisynth has histogram filter so I will do some investigation http://avisynth.nl/index.php/Histogram

I tried all the histogram modes and sadly none of them can actually plot saturation, only the stimulus of the RGB or YUV channels individually, which is not the same as saturation.

The documentation for the 2 vectorscope modes (color and color2) claims to plot saturation but it actually doesn't - a red luminance sweep and a red saturation sweep create the same pattern of dots on the graph going from the edge to the center. That is by design, so we need some more advanced tools like maybe commercial product like Davinci Resolve might have a saturation histogram. Or maybe there is some way to do it in Avisynth by converting the pixel values to HSL and histogramming the S channel.

So currently I am limited to just taking screenshots of scenes where there are bright green or red objects in the scene and looking at the pixel values in photoshop to see if they are fully saturated, but this is a time consuming thing.

[flossy_cake]

I guess it's not really definitive anyway since the colour grading could be such that for example there are no greens above 75% saturation on any scene. The green lights that appear in the background of many DS9 scenes aren't necessarily supposed to be 100% saturated. So maybe I won't pursue that investigation anymore. I suppose if I had a CIE chart histogram and could scrub around to various scenes with saturated highlights and they all just happen to land on the edges of the 170M triangle which sits inside the 470M triangle, then that could be a "tell".

[flossy_cake]

Will the real Dax please stand up

https://d.l3n.co/i/NjT5rc.png

On the left she looks a little pale and green, like she ate some bad food and is about to hurl,
or is being illuminated by low CRI LED bulbs.

On the right the colours are popping, perhaps even a bit too much for something so old and
analogue. The lights in the background are hued green instead of lime, which seems more
"correct" to me. This complements and contrasts against the more saturated and orange
hued skin tone and those signature 470M teals on her suit.

The weird thing is if I stare long enough at the pale and green Dax, my eyes adjust and it
starts to look more reasonable. But the same happens for 470M - the longer I look at it the
less saturated it looks. Even that "orange juice" image of Picard starts to look normal to me
after 30 seconds of starting at it. Cone fatigue?

edit: slider https://imgsli.com/NDAyMTk4

[Sunspark]

Interesting. Right side has good saturation (a touch too much though) but needs the blues and greens dialed down a tad. Left side is ok but is desaturated on the reds, needs a push up and needs less green too.

You can see what the blue is supposed to look like with this promo photo of Dr. Crusher that I put up earlier in https://forum.doom9.org/showthread.php?p=2020733#post2020733

I was able to play with the right side on my monitor a bit. Switching it into video mode instead of graphics, preset "Movie" then raising the hue to 62 and lowering the saturation to 45 puts the tunic mostly back to blue and looks pretty ok. Easier to work with the right side than the left. I don't use video mode though, that's mostly meant for TV/DVD usage.

What algorithm are you using for chroma here? There are some I don't like because they put too much saturation in. If it pleases you to, take a look at the right side with Mitchell-Netravali AR and see if it is the same. I think you will find it is not as pushed.

[flossy_cake]

What algorithm are you using for chroma here? There are some I don't like because they put too much saturation in. If it pleases you to, take a look at the right side with Mitchell-Netravali AR and see if it is the same. I think you will find it is not as pushed.

I'm using "bilateral old" for chroma cause I like its strong antialiasing properties

I think I will stop posting screenshot comparisons because I don't think they're necessarily valid. It's almost impossible to explain but it's to do with the "simultaneous contrast" effect and cone fatigue which can set in after 30 seconds. I think the only valid test is to actually screen the episode in FULL SCREEN in a DIM SURROUND on a display that doesn't have major colour flaws. Looking at images side by side on a white forum background on a PC monitor during the day, or a phone , or even just A-B'ing the difference imbues simultaneous contrast effect. Even just looking at the other image we're setting up a "simultaneous contrast" effect with the other image.

Basically I think the only way to properly evaluate the colour is to just look at the image in question, and only the image in question, under controlled environment. But even then, cone fatigue can set in after 30 seconds of pausing on a scene, so you can't even pause it you have to play it continuously. I'm worried that colourists sitting in a dark room working for hours aren't realising that cone fatigue or dark adaptation has set in and maybe that's why Hollywood has a desaturation problem. Because I found that if I look in a pitch black room the saturation and hue seems more balanced. But I don't like having to turn all the lights out. During the day nothing can be evaluated reliably.

[flossy_cake]

Like, right now, I'm looking at the left image of Dax on S90D and it doesn't look that bad at all. In fact it looks kind of normal. This wasn't the case yesterday so I've no idea what's going on. And on my IPS screens right now it's the other way round and the left one looks quite bad and the right one looks "obviously correct". Maybe it's S90D's QDOLED thin spectral distribution that doesn't jive with my cones in a predictable way like IPS

[flossy_cake]

is supposed to look like with this promo photo of Dr. Crusher that I put up earlier in https://forum.doom9.org/showthread.php?p=2020733#post2020733

But remember 470M has a different blue primary, so even when 470M is the intended gamut, the suit still should look teal instead of the "correct" blue

https://i.imgur.com/8kv9t6p.png

The white line is 470m, black line is 170m. So let's say you want that deep saturated blue on the tip of the black triangle, you can't do that in 470m, the closest you can get is further up the black line where it intersects with the white line, which is more towards cyan i.e teal

Another thing is that ok her suit is wrong, but what's more important her suit or her face? If her face is wrong then that's arguably just as important. On my IPS PC monitor right now (calibrated greyscale and in sRGB colour space which is same as 709) her face is completely wrong. But on my QDOLED (calibrated greyscale AND colour space cal to 709) right now it looks okay. But it's cold right now 12C and I find QDOLED becomes more saturated and crushed in the low end when it's cold. But also it's twilight and there's some bluish twilight coming in through the curtains so I think that's affecting my perception as well

[flossy_cake]

Yeah so, the imgsli.com site is useful because it puts a dim grey as the background rather than white forum background. If I open that in a full screen web browser on the 470m dax, stare at that for 30 seconds, let my eyes adjust to that level of saturation, then when I switch back to 170m Dax her face looks awful. Then, 30 seconds of starting at 170m Dax, starts to look normal, then swiping to 470M dax looks oversaturated.

[Sunspark]

Oh, install the Dark Reader extension.. it's great. No more white forum background. Default settings are fine. With it, the forum here is dark grey background.

[flossy_cake]

Thanks I'll check that out.

Also those Dr Quinn images I posted here (https://forum.doom9.org/showthread.php?p=2020973#post2020973)... note how crazy oversaturated it looks when 170M is incorrectly decoded as 470M. The fact that Star Trek does not look anywhere near that degree of oversaturation I think is telling.

[flossy_cake]

Yeah I don't know what's going on, I'm looking at Voyager S01 and it looks all wrong at 470M. DS9 S01 and TNG S01 still look okay at 470M though. I think Voyager maybe just has that NTSC hue phase shift and lost some chroma in the conversion to composite and could do with a slight chroma boost with Avisynth Tweak().

One things for sure - I can't trust my lying eyes!

edit: actually for TNG I think it's just full of mastering errors and I'll just remain agnostic. I can see regardless of which gamut I choose, the colour grading can vary quite dramatically from one scene to the next within the same episode. Perhaps some scenes were spliced in from a 170M tape and others went through a different analogue pipeline that converted to 470M and so there may be no "one size fits all". But that garden scene with Picard and Wesley (first image in OP) is definitely 470M imo.

[Sunspark]

Time to give up. :) They'll either scan the film one day, or someone will invent some kind of AI learning model that is trained on props and uniforms in different light conditions and adjusts the rendering accordingly.

Might be interesting to check out a VHS tape sometime to see how it looks.

[DS9Redefined]

Might be interesting to check out a VHS tape sometime to see how it looks.

Theoretically the LaserDisc and VHS should match very closely color-wize since they're both analog RF transfers, they would have had to pass through separate modulators to down-convert to the formats. I did get a VHS of the Voyager episode "Tattoo" so hopefully will be able to do a comparison at some point.

[flossy_cake]

I could also buy the PAL DVDs to see if that went through a different process.

[Sunspark]

Theoretically the LaserDisc and VHS should match very closely color-wize since they're both analog RF transfers, they would have had to pass through separate modulators to down-convert to the formats. I did get a VHS of the Voyager episode "Tattoo" so hopefully will be able to do a comparison at some point.

Well, the thing is, the LaserDisc material you've already shared, doesn't look like how I remember it looking on my TV when it was first broadcast so something is different. It's been a long time, maybe I just remember it different now, like how we remember old video games looking different.

I still have an old 2-head VCR in the basement and some retail VHS tapes, but no Star Trek.

[flossy_cake]

Well, the thing is, the LaserDisc material you've already shared, doesn't look like how I remember it looking on my TV when it was first broadcast so something is different. It's been a long time, maybe I just remember it different now, like how we remember old video games looking different.


Do you seem to remember the teals? For some reason I think I have a memory of the teals, like in DS9 when the wormhole opens its this magical teal colour, and the teal accents on their uniform uppers. For some reason I think that's part of the identity of the show. I'm trying to figure out if it's a false memory like Mandela Effect or something lol

[Sunspark]

No, I don't actually. Basically what I did back then was adjust the hue and saturation until it looked pretty OK for all skin tones, then all the rest of the colours were whatever they were.

[DS9Redefined]

We may have figured it out! Or at least come even closer. Here's some new work from JonnyPoe that I'll be replicating later tonight to see if I get the same results.
Essentially, when using the ffmpeg Zscale filter or the AviSynth z_ConvertFormat filter to convert from 470m to 709, they don't appear to be properly converting the white point.

- X - - Y - |
0.3100 | 0.3160 | ntsc
0.3127 | 0.3290 | 170m, 709, 470bg, rgb*
0.2848 | 0.2932 | ntscj

For AviSynth, Jonny added in fmtconv to do the whitepoint conversion. z_ConvertFormat is still needed because fmtconv requires RGB rather than YUV.

z_ConvertFormat(pixel_type="RGBPS", colorspace_op="fcc:470m:470m:limited=>rgb:same:same:limited")
fmtc_primaries(prims="470m", primd="709", wconv=true)
z_ConvertFormat(pixel_type="YUV444P16", colorspace_op="rgb:709:709:limited=>709:709:709:limited")

For ffmpeg, you can use the colorspace filter with wpadapt:
-filter:v "colorspace=ispace=fcc:iprimaries=bt470m:itrc=bt470m:irange=tv:fast=0:dither=fsb:wpadapt=bradford:all=bt709"

Here's how it looks on the DVDs:

https://i.imgur.com/N7G53EOl.png (https://i.imgur.com/N7G53EO.png)

https://i.imgur.com/ez1wJkAl.png (https://i.imgur.com/ez1wJkA)

https://i.imgur.com/YzoDMAGl.png (https://i.imgur.com/YzoDMAG)

https://i.imgur.com/89UKm9Wl.png (https://i.imgur.com/89UKm9W)

https://i.imgur.com/IibkCxNl.png (https://i.imgur.com/IibkCxN)

https://i.imgur.com/6LSG4fnl.png (https://i.imgur.com/6LSG4fn)

https://i.imgur.com/lXvIKWyl.png (https://i.imgur.com/lXvIKWy)

https://i.imgur.com/RxhathKl.png (https://i.imgur.com/RxhathK)

https://i.imgur.com/GveMKT6l.png (https://i.imgur.com/GveMKT6)

https://i.imgur.com/FxGhkDIl.png (https://i.imgur.com/FxGhkDI)

As for the LaserDiscs, something that I found before we knew about the colorspace issue was that the "phase compensating decoder" feature of ld-decode that's on by default seemed to cause colors to be inconsistent from scene to scene. Turns out, we just didn't have the right color space and white point. Turning the PCD back on gives us these results:

https://i.imgur.com/Pdrwvq4l.png (https://i.imgur.com/Pdrwvq4)

https://i.imgur.com/zede1TIl.png (https://i.imgur.com/zede1TI)

https://i.imgur.com/V9S83Twl.png (https://i.imgur.com/V9S83Tw)

https://i.imgur.com/WwkkhCwl.png (https://i.imgur.com/WwkkhCw)

[Sunspark]

PCD with the Laserdiscs presents 100% better. These are much closer to what I remember from broadcast.

The DVD images still have issues. Way too much red (or not enough green) on the white point converted images.