LINUX.ORG.RU

Gimp 2.10. Быстрее, чище, страннее

 ,


1

3

Несколько дней назад, была анонсирована новая версия растрового редактора Gimp, который , в мире свободного ПО, настоятельно рекомендуют для обработки фотографий. Некоторые пользователи (не буду показывать пальцем, потому что мы итак знаем, кто именно) сообщили, что в новой версии заметно возросла производительность. Чуть ли не в два раза, а может быть даже и больше. Конечно же, я не сдержался, скачал новейшую версию, достал секундомер и начал проверять.
Все знают анекдот про новую японскую пилораму, суровых сибирских мужиков и лом. В качестве лома для пилорамы-Гимпа я извлёк из закромов панораму из нескольких снимков, разрешением 36553 на 7503 пикселей и в 16-битном цвете. Объём tiff c lzv-сжатием – 1,4GB. Опыты производились на компьютере с процессором i7-6700k, 32GB Ram, 780GTX, накопитель SSD Samsung 850EVO. OpenCL включен.
Итак, для любознательных, некоторые цифры. Открывался файл до полной прорисовки 50 секунд. Размытие по Гауссу с радиусом 1000 заняло 4 минуты 10 секунд и завершилось успехом, а не как несколько релизов назад, когда всё изображение покрыло отдельными тайлами. Вообще, это долго, но, и правда — гораздо лучше чем было. Теперь расскажу про странное. Странное номер раз: USM c радиусом 3 и силой 2 на том же изображении считался 4 минуты 45 секунд. Дольше, хотя радиус не 1000 а 3. Я ненастоящий сварщик, но так быть не должно. Второе странное: и при блюре и при шарпе загрузка CPU составляла 15-20%, загрузка GPU 0%. Гимп бодренько засасывал оперативную память до отметки 20GB (из 32, напомню), после чего не взял себе больше ни мегабайта, зато начал порциями писать на диск со средней скоростью 100-150MB/s. Видимо, Гимп решил поберечь мою оперативку от использования, путем изнасилования SSD. Я не нашел, где в настройках Гимпа можно явно указать ему, чтобы не стеснялся, и брал себе, например, 80% оперативки. У меня ее достаточно, я для него и покупал. Пожалуйста скажите, какому именно богу надо принести человеческую жертву, чтобы такая настройка появилась в Preferences.
Кисти размером в 1000px у меня по-прежнему тормозили. Возможно, это просто моя карма.
Больше я не знаю что рассказать. Выйдет 2.12 — попробую снова.

>>> Просмотр (1920x1080, 1618 Kb)

★★★★★

Проверено: JB ()
Последнее исправление: JB (всего исправлений: 1)

Ответ на: комментарий от ist76

После применения фильтра - 1622MB

Это очень много. У меня на компе всего 4GB памяти, процессор amd phenom x4 (который даже dpdk и xmrig не пожет запустить) и ноутбук, где 2GB оперативки. Процессор правда посвежее (dpdk заведётся, да и помайнить можно) но, если я применю вышеуказанный фильтр, то в лучшем случае gimp грохнет oom или повиснет вся система.

ne-vlezay ★★★★★
()
Ответ на: комментарий от ne-vlezay

У тебя фотоаппарат снимает 36мп фотографии? Если нет, то какое тебе до этого дело?

ist76 ★★★★★
() автор топика
Ответ на: комментарий от ne-vlezay

У меня на компе всего 4GB памяти,

У гимпа для таких как ты есть ограничение на размер кеша.

Deleted
()
Ответ на: комментарий от AVL2

Давайте в текстовом редакторе тестировать террабайтные файлы, это ж так актуально...

Так в стандартных текстовых редакторах различных дистрибутивов GNU/Linux вообще отсутствует возможность открывать большие текстовые файлы. Хотя бы в режиме просмотра (ReadOnly).

Вот уж где победа.

EXL ★★★★★
()

оО... Окрестности Коктебеля!

exst ★★★★
()
Последнее исправление: exst (всего исправлений: 1)
Ответ на: комментарий от AVL2

Некоторые операции быстрее выполнить через кисть размером с изображение, чем искать в глубинах меню.

question4 ★★★★★
()

не использую как редактор, а люблю просто рисовать и проводить графические эксперименты именно из-за его Штранности

Deleted
()
Ответ на: комментарий от ist76

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

AVL2 ★★★★★
()

Для тех кто не в теме - фотошоп делает сильно быстрее? И есть ли у гимпа баги на нефункциональные требования?

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Фотошоп делает сильно быстрее (не в два и не в три раза, а в 8-10), и, что дополнительно нагнетает, многое фотошоп делает удобнее - те же кривые в корректирующем слое. Про «баги на нефункциональные требования» не понял.

