Need help with an admittedly convoluted equipment chain

[HDgaming42]

First off--yes this is excessive, and yes the difference might ultimately be minute, but it's something I'd like to try. I have the vast majority of the gear listed, but want to have a "sanity" check on the proposal before spending any more $$$ on solutions that don't work. I'd also like to avoid shelling out for a Corio2 or DVDO HD,HD+ if possible. Hence this "I already have most of this" maze I've constructed.

I want to calibrate all my monitors with a LUT. The LUT box I have only does 720p through 1080p via HDMI. I want to get back to 15kHz 240p, and feed both RGB (PVM) and consumer component monitors. Yes, running component to everything would skip a step but I'm OK with another DA.

The only gear I don't have is the extron DA6xi (I could use a mechanical VGA switch in reverse instead) and the RetroTINK. That's why I'd rather not shell out mad dollars for a Corio2 unit. If I could find a reasonable DVDO HD or HD+ unit I think I could skip a lot of this chain.

So does the following make sense? Is there a way to skip a step?

I think *most* of this gear is essentially lag free, so I don't anticipate it adding up to being objectionable.

Thoughts?

[HDgaming42]

OK, maybe there's a breaking point where a Corio2 or DVDO unit makes sense. Didn't realize a RetroTINK rgb2comp was as much as it is. That's approaching used DVDO pricing.

But if I'm dealing with 720p/1080p HDMI/DVI, then the DVDO non + model won't work for me, is that correct? The regular HD doesn't process the DVI input?

What about quality of the HD+? Is it as good at downscaling as the Corio2? I suppose I could spring for a DVDO HD+ and then just use one DA to all the monitors and just have the DVDO decide whether it's outputting RGB or component...

DVI Input
-
The DVI input accepts 480p, 576p, 720p and 1080i formats. If the content is copy-protected by HDCP, the iScan HD+ will output the processed signal on the DVI output with HDCP or if the analog output is selected, the iScan
HD+ will output blue screen. Non HDCP signals will be output on either the DVI output or analog output. Other input formats are passed through to the DVI output unprocessed.

It seems even the HD+ won't take in 1080p. Good to know. The chain would still work if I initially used the OSSC 3x mode for 720p...

[HDgaming42]

OK, it seems the eeColor will actually passthrough 240p, all the way to 1080p. However it will only process 720p through 1080p. Great.

After many, many experiments with the equipment I have on hand I've found a method of success (for RGB).

OSSC at 3x into eeColor, out to DVDO VP30, out as HDMI 480p into Tendak convertor, into Extron 203rxi into Extron Emotia out to PVM. SUCCESS.



Two very similar methods that didn't work:

OSSC at 3x into eeColor, out to DVDO VP30, out as analog 480p into Extron 203rxi into Extron Emotia out to PVM. This resulted in an image, but it was blown out, and there was a rolling refresh line (single scanline) that I couldn't kill no matter what I set my refresh rate to.

OSSC at 3x into eeColor, out to DVDO Edge, out as HDMI 480p(and 640x480) into Tendak convertor, into Extron 203rxi into Extron Emotia out to PVM. This results in the 203rxi initially reading 31.kHz, boucing up to the seventies, and finally settling at 48kHz. I tried every combo of 1:1 frame-rate and frame-lock there was. Of course the Emotia really didn't like that at all.

Any idea why the Edge would do this? My thought is the downscaling might be better than on the VP30. Also, I don't see a "game mode" anywhere in the VP30 either...

[Unseen]

Wow, that's... convoluted.

As far as I know the OSSC does not convert from 601 to 709 primaries when it receives an RGB input signal - are you sure the calibration profiles in your LUT box are set up correctly to compensate for that?

[HDgaming42]

Wow, that's... convoluted.

As far as I know the OSSC does not convert from 601 to 709 primaries when it receives an RGB input signal - are you sure the calibration profiles in your LUT box are set up correctly to compensate for that?

Hmmmm. An intersting point. So let's think this through...

SD games are 601, OSSC upscales to 720p but doesn't convert to 709. I guess the question is whether the VP30 will automatically treat it as 709 because of the input resolution...

As for the LUT, I'll be using displaycal and it allows you to set the source colour space as ITU-R BT.470/601 (M).

[Unseen]

I guess the question is whether the VP30 will automatically treat it as 709 because of the input resolution...

I would be surprised if it doesn't auto-switch on some basis - maybe using the resolution, maybe using the metadata embedded in the HDMI signal. On the Edge, I have an option to manually override 601/709/auto on a per-input basis, maybe that option already exists on the VP30?

[kitty666cats]

https://www.ebay.com/itm/anchor-bay-mm- ... 4386963391

I saw this on eBay earlier, pretty reasonable price (I think?)

[Fudoh]

SD games are 601, OSSC upscales to 720p but doesn't convert to 709. I guess the question is whether the VP30 will automatically treat it as 709 because of the input resolution...

shouldn't matter. rec601 and 709 are used when RGB is converted to YCbCr and vice versa. The OSSC stays in RGB all the time, so there's no need to apply those conversion profiles. A secondary processorslike the DVDO also shouldn't apply any unnecessary encoding profiles when a RGB source is detected. And even if it does (to get the signal into the internal 4:2:2 YCbCr pipeline), it will also apply the right decoding profile when converting the output back to RGB 444.

