Журнал LinuxFormat - перейти на главную

LXF104:Интервью

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Новая: ==Linux шагает в кино== : Разработчик ''CinePaint'' '''Робин Роу''' описывает 3D-анимацию Голливуда и студии по прои...)
 
м (добавлены категории)
 
Строка 186: Строка 186:
 
Apple не взял на работу нашего ведущего разработчика по этому проекту, и только мы его и видели! Теоретически, доделывать не так уж
 
Apple не взял на работу нашего ведущего разработчика по этому проекту, и только мы его и видели! Теоретически, доделывать не так уж
 
много. '''LXF'''
 
много. '''LXF'''
 +
 +
[[Категория:Интервью]]
 +
[[Категория:Робин Роу]]

Текущая версия на 12:14, 28 октября 2011

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

[править] Linux шагает в кино

Разработчик CinePaint Робин Роу описывает 3D-анимацию Голливуда и студии по производству видеоэффектов как мир, где все шиворот-навыворот, где тон задает Linux, а остальные платформы просто не котируются. Заинтригованные, мы захотели узнать больше…

Внимание, киноманы: что общего у «Последнего самурая», «Планеты Обезьян» и «Гарри Поттера»? Угадали: ответ – Linux, а точнее – CinePaint, графический редактор с открытым кодом, то и дело подправляющий сцены из жизни школ для юных волшебников, имперской Японии и Нью-Йорк Сити Питера Паркера.

Ведущий разработчик CinePaint, Робин Роу [Robin Rowe], стоит у руля одного из тех немногих настольных проектов, которые одновременно являются и свободным ПО, и содержат код, предоставленный студиями-соперниками. Наш бесстрашный репортер Дэниэл Джеймс встретился с Роу у него дома, в Беверли-Хиллз, чтобы выяснить, в чем проявляется колоссальное влияние Linux на соседний кинотеатр, каково это – стать приемным отцом осиротевшему коду, и каким видится будущее программы, которую когда-то называли Film Gimp.


ДДж: Как вы начали заниматься разработкой программ?

РР: Я учился этому в школе, но моим основным предметом [в американских школах ученики сами выбирают свою специализацию, – прим. ред.] были не «Компьютерные технологии», а математика и танцы. Это было в эпоху перфокарт; ПК еще не получили распространения. Я нашел работу в телеиндустрии, на станции NBC, и какое-то время занимался этим. Потом ПК стали очень популярны, и ко мне начали обращаться за консультациями. Кончилось тем, что я перешел на консультации, а потом на обучение – все это было в Чикаго. Затем я перебрался в Сиэтл, чтобы быть поближе к Microsoft, а однажды мне позвонили из Университета Вашингтона и спросили: «Не согласитесь ли вы преподавать на вечернем отделении?», и я отправился туда.

В итоге я стал профессором в Мореходной аспирантуре в Монтерее, то есть госслужащим – поскольку работал на ВМФ. Оттуда я перебрался в оборонный сектор – поступил в крупную оборонную компанию из списка Fortune 500, а оттуда – в киноиндустрию. Меня пригласили на работу в DreamWorks Animation, чтобы я потрудился у них на ниве рендеринга, используя C++ и Python.

ДДж: Когда вы впервые услышали о проекте CinePaint? По-моему, когда вы взошли на борт, он назывался Film Gimp, да?

РР: Film Gimp или Hollywood Gimp – у него было два названия. Я тогда писал статьи для Linux Journal и выпустил целую серию материалов о том, как киноиндустрия переходит на Linux и как это у них получается. Что у них за задачи, как они их решают, в общем, всякое такое. Среди упомянутых мною студий была Rhythm & Hues, довольно крупная, хотя и не особо широко известная. В процессе написания, я у них спросил: «А вы пользуетесь штукой под названием Film Gimp? Что вообще с этим проектом происходит?» И они ответили: «Да, все еще пользуемся – вот применяли в “Скуби-Ду”. Это система покадрового ретуширования, мы с ее помощью чистим кадры от мелких дефектов». Есть более автоматизированные инструменты, но с их настройкой нет смысла возиться, когда подпорчено всего несколько кадров. Гораздо быстрее ручная правка, если все не слишком масштабно.

ДДж: Итак, на тот момент это была часть проекта Gimp?

