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)

Возросла производительность != стал быстрым. Это значит, что он тупит меньше старых версий.

Vsevolod-linuxoid ★★★★★
()

Пожалуйста скажите, какому именно богу надо принести человеческую жертву, чтобы такая настройка появилась в Preferences.

Линуксовому: https://image.ibb.co/kQNYTc/1.jpg - в линуксе все настройки есть

Странное номер раз: USM c радиусом 3 и силой 2 на том же изображении считался 4 минуты 45 секунд. Дольше, хотя радиус не 1000 а 3.

Возможно упирается в ввод/вывод, да и если там fft таки завезли то радиус уже не должен влиять

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

Линуксовому: https://image.ibb.co/kQNYTc/1.jpg - в линуксе все настройки есть

У меня оно tile cashe size и я, похоже затупил, поставил 16, вот оно и 16.

Возможно упирается в ввод/вывод, да и если там fft таки завезли то радиус уже не должен влиять

Ну а 15%cpu? Три ведь канала, неужели нельзя каждый канал отдельным потоком соответственно, на отдельном ядре) считать?

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

Обалдеть. Поставил 25гиг для кэша, и та же задача - блюр1000 за 2 минуты 40 секунд, без сваливания в своп.
Чтож, теперь пользователям гимпа остается порекомендовать иметь в системе 64 гигабайта оперативной памяти. А то, тут спрашивают, зачем на десктопе больше двух гигов. Вот зачем!!!!

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

Ну а 15%cpu? Три ведь канала, неужели нельзя каждый канал отдельным потоком соответственно, на отдельном ядре) считать?

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

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

Поставил 25гиг для кэша, и та же задача - блюр1000 за 2 минуты 40 секунд, без сваливания в своп.

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

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

Может, у меня собрано так, что процессор не может весь взять. Не знаю.

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

31 секунда, при загрузке процессора 51% (привет гипертрединг) и 7,5 гигах занятой оперативной памяти
Я не думаю, что стоит их сравнивать

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

Надо понимать, что это первый релиз, все кишки новые.

Жди след релиза. Ну или хотя бы через пару мелких багфикс релизов попробуй.

Со временем оно станет лучше.

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

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

В любом случае пока фотошоп, на линуксе не работает 8)

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

Фотошоп пишут за зарплату и большой командой. Не всегда хорошо (как будто в опенсорсе всегда хорошо пишут), но тем не менее. «Догнать и перегнать» не получится. Но сделать хороший, работающий софт, я считаю, возможно. В чём-то и сейчас вполне работоспособно.

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

В чём-то и сейчас вполне работоспособно.

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

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

Да вот чорт знает. Видишь, 4к мониторы вполне себе в обращении, 8к анонсированы. Пройдёт несколько лет и они будут, а у кого-то будет два, а того и три, может через 10 лет, а может через 15. 3 по 8, это 24к в длину, это только панорама, камер таких пока на свете не очень много. Железо к тому времени появится, а вот нынешние снимки на таком триптихе будут смотреться вяло.

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

Пока еще упирается в матрицы камер и оптику. Я беру и почти всегда уменьшаю в два раза картинку, потому что попиксельно там обычно пичалька, это на 24мп.

С другой стороны народ обычно картинки смотрит со смарфона. В жж всё тухло, например, а во вконтактике просмотров больше, хотя френдов меньше (чуть ли не в пять раз). А для мобил все эти пиксели не нужны, даже если там 1000dpi будет, один хрен, глаз столько не разрешает.

Короче, я полагаю, что размер фоточек конечно расти будет но не так быстро, так что гимп всяко успеет 8)

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

Так то да.
А вот был у меня никон д40 разрешением 3000x2000, да ещё, под настроение, я мог при сохранении в жопег, ресайз сделать на 50% по стороне. И нормально было, а сейчас такие снимки даже для Инстаграма маловаты.

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

Люблю смотреть, как долго и упорно гимп создаёт копию слоя размером в несколько гигабайт при какой нибудь простейшей операции вроде копирования. На ноуте с 2Гб памяти, разумеется... И даже не могу сказать, что он не прав. Я вроде как сам попросил его.

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