ist76 ★★★★★
() автор топика
Ответ на: комментарий от ist76

Как ты сказал, есть вещи, которые гимп делает медленно.

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

pon4ik ★★★★★
()
Ответ на: комментарий от pon4ik

Да нет в этом никакой проблемы. Есть быстрые алгоритмы, защищенные патентами, например. Поэтому, до последнего времени их не использовали. И есть, как я понимаю, дефицит времени и ресурсов у разработчиков. Оптимизация - это долгая и кропотливая работа, а добавить новый фильтр можно, я думаю, за полдня.

ist76 ★★★★★
() автор топика

Вот, со второй попытки, сделал видео с другим графическим редактором:
https://youtu.be/4_mpCQ2pmKM
На видео, в том числе, используются кисти большого размера (правда курсор глючил, но что это кисти - понятно)
Вот хотелось бы, чтобы можно было повторить такое же в Гимпе и с той же скоростью. Пока что это, увы, невозможно.

ist76 ★★★★★
() автор топика
Ответ на: комментарий от ne-vlezay

А куда деваться, если такой размер графических данных? Сжимать их в оперативке, или обсчитывать всю цепочку преобразований заново на каждом действии? Можно ещё забыть историю действий.

Единственное что могу придумать: опускать историю действий в своп по тихому. Но это спорный метод.

kirill_rrr ★★★★★
()
Ответ на: комментарий от EXL

Слышал историю успеха при открытии 2+ Гб лога данных в nano. Вроде как долго думало и выжрало оперативки по размеру файла.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Ещё поделить на 8, ботому что 16 бит а не 16 байт. Как раз мой результат получится.

Так, почтал дальше. Вроде как пересчитали, вышли на те же 2 Гб при 16 бит*4 канала. Получается до выпадения в своп было сделано 8 преобразований?

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Деватся никуда не нужно, достаточно хранить оригинал на диске и текущее изображение в памяти, а всё остальное в виде операция над исходным изображением (вроде это «неразрушающее редактирование»), в гимпе к этому идут, но для этого надо всё переделать, щас вот gegl ввели, это как бы один из шагов к сему

Deleted
()
Ответ на: комментарий от Deleted

Мне кажется, неразрушающее редактирование в фотошопообразных редакторах изображений, это утопия.
Ноды, пресеты - вот это всё хорошо на потоке. А в штучной обработке они дают не очень много преимуществ.

ist76 ★★★★★
() автор топика
Ответ на: комментарий от ist76

В фотошопе оно емнип уже есть. Это какраз эти «слои», которые по сути являются просто фильтрами над подложкой (те же ноды).

Понятно, что для возюкания кисточкой это всё будет не к месту. Но если в файле пяток слоёв в которых кривые, размытие и т.п. то концепция очень сильно снизит размер и в памяти и в файле, да ещё и можно будет взять и «подправить» задним числом.

Deleted
()
Ответ на: комментарий от Deleted

В фотошопе оно емнип уже есть. Это какраз эти «слои», которые по сути являются просто фильтрами над подложкой (те же ноды).

Отчасти, да. И это ужас как удобно. Более того, там есть ещё такая штука, как смарт объект, которая позволяет в любой момент, например, поменять радиус для уже применённого блюра/шарпа.
Но как раз памяти это хозяйство жрёт просто вагон и производительности не добавляет.
Поэтому мне идеальным (для штучной работы над снимками) кажется именно «гибрид» когда и корректирующие слои и смарт-объекты, но при этом вся пачка слоёв линейная. Собственно, в ФШ же есть экшены и макросы, которые работают как те же наборы нод.

ist76 ★★★★★
() автор топика
Ответ на: комментарий от ist76

«Догнать и перегнать» не получится.

Уже получилось. Фотошопа нет, а гимп есть. Перегнать несуществующий продукт не сложно =)

Наличие фотошопа под оффтопик ровным счётом ничего не значит. Чай не WOR, а LOR.

skiminok1986 ★★★★★
()
Ответ на: комментарий от ist76

Плохо, когда сказать что-то умное хочется, а нечего, правда?

Ты так и написал это сообщение, признайся.

Отличать фотографов от фотодрочеров полезно, кстати. Но не для фотодрочеров, наверное =)

skiminok1986 ★★★★★
()
Ответ на: комментарий от skiminok1986

Отличать фотографов от фотодрочеров полезно, кстати.

А я не знаю, кто такие фотодрочеры. Это которые любят рассуждать, а сами не снимают, как ты?

ist76 ★★★★★
() автор топика
Ответ на: комментарий от ist76