РР: Да, и они продолжали разработку, но остальная часть индустрии по большей части потеряла его из вида. Они были среди самых первых разработчиков, и весь проект создавали с людьми из Gimp. Film Gimp никогда не был отдельным проектом, это часть Gimp. Киноиндустрия помогла профинансировать поддержку 16-битного цвета, потом 32-битного, а затем и кинеографа. В Film Gimp были функции, уникальные для киноиндустрии, и очень важные для нее, поскольку их стандартный формат файлов в Gimp искажался: он калечил изображения, пытаясь считать их в 8-битной системе отрисовки.

В киноиндустрии полагали, что будет Gimp 2.0, но они [разработчики Gimp] почему-то решили его не делать. Все это было еще до меня. Проект выпал из поля зрения; люди о нем забыли, да он и сроду не отличался особой публичностью, поэтому я написал о нем статью, объявив: код открыт, «и вот как вы можете получить его»; он вообщето был на сайте Gimp, но нужно было знать магические пассы, чтобы извлечь его из их CVS, там же не было ни tar-архива, ничего. Мне стали писать: «Почему такая дивная вещь сидит где-то на задворках?», ну, а я им: «Я просто написал статью, а программа не моя». Потом стали присылать заплатки и просить tar-архив. Я говорю, у меня его нет, а мне на это – «Вы должны сделать так, чтобы эту штуку можно было собрать, и вы это уже сделали, мы же видели снимок экрана в журнале. Вы явно ее собрали – вот и дали бы нам свой tar-архив, поскольку эта версия программы нормальная, мы знаем». Я тогда – «Ну ладно». Тут начали возвращаться заплатки со словами: «Вот здесь ошибка, а вот исправление». А потом людям действительно понадобился tar-архив, потому что пошли слухи: «У Робина есть версия с заплаткой, которая исправила ошибку!»

ДДж: То есть вы стали лидером проекта вроде как явочным порядком.

РР: Ой, просто с ума сойти. Я пришел к разработчикам Gimp и говорю: «Хотите, я присоединюсь к проекту Gimp? Что вы с ним собираетесь делать?» А они: «Да, хорошо было бы, но нам придется дать тебе пароль на сервере». Месяцы идут, ничего не происходит. Наконец, я спросил: «Может, я выложу его в SourceForge?», и в ответ услышал: «Да пожалуйста». Так я и сделал, и превратился в фактического лидера проекта. Люди тут же возжелали узнать, почему в программе так много ошибок; не мог я, что ли, сделать ее получше; каким местом я, собственно, думал; и тому подобное. Я сказал: «Эй, меня расспрашивали об этой программе. Код у нее открытый, и народ говорит, что невозможность ее найти – просто преступление; ну так вот вам она». Затем мне позвонили из Sony Imageworks и рассказали, что воспользовались этой программой. У них было несколько человек, которые работали в Rhythm & Hues, а потом перешли в Sony и программу взяли с собой, потому что это Open Source. В обычной ситуации такого бы никогда не произошло – программа осталась бы в собственности. Итак, ее стали использовать в Sony, сделали к ней поправки и вообще все, что нужно, и у меня спросили: «Хотите ее получить?» А я ответил: «Было бы здорово! Почему бы и нет?» Они предложили мне человека, помочь с кодом, и я сказал: «Это вообще отлично, просто фантастика!» Если скидывание вам заплаток – это помощь, то мне помогли, но ничего другого я не получал.

ДДж: Вы переименовали ее в CinePaint примерно тогда, когда ушли из Gimp?

РР: Я создал группу под названием LinuxMovies.org, которая существует до сих пор, но мы не встречаемся, потому что практически незачем. Linux настолько стандартен, что это было бы равносильно встречам для обсуждения Windows – что бы вы на это сказали? Но тогда еще шла борьба; все было на уровне: «А вы пропатчили свое ядро?», ну и в этом роде. Я подумал, что круто было бы иметь свою конференцию, и она проводилась два года, в ней участвовали технические специалисты из киноиндустрии. Одной из главных тем первого года стал Film Gimp. Тогда многие из этих людей встретились впервые. Они были знакомы только по электронной почте, а тут увиделись. И каждый имел свою концепцию направления развития Film Gimp – то есть полный хаос. Но в одном они, к моему изумлению, сошлись: всех трясло от этого названия. По их мнению, оно было самое отстойное. Они просили: «Ну пожалуйста, давайте мы его переименуем». И мы взяли название CinePaint.

