Render.ru

Размер сиквенсов

#1
При стандартном bath rendering 640 на 480 850 кадров в TGA весят около гигобайта

Подскажите пожайлуста Это так надо или я напортачил

Винт у меня не резиновый
 
#2
стандартный кадр Pal в тарге с альфаканалом и без RLE компрессии весит 1,6 мега.
 
#3
Как учит наука Арифметика:

640*480*3=921600
921600*850=783360000=765000K=747,0703125M (действительно под гигабайт).

Может оно так и не надо, но оно так есть.

Лео
 
#4
Я сам не пробовал, но если есть проблемы с местом, то наверное можно использовать "Post Render MEL" в RenderGlobals->RenderOptions. И с его помощью вызывать для только что просчитанного кадра команду типа:

imgcvt -f tga -t tga RenderedPic.PicNumber.tga CompressedPic.PicNumber.tga
delete RenderedPic.PicNumber.tga

Я например использую imgcvt, когда нужно срочно прокачать по неповоротливой сети последовательность кадров на монтаж. Кадр с какой-нибудь маленькой фигнёй с альфой на чёрном фоне занимает более мега только засчёт отсутствия RLE компрессии. Переконвертирование из некомпрессированной в RLE-компрессрованную tga иногда в зависимости от того, что изображено в кадре, может снизить размер файла в несколько раз ,не затрагивая качества.

Например , если есть последовательность picture.0.tga --- picture.500.tga , то

imgcvt -f tga -t tga -n 0 500 1 picture.@.tga comp_picture.#.tga

В результате получается последовательность
comp_picture.0000.tga --- comp_picture.0500.tga
(знаки @ и # позволяют преобразовать нумерацию в четырёхсимвольную,
хотя это можно ещё до просчёта задать)

Если вы запускаете майский рендер не из под интерфейса, а из коммандной строки, то в .bat файле можно задать чтобы скажем через каждые 10 посчитанных кадров они компрессировались с помощью imgcvt , а исходные кадры удалялись.
MEL и коммандная строка - иногда ну очень полезные штуки.
 
#6
Нравится. Но tga с RLE-компрессией у меня получился на 12% меньше аналогичного sgi. Что это - дополнительная выгода или лишний гимор - зависит естественно от содержания кадра и от длины последовательности кадров.
 
#7
Это странно...Тарговская компрессия довольно-таки примитивная...Например, градиент "сверху-вниз" компрессуется хорошо (в строках одинаковые значения цвета), а такой же градиент ("слева-направо") комрессуется плохо (нет одинаковых рядом стоящих пикселов) и в этом случае компрессный файл больше некомпресного...Вот такие вот пироги...
Алгоритмы компресии (имеется ввиду компрессии без потери качества, то есть архивации) хороши в форматах RLA и IFF- там, похоже, каждая битовая плоскость компрессуется независимо...Вообщем, тарга хороша лишь с точки зрения универсальности (формат настолько тупой, что его все понимают) и совместимости со всеми внешними девайсами и программами...
 
Сверху