In other words, no problem.

[Fudoh]

The Extron VSC + 203 combo in your first processing chain is flawed. First because it's unreliable and second because you'll never get a 100% perfect match in terms of sourse pixel rows to to 480i field rows. I found this extremely difficult to dial in.

How does your 2nd chain perform ?

I would think that you're at least introducing crosstalk between adjacent lines when downscaling the 720p output of the OSSC back to 480p using the DVDO. After all, it's not just dropping every 3rd line.

Also the Emotia is likely to introduce banding. It's just too old and dated to support the color bandwith you need.

[Unseen]

shouldn't matter. rec601 and 709 are used when RGB is converted to YCbCr and vice versa.

601/709 matters whenever the absolute color of the signal matters. The choice is baked into the LUT when it is created because the calibration process attempts to build the LUT so the measured output of the display matches the color of the input signal as closely as possible. This requires knowledge about the conversion from the input signal to an absolute color space, which is different for 601 PAL vs. 601 NTSC vs. 709 because they all specify different xy coordinates for their primaries.

[Fudoh]

yes, but's still not relevant to the question posed above (?). Since it's only relevant for YCbCr signals, and the DVDO receiving a 720p *RGB* signal from the OSSC. I can't see at which point any color conversion could go wrong in this particular processing chain.

15 years ago, when the majority of processed sources were SD and HD processing was just introduced, I've seen plenty of conversions going wrong and if you've seen enough, it's easy to tell with any green or red tones easily drifting off.

[Unseen]

Since it's only relevant for YCbCr signals, and the DVDO receiving a 720p *RGB* signal from the OSSC.

Once more, with feeling:

Bt.601 and Bt.709 specify different color coordinates for their primaries. The same RGB triplet corresponds to a different absolute color in 601 and 709. If HDgaming42 cares enough about color accuracy to use such a convoluted processing chain for color-correcting a CRT, this difference matters.

[Fudoh]

Please explain to me where this would come into play in an exlusive RGB chain from the creation of the assets to the display on RGB panel. BT 601 and 709 provide standardized numbers for conversion from RGB into or from YCbCr using matrices. If we assume that the DVDO handles the conversion from RGB to YCbCr and back to RGB in a way that we can't tell the difference between the input and the output (so 4:2:0 issues aside), at which point do you see this matter?

RGB > YCbCr > RGB using a bt601 matrix for both en- and decoding has the same results as RGB > YCbCr > RGB using a bt709 matrix for both en- and decoding. Problems arise when the two different matrices are used in the same chain, once for encoding, once for decoding. This is bound to happen when we use YCbCr for the exchange between machines, but that's not happening with the OSSC's RGB-only output.

[Unseen]

Please explain to me where this would come into play in an exlusive RGB chain from the creation of the assets to the display on RGB panel. BT 601 and 709 provide standardized numbers for conversion from RGB into or from YCbCr using matrices.

I'm not talking about conversion from or to YCbCr.

RGB > YCbCr > RGB using a bt601 matrix for both en- and decoding has the same results as RGB > YCbCr > RGB using a bt709 matrix for both en- and decoding.

Correct, but irrelevant for this argument.

Compare the tables for the primary chromaticities of Bt.601 and Bt.709. In the classic Horseshoe color diagram, these coordinates specify the three points of the triangle that marks all of the colors that the color space can generate. Since the two standards specify slightly different coordinates for their primaries, the corners of the triangles are at slightly different positions. An RGB triple specifies a point within one of these triangles by giving the coefficients for a linear combination of the three corners of the triangle (ignoring gamma and luminance to keep things simple). If you take the same RGB triple, but calculate the final color using different primaries, the final color is different.

This difference is small for 601-625/601-525/709, but becomes very noticeable if you would for example use Adobe RGB, Rec. 2020 or DCI-P3. If you have a monitor/TV that can be switched between sRGB and some wider gamut, try feeding it with an RGB signal and switching gamuts - it should make a visible difference. I liked playing the jungle segments of the Uncharted games on my Dell U2410 monitors in the Adobe RGB setting, which has much nicer greens, but always switched back for normal movies because it makes normal grass look weird.

[Fudoh]

I understand what you're writing, but I don't understand at which point a targeted color space would be defined for any given source. To take an example as simple as it can get: take a RGB source with variable output scan rate and feed it directly a PC RGB CRT. You can switch between ED and HD without seeing a change (though one would be 601 and the other 709 in the digital video domain). Now change the PC CRT for a DVI-only monitor. Then for a HDMI TV. And eventually the source for the assumed processing chain from above. At which point in which configuration do you expect any display (or any preceeding sink) to adjust it's color space to match the source in any other way than your most basic setup would?

[Unseen]

At which point in which configuration do you expect any display (or any preceeding sink) to adjust it's color space to match the source in any other way than your most basic setup would?

At the point where an absolute color space and calibration come into play. If you deliberately declare the source as "this is just arbitrary RGB" then there is no absolute color space and the whole discussion becomes moot, because no set of primaries is more correct for it than any other.

Since the original poster in this thread specifically said that he wants to do color calibration, he must have some idea what color space his source is meant to be, so the differences do matter.