Кроме того, из-за прежнего названия возникала некая путаница: раз в названии было слово Gimp, нас и считали частью проекта Gimp, и так происходит до сих пор. У нас спрашивают, чем нас не устраивают разработчики Gimp, почему мы ушли из проекта. А мы-то в нем никогда и не участвовали.

ДДж: Вы упоминали форматы файлов, используемые в индустрии. Есть OpenEXR...

РР: Которого на тот момент не существовало. На самом деле, CinePaint стал первым приложением, которое поддерживало OpenEXR, потому что ILM [Industrial Light & Magic] предоставили нам код модуля расширения .

ДДж: Потому что они тоже использовали CinePaint у себя?

РР: ILM рассматривала это скорее как эксперимент. Самыми крупными пользователями были Rhythm & Hues и Sony, и был еще ряд студий помельче, которые тоже пользовались программой для своих целей.

ДДж: Я так понимаю, судя по названию, OpenEXR создан для более широкого применения, чем домашнее употребление в Industrial Light & Magic?

РР: Что-то сдвинулось благодаря «Матрице» – она всех типа пробудила. До этого момента было так: над картиной работала одна компания, создающая видеоэффекты, и иногда кто-то занимался мелкой доработкой. Но в «Матрице» было столько видеоэффектов, что пришлось привлечь семь компаний, специализирующихся на их создании. Это был хаос, просто Вавилонское столпотворение: раньше крупные компании никогда не обменивались материалами во время постпродакшна. На тот момент стандартными форматами были DPX, Cineon и разные вариации 16-битного TIFF. И у всех у них были неоднозначные результаты: цвета одной студии совсем не обязательно смотрелись так же, как цвета другой студии. А когда фильм монтируется в единое целое, радоваться тут нечему. Я полагаю, это и послужило толчком; спросите у ILM, в какой момент они решили это сделать, потому что раньше такой проблемы не было – не было необходимости во взаимообмене.


ДДж: Игра под названием «взаимодействие».

РР: Формат TIFF дает широкие возможности. Все думают, что знают, что такое TIFF, а на самом деле – нет, когда вы получаете какой-нибудь экзотический вариант. Он может сильно отличаться от ваших представлений. Что-то вы увидите, но будет ли оно выглядеть так, как вы ожидали, на вашем мониторе, это уже другой вопрос.

В то время в TIFF использовался HDR [high dynamic range – высокий динамический дипазон]. В обычном образе TIFF значения идут от нуля до единицы, но для кинопроизводства весьма распространенным является, когда значения идут от нуля до двух. Это означает, что все имеет либо половинную интенсивность, либо двойную, в зависимости от того, как вы смотрите на это в обычном просмотрщике TIFF.

ДДж: Изначально Film Gimp основывался на GTK 1, не так ли?

РР: Он и теперь содержит кусок GTK 1.

ДДж: На каком этапе вы решили его переписать?

РР: С тех пор уже два года прошло. Мы унаследовали код, который понять не могли. Когда мы его получили, уж точно ничего не понимали – я просто выложил tar-архив, и все. Люди стали сообщать об ошибках, и мне пришлось продираться сквозь код. Это действительно интересная архитектура. Он разработан в 90-х, и для того времени был просто блестящим, но с тех пор многие успели приложить к нему руку. Пока над ним работали один-два человека, он, возможно, был превосходным, но потом его курочили человек эдак сто, и он несколько ухудшился.

Да и компьютерные программы тоже изменились. Когда он разрабатывался, ОЗУ было драгоценным, а процессоры – намного медленнее. Так что вся парадигма за это время сильно изменилась. Во времена Film Gimp изображения OpenEXR и HDR только-только вступали в жизнь

ДДж: И чем вы в итоге стали пользоваться?

РР: Я занялся исследованием, чтобы решить, какие выбрать инструменты. GTK 1 нас немало огорчал. Группа GTK 1 ограничилась обещанием, что если мы сообщим им об ошибках, они их исправят. Звучит замечательно, пока вы не начнете работать с действительно сложным графическим приложением, и они вам скажут: «Ладно, вырежьте ту часть приложения, в которой есть ошибка, и пришлите нам». Быстрее было бы самим исправить ошибки в GTK. Знай мы об этом, мы бы с ними покончили! GTK 2 намного больше, чем GTK 1, а у нас не было ресурсов для отладки GTK 1. Многим нравится инструментарий Qt, он весьма заманчив, но это означает зависимость от других в деле исправления ошибок.