Как всегда, для тестирования взят битмап чуть ли не больше оперативки. Мне очень интересно, насколько хорошо он научился задействовать несколько ядер при при достаточной памяти, скажем когда размер изображения не больше 20% ОЗУ.

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

Да, кстати, а какой размер битмапа? А то заявленные цифры ,если их перемножить, дают чуть больше 530М, но это меньше сжатого файла 1,4Гб. Даже если 16 бит это не весь цвет, а 4 канала по 16 бит, то 2Гб. Или 8 копий слоя чтобы занять лимит в 16 Гб.

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

Почему ты умножаешь на 16, когда 16bits => 2bytes, тебе ведь нужно вычислить занятую оперативку, не? А, туплю, ты же дальше множишь на 1024^3.

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

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

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

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

Разупорись, кисть в 1000px часто используется для масок

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

в смысле, неадекватные?
вот я снял мелкую предметку
пошарпил изображение целиком
так как это мелкая предметка, вся она в ГРИП не влезла, а шарпить боке, это надо быть действительно больным
вот я масочкой делаю пошарпленным только резкое
2-3 маска кистью 1k-2k
это нецелевое применение растрового редактора, серьёзно?

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

да, только оператива на порядок так и.

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

mos ★★☆☆☆
()

прорисовки

Размытие

так я не понял, разве не видюха должна этим занимаца и пихать всё в свою память? должно быть пофиг на ЦП и оперативу же, вроде как.

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

Щаз мозг вроде очнулся…

множишь

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

4 — это количество каналов?

(36553*7503*4*2)/(1024^3)=2.04

Но это только на исходное изображение, не считая undo history, памяти на все подгруженные/используемые модули и прочее.

Можно одним только undo history уложить комп на лопатки, вне зависимости от параметров исходного изображения (но сильно зависит от размера холста и налагаемых эффектов).

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

4 — это количество каналов?

Да, я полагаю RGBA, но не факт, что гимп его добавляет по умолчанию.

И там же ещй не сплошной массив, а тайлы (интересно, фиксированного размера?), значит есть некие накладные расходы.

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

может и хочет, он же не говорит ничего
тут кроме меня никто особо не хвастается, у меня вот видимокарта не используется, как у других я не знаю

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

Да, я полагаю RGBA, но не факт, что гимп его добавляет по умолчанию.

При экспорте файла, формат которого не подразумевает прозрачность, идёт всё же три канала, но не обязательно RGB (впрочем, GIMP всё же предлагает экспортировать в sRGB). Об остальных я знаю совсем ничего, ибо не углублялся.

значит есть некие накладные расходы.

Они всегда есть. Та же palette, например.

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

Я конечно понимаю, что тут все крутые фотографы с беличьими хостами.

Но я всё же о чём-то простом спрошу. Оно научилось на macOS:

1) шорткаты в не англоязычной раскладке

2) не терять фокус каждый раз при сохранении файла (когда не возможно нажать кнопку без переключения на общую панораму стола и обратно)

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

Опять тебя куда-то не туда. Экспорт файла не имеет никакого отношения к тому что там внутри гимпа.

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

Оно научилось на macOS:

У вас там фоточки не в чем редактировать шоле?

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

ладно, там новость что они 3.0 начали делать на гтк3, как выкатят трёшку там опробую.

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

Опять тебя куда-то не туда.

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

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

А вот, кстати, взял 36мп кадр и он у меня поблюрился в 1000 за 12 секунд. И Загрузка процессора даже под 40 скакнула одномоментно.
Но кисти всё равно неприемлимо медленные.
Но вообще - круто.

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

Бессмысленный вопрос. Смотря что открыть, смотря что с этим открытым делать.
Запущенный без ничего - 138MB
С открытым 36МП изображением в 16битном цвете (tiff весит 218) - 816MB
После применения фильтра - 1622MB

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

я не представляю нахрена вообще брать 4-ре разных задачи

Выходные не бесконечные…

еще и болтать с кем-то

Но, всё же, выходные.

r3lgar ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.