А я не знаю, кто такие фотодрочеры. Это которые любят рассуждать, а сами не снимают, как ты?

Садись. Два.

skiminok1986 ★★★★★
()
Ответ на: комментарий от ist76

Хотя, нет. Это из неё кусок вырезать придётся. Давай сам в гимпе вырежешь кусок, который больше нравиться.

ist76 ★★★★★
() автор топика
Ответ на: комментарий от Deleted

Речь вроде как о потреблении памяти, так что если

а всё остальное в виде операция над исходным изображением

то получился, что отмена действия будет реализована как обратная операция или скорее промотка всей цепочки преобразований над исходным изображением. Так точно делать нельзя.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

то получился, что отмена действия будет реализована как обратная операция или скорее промотка всей цепочки преобразований над исходным изображением. Так точно делать нельзя.

Нет.

Deleted
()

Все знают анекдот про новую японскую пилораму, суровых сибирских мужиков и лом.

Вообще-то это не анекдот, а слегка переиначенная реальная история.

Quasar ★★★★★
()
Ответ на: комментарий от ist76

Большие мониторы с высоким DPI сделать слишком трудно из-за колоссального брака.

Quasar ★★★★★
()
Ответ на: комментарий от Deleted

Технический объём контента зависит от того, что позволяет на сегодняшний день канал в интернет передавать такие объёмы, и позволяют ли текущие устройства этот контент отображать.

Quasar ★★★★★
()
Ответ на: комментарий от ist76

Фотошоп пишут за зарплату и большой командой.

Не оправдание, но

«Догнать и перегнать» не получится.

Зависит от области применения. В ряде случаев GIMP уже давно догнал и перегнал фотошоп.

Quasar ★★★★★
()
Ответ на: комментарий от AVL2

неадекватные запросы к софту не просто бесполезны, но и контрпродуктивны.

нормальный у него запросы. так и надо тестить. терпеть не могу неженок программеров, которые дрожат над своим софтом: больше мегабайта файлы не открывайте, у него же переполнение случится!

Давайте в текстовом редакторе тестировать террабайтные файлы, это ж так актуально...

ты просто не знаком с настоящими мужиками. не нужно путать свою писанину в ворде с разнообразными текстовыми дампами от серваков...

crypt ★★★★★
()

Гимп бодренько засасывал оперативную память до отметки 20GB

ах-ха-ха, перестань, не надо так больше! надо бы еще размер свопа оценить, но всеравно это слишком большой расход памяти для 1.4 Гб файла, имхо. Или исходный файл слишком ужат. Вообще lzv-сжатие имхо лишнее в этом тесте. Размер исходных данных неизвестен.

при шарпе загрузка CPU составляла 15-20%, загрузка GPU 0%

тут надо сразу посмотреть, может, он диск забил. ушел в своп, а теперь надо работать с изображением и он начинает и читать, и писать сразу.

где в настройках Гимпа можно явно указать ему, чтобы не стеснялся, и брал себе, например, 80% оперативки.

Настройка правильная, но я бы наоборот уменьшал. Ибо жрет слишком много, всеравно все не влезет, а отдавая ему слишком много оперативки, ты вытесняешь дисковый кеш, который тож полезен.

crypt ★★★★★
()
Ответ на: комментарий от ist76

а если её опять снять, то будет ли быстрее?

проверялась ли работа opencl на чём нибудь ещё с отслеживанием! нагрузки на видеоядра? darktable, например, его умеет.

то есть есть ли у драйвера вообще в системе поддержка opencl?

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

ничего не проверялось
я чисто о своих впечатлениях пишу, очень частных - впечатлениях человека который ничего не понимает в ваших мегатехнологиях, но немножко (я надеюсь) умеет что-то делать с фотографиями
чтобы проверить как следует, надо AMD-карту какую-нибудь
а я этого у себя не держу и не планирую

ist76 ★★★★★
() автор топика
Ответ на: комментарий от ist76

я к тому, что надо замерять, насколько увеличился своп. по поводу исходных данных беру слова назад. около 4 гигов должен быть этот файл без сжатия.

crypt ★★★★★
()
Ответ на: комментарий от ist76

в смысле проверить как следует? nvidia не показывает нагрузку на ядра?

ну хотя бы просто с отключенным opencl прогони, тем более, что и так знаешь, что на твоей системе с его активацией медленнее пашет (скорее всего потому, что нечем, а почему не ругается - не знаю).

grem ★★★★★
()

Спасибо за обзорчик. Вообще, я только рисую и с фото не работаю, но сколько я не пробовал на MacOS и Linux Gimp у меня всегда тормозил. 2.10 даже не буду пробовать. ;-)

nihil ★★★★★
()
Последнее исправление: nihil (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.