Вот возвращаюсь к задаче перевода видео формата 320x240 RGB в 720x288 для последующего форматирования в BT.656 поток.
Заранее оговорюсь, 720x288 будет трактоваться как один field потока BT.656, т.е 2 последующих таких fieldа формирует полный 720х576 кадр (активное окно) PALa.
После гамма коррекции и перевода RGB в YCrCb (RGB -> YCrCb 4:4:4 -> YCrCb 4:2:2) получаем по каждому входному кадру в формате RGB 320х240 - 320х240 YCrCb в виде 320 samples Y и по 160 samples Cr и Cb (дя каждой из 240 строк ессно).
Задача, для подгонки под BT.656 - раздуть эти 320 Y samples в 720, а каждые 160 samples Cr, Cb - в 320 каждого, т.е. в сумме формируя поток активная зона которого содержит стандартные 1440 CbYCr samples.
Важно то что имплементация будет на FPGA с достуной внутренней памятью (блочной) ограниченного размера и несколькими DSP блоками. Характер информации - в основном ч/б (но важны градации серого и по возможности сохраненние четкости границ обьектов), цвет - немного текста наложенного на изображение. Ессно, все делается в реальном времени.

Вопрос - как лучше подойти к проблеме интерполяции 320 -> 720 (для Y) и для цветовых компонентов ? Что посоветуем ?
Bicubic - как то стремно ибо чисто теоретически кажется весьма ресурсо-загружен и в плане вычислений и в плане обьема памяти.
Может подумать насчет какого-нить алгоритма интерполяции 320 ->720 используя только данные одной данной строки ? (например какая-нить взвешенная одномерная интерполяция для каждой отдельной строки) ?
Что насчет применения подхода sample-rate conversion с отношением 9:4 (с требуемой фильтрацией ессно) ? Т.е. делать interpolation х9 а затем decimation by 4 ? Есть ли тогда шансы получить нормальное качество на выходе ?

Для цветовой составлющей, ввиду того что глаз менее чувствителен к ней а также принимая во внимание факт того что она несет информацию второстепенного значения, димаю duplication может быть достаточно.

Буду рад мнениям и конструктивным советам, особенно основанным на собственном опыте.