Вообще-то, это "dpsRealityHD, providing single-stream HDCAM native storage with an SDTI interface", см. http://www.dps.com/dpsweb.nsf/IBC2001?OpenPage. А SDTI означает компрессию потока со стандартных для SMPTE 292М 1,49Gbit/sec до 270Mbit/sec SMPTE 259М. Это во-первых.
А во-вторых, в realityHD способ представления данных - 44:15:15 вместо полагающихся 44:22:22. Если провести аналогию с принятым в ITU-R-601 стандарте 4:2:2-квантовании для сигнала YUV, формат 44:15:15 эквивалентен использованию квантования 3:1:1 (или 4:1,5:1,5).
То есть при базовой частоте оцифровки яркостного канала в ATSC-1920 = 74MHz, цветовые каналы оцифровываются с частотой в 1,5 раза меньше (25MHz вместо 37MHz), чем это должно быть для сохранения соотношения в качестве представления сигнала.
Что из этого следует ? Материал, снятый на HD, проходит через узкое "горлышко" SDTI + ограниченное квантование reality HD. При этом смазывается по горизонтали цветовая составляющая из-за пониженной частоты оцифровки каналов U и V. Под вопросом keying и глубокая цветокоррекция. Также вероятно появление характерных квадратиков из-за HDCAM-компрессии (1490:270=5,5:1), если очень сильно "выкручивать ручки" цветокоррекции.
В случае серьезного post-production никуда не деться от необходимости оцифровывать через "полноценные" HD-карты, работающие в "настоящем" YUV-пространстве, а еще лучше, в RGB (не по битности, а по формату видеосигнала). Такие, как DVS'овская карта для ОЕМ'ов (в частности, NothingReal, производитель пакета Shake, делает на ее основе систему TremorHD), Avid Meridien в Softimage|DS HD, 5D Cyborg Commander и DMediaPro2 и 3 для SGI. При этом все они, кроме DMediaPro3 (под Onyx3200), работают в HD с использованием формата YUV (44:22:22) 10bit или RGB (44:44:44) 8bit. Последняя же поддерживает и HD RGB (44:44:44) 10bit. В случае серьезных спецэффектов на киноносителе выбор очевиден.
Если же отснятый материал просто монтировать встык, делать небольшую цветокоррекцию и накладывать титры - то сойдет и HDCAM.
Кирилл Буслаев, видеоинженер
)