Думается мне, в этих 13s 99.9% времени - рендер, а запись в png - копейки. Посмотри профиль (например, sysprof-ом).

libpng не шибко быстрый, но не настолько. Выше уже правильно написали, что там 99% - рендер.

Тут нужно ресурсов самому блендеру подкинуть ...

так и есть

на запись примерно 2 сек, только остальное не рендер, а сжатие в png

на рендер - секунда примерно, не больше, просто сделал тест на скорую руку, не стал заморачиваться чтоб было без рендера совсем

ты такой умный? прочти внимательно тему, ладно

попробуй в какой-нить jpg сохранить или bmp. есть ожидание что время будет примерно такое же, т.е. никакие патчи не помогут.

Посмотрел в лог, как-то странно.

Какое выходное разрешение? Насколько жив диск? Насколько будет отличаться результат по времени, если писать например в /tmp?

Файл не качал, ибо блендера у меня под рукой нет.

$ time blender -b save.blend -f 1
...
Saved: '/home/vitaly/Downloads/0001.png'
 Time: 00:10.26 (Saving: 00:08.48)


Blender quit

real    0m11.811s
user    0m15.353s
sys     0m0.605s

Странно это все. Компрессия и сохраниение в файл тут точно не причем.

На каком железе? У тебя время точно не на сжатие уходит. Включи больше отладочной инфы - может чтото прояснится.

Сжатие в png занимает микросекунды. Просто забудь об этом. Хотя можешь гдето в настройках выключить сжатие если сильно хочется.

Какое выходное разрешение?

PNG image data, 3840 x 2160, 8-bit/color RGB, non-interlaced

Насколько будет отличаться результат по времени, если писать например в /tmp?

не будет. Там какойто композитинг или что-то в этом духе.

привет

спасибо за интерес

железо asus g75wv

железо не причем, так как если я отключаю компрессию, то создание png занимает 2 секунды

http://pasteall.org/blend/index.php?id=48363

железо не причем,

Согласен

так как если я отключаю компрессию, то создание png занимает 2 секунды

Хммм ... Такое впечатление что ты отключаешь какойто постпроцессинг а не сжатие png. Может там под «компрессией» подразумевается сжатие динамического диапазона или чтото в этом духе?

Вряд ли, так как диалог сохранения png, во всех редакторах сходный, и параметр процента компрессии ведет себя одинаково, ну то есть тормозит libpng/zlib

прочел на офф гите libpng, как я понял, что 1.7.x будет обладать более быстрой компрессией

https://github.com/glennrp/libpng/pull/112

Попробуй пересобрать пакет с другими параметрами "-march".

Хммм ... Такое впечатление что ты отключаешь какойто постпроцессинг а не сжатие png. Может там под «компрессией» подразумевается сжатие динамического диапазона или чтото в этом духе?

Что-то тебя заклинило. ТС прав, тормозит именно сжатие png. Создай в GIMP файл 3840x2160, примени фильтр например «Шум RGB», чтоб не просто белый лист был (ну или любую картинку соответствующего разрешения открой) и экспортируй это дело сначала в bmp, а потом в png. И убедись уже, что сохранения png очень медленное.

Ускорить на несколько процентов можно пересобрав libpng под свою машину со всеми оптимизациями. Ускорить в разы не получится никак. Оно по природе своей медленное при сохранении (зато просмотр вполне быстрый)

Сжатие в png занимает микросекунды. Просто забудь об этом.

На каком месте в топ100 суперкомпьютеров твоя машина?

Если вообще не в топ100, то КАК? Даже бы при разрешении, как у ТС — 3840x2160, оно занимает секунды, причём даже около десяти на современных десктопах. При максимальном уровне сжатия, конечно.

Оно там не одно ядро грузит?

Одно, кстати.

Ну вот, значит, и выяснили способ ускорить в разы — переписать libpng, чтобы параллелилось. Правда микросекунд на домашней машине всё равно не будет, даже на восьми ядрах.

параллельно

Там же zlib под капотом, он умеет разве блочную компрессию?

Тормазит не libpng, a libz. Пнг нихрена не делает.

Ну дак выкинь это png, либо сохраняй не с экстремальными настройками. Ты место экономишь?

Что-то тебя заклинило. ТС прав, тормозит именно сжатие png. Создай в GIMP файл 3840x2160, примени фильтр например «Шум RGB», чтоб не просто белый лист был (ну или любую картинку соответствующего разрешения открой) и экспортируй это дело сначала в bmp, а потом в png. И убедись уже, что сохранения png очень медленное.

Ну хз. Я взял 3840x2160x4 байт мусора и сжал gzip-ом на селероне. Это конечно не быстро, но отнюдь и не 13 секунд, как у ТСа:

vadim@aquila:~$ head -c `expr 3840 \* 2160 \* 4` /dev/urandom > /tmp/1.tmp
vadim@aquila:~$ ls -l /tmp/1.tmp 
-rw-r--r-- 1 vadim vadim 33177600 ноя 21 18:06 /tmp/1.tmp
vadim@aquila:~$ time gzip -9 < /tmp/1.tmp > /dev/null 

real	0m2,902s
user	0m2,547s
sys	0m0,034s
vadim@aquila:~$ time gzip -6 < /tmp/1.tmp > /dev/null 

real	0m3,426s
user	0m2,625s
sys	0m0,047s
vadim@aquila:~$ time gzip -1 < /tmp/1.tmp > /dev/null 

real	0m2,977s
user	0m2,400s
sys	0m0,042s
vadim@aquila:~$ 

Хм, а вот если из gimp-а сохранять, то действительно долго.

Провел эксперимент. Я получил гдето 3.5 секунды на картинке автора на максимальном сжатии. Странновато, но все равно это далеко не те 10 секунд которые у ТС.

Я взял 3840x2160x4 байт мусора и сжал gzip-ом на селероне

У ТС i7. Мой i7 жмет за доли секунды.

А может ты попробуешь другие форматы вместо PNG? Ну там TIFF, TGA, ... . PNG сверх компресии при помощи zlib, выполняет сжатие LZ77, которое видимо и сьедает все твое время. LZ77 быстрым не бывает.

Вобщем мою фразу о том что libpng жмет за микросекунды теперь нужно понимать «zlib жмет за доли секунды». Извиняюсь за введение в заблуждение.

Я тут откопал что libpng жмет комбинацией LZ77 и zlib. LZ77 быстрым не бывает, это по всей видимости и есть корень его тормозов.

нет, я png люблю, ну и при 70% он у меня отрабатывает тест за 6 сек

покажи лог пожалуйста

теперь понятно?

bm@BM ~ $ time gzip -9 < /tmp/1.tmp > /dev/null
bash: /tmp/1.tmp: Нет такого файла или каталога

real    0m0,001s
user    0m0,001s
sys     0m0,000s
bm@BM ~ $ head -c `expr 3840 \* 2160 \* 4` /dev/urandom > /tmp/1.tmp
bm@BM ~ $ ls -l /tmp/1.tmp 
-rw-r--r-- 1 bm users 33177600 ноя 21 21:07 /tmp/1.tmp
bm@BM ~ $ time gzip -9 < /tmp/1.tmp > /dev/null 

real    0m1,118s
user    0m1,110s
sys     0m0,006s

теперь понятно?

:-)

Всеравно эта одна секунда zlib ничего не решает на фоне 9 секунд LZ77.

Неправильно откопал. PNG по архитектуре жмёт zlib (RFC 1950) которая представляет из себя минимальную обёртку над Deflate (RFC 1951), который представляет из себя комбинацию LZ77 и Huffman.

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

Неправильно откопал. PNG по архитектуре жмёт zlib (RFC 1950) которая представляет из себя минимальную обёртку над Deflate (RFC 1951), который представляет из себя комбинацию LZ77 и Huffman.

Вау, это обьясняет почему gzip отрабатывал намного дольше чем я предполагал изначально: я совершенно забыл что zlib это не чистый Huffman :-(

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

:-)

так как его ускорить?

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

Вот оно что. Про это не знал.

Ну, если решать задачу как разработчик - то вызвав что-то вроде

png_set_filter(png_ptr, PNG_FILTER_TYPE_BASE, PNG_FILTER_NONE);

Как это решить на уровне пользователя Blender - не знаю, надо читать доки к Blender. Не факт, что соответствующие опции проброшены вообще.

Решить это «оптимизацией компиляции» скорее всего не получится: PNG просто спроектирован таким образом, что один из этапов сжатия очень ресурсоёмок. Его можно либо отключить, либо использовать. «Ускорить» его практически невозможно.

На фуфыксе затестите, посоны.

blender -b save.blend --render-format BMP -f 1

Для такого изображения получившийся bmp всего в четыре раза больше, чем png.

«Ускорить» его практически невозможно.

Утилита convert позволяет очень слабо сжать png

convert -quality 01

Ну, она просто один из этапов сжатия пропускает, скорее всего.

У ТС выставлено Compression: 100%, поэтому и тормозит жутко.

https://blender.stackexchange.com/questions/69655/what-does-the-compression-s...

Compression: 20% — результирующий png на ~15% больше, скорость почти в 10 раз выше.

А фильтры?

Думаю, для максимального сжатия там что-то типа optipng используется.

ускорил!

переездом на Calculate

real    0m3.989s
user    0m9.087s
sys     0m0.775s

Разверни мысль?

было - 13 сек,

стало - 3 сек