Потом дело дошло до менее известных вещей, например, FLTK [Fast Light Toolkit – Быстрый Легкий Набор Инструментов, произносится ‘fulltick’]. FLTK сразу понравился, поскольку был задуман специально для кинопроизводства. Примерно так: «Мы должны этим воспользоваться, просто чтобы поддержать наших».

ДДж: Он ведь изначально был создан одним из разработчиков в [студии видеоэффектов] Digital Domain?

РР: Да, он был разработан в Digital Domain, теперь это компания Майкла Бэя [Michael Bay]. Она поставляет немало коммерческих программ Linux, в том числе Nuke. Набор инструментов создавался как раз для Nuke.

ДДж: Изначально это был инструмент для внутреннего студийного пользования Digital Domain, да? А потом они сделали его проприетарным приложением…

РР: Да, коммерческим проприетарным приложением. Причем для Linux, так что можете пойти и купить его. Эта программа – композитор, это совсем не такой зверь, как CinePaint. Композитор берет видеокадры и смешивает их. То есть вы берете главных персонажей и снимаете их на фоне зеленого экрана. И у вас есть другой ролик, где отснят нужный вам фон. Композитор их соединяет – абсолютно идеально, словно вы снимали свой персонаж, стоящий на нужном фоне.

ДДж: То есть от редактора его работа отличается многослойностью?

РР: Это очень похоже на работу в Photoshop, где у вас есть один слой, и еще слои, и вы накладываете их друг на друга и создаете нечто, а в редакторе вы просто нарезаете и соединяете кадры и присоединяете к ним титры. Редакторы становятся все более сложными, так что налицо некое сближение.

ДДж: FLTK живет своей жизнью, не так ли? Он использовался уже в нескольких проектах…

РР: По-моему, еще до того, как Film Gimp попал на SourceForge. Что интересно в FLTK – он настолько мал, что просто встраивается в приложение, а с набором инструментов графического интерфейса этого обычно нельзя сделать. В процессе отладки выход за границы динамической библиотеки зачастую бывает болезненным. Если же все скомпилировано внутри, вам не приходится делать таких скачков, и инструменты отладки уже имеются. Работая c Glasgow, я обнаружил, что он не справляется с двумя мониторами; мешала ошибка в коде. В GTK 1 исправить ее было бы невозможно; и не потому, что нельзя было туда влезть и все сделать, а просто это заняло бы уйму времени.

ДДж: А название Glasgow всплыло не потому, что Университет Глазго тоже внес определенный вклад?

РР: Университет Глазго все и делал. Я пытался найти финансирование в США, и, в силу разных причин, впустую. Мы встречались с разными вице- и прочими лицами. И при этом теряли свой запал: ведь пока ты ходишь по чиновникам, программы сами не пишутся. Если у тебя маленький проект, то, гоняясь за финансированием, легко перегореть.

Команда исследователей Университета Глазго добилась финансирования от ЕС, и они сказали: «CinePaint неплох, но он нам не совсем подходит. Мы могли бы переписать его, и нам нравится FLTK. Что если мы этим займемся?» Это была сомнительная удача: они наваяли столько кода, что на нас уже во второй раз свалился огромный tar-архив! Архитектура его во многом походила на Gimp, так что разобраться в нем было можно. Но, по нашим планам, релиз должен был появиться намного раньше, так что этим ребятам пришлось поднажать. А у их исследования были свои цели, плюс приходилось отчитываться перед спонсором, и они спешили уложиться в срок. Завершили проект, да и говорят: «ОК, наше финансирование кончилось. Вот вам!» Здрасьте, опять сиротка на моем пороге!

ДДж: Вы ищете разработчиков для работы над проектом?

РР: В общем, да. Наша очередная задача – вытащить кое- какие интересные наработки. CinePaint – и совершенно напрасно – часто принимают за видеоредактор. А есть видеоредактор, под названием Shortcut, который пропал было из вида. Он есть на нашем CVS – мы обдумываем его реанимацию. Также имеется GTK+OSX, проект GTK для Mac – еще один сирота, которого я усыновил. Все шло хорошо, пока Apple не взял на работу нашего ведущего разработчика по этому проекту, и только мы его и видели! Теоретически, доделывать не так уж много. LXF

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF104:%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%B2%D1%8C%D1%8E&oldid=12852»
Персональные инструменты
купить
подписаться
Яндекс.Метрика