Комментарии 67
Очень интересная статья, спасибо!
Тоже давно работаю исключительно в Linux. Сейчас работаем с графикой (фото) и Linux прекрасно справляется почти со всеми задачами (одной единственной софтине не удалось найти достойного аналога, хотя таковые есть, и потому только из-за неё на одном из компов в офисе стоит Win. Больше на нём ничего нет (даже антивируса) — какое расточительство :()
Хотя похвастать особо не чем. Из основных инструментов используются Gimp, ufRAW, enblend, на bash написано несколько скриптов для автоматизации рутины, torrent`ы, которые так невзлюбили правообладатели, тоже помогают, когда надо передать несколько GB фоток через пол страны.
Ещё в работе очень помогает mpd, стоящий на линуксовой же файлопомойке и крутящий через хорошую акустику различные радиостанции.
Тоже давно работаю исключительно в Linux. Сейчас работаем с графикой (фото) и Linux прекрасно справляется почти со всеми задачами (одной единственной софтине не удалось найти достойного аналога, хотя таковые есть, и потому только из-за неё на одном из компов в офисе стоит Win. Больше на нём ничего нет (даже антивируса) — какое расточительство :()
Хотя похвастать особо не чем. Из основных инструментов используются Gimp, ufRAW, enblend, на bash написано несколько скриптов для автоматизации рутины, torrent`ы, которые так невзлюбили правообладатели, тоже помогают, когда надо передать несколько GB фоток через пол страны.
Ещё в работе очень помогает mpd, стоящий на линуксовой же файлопомойке и крутящий через хорошую акустику различные радиостанции.
Если не секрет, чему не нашлось аналога?
PTGui
Про hugin знаю и довольно долго даже пытались пользоваться им. Но он очень медленный, есть проблемы с поиском контрольных точек и сведением панорам, проблемы с распознаванием объективов, интерфейс в PTGui удобнее гораздо. В итоге пришлось выделять целый компьютер под единственную программу.
Под вайном ptgui работает отвратительно, к сожалению. Такие дела.
Про hugin знаю и довольно долго даже пытались пользоваться им. Но он очень медленный, есть проблемы с поиском контрольных точек и сведением панорам, проблемы с распознаванием объективов, интерфейс в PTGui удобнее гораздо. В итоге пришлось выделять целый компьютер под единственную программу.
Под вайном ptgui работает отвратительно, к сожалению. Такие дела.
Спасибо за отличную статью!
Хорошая статья. Только вместо ufRAW рекомендую использовать darktable. Там намного более мощные инструменты и интерфейс удобнее, если привыкнуть.
Разрыв шаблона. Когда слышу «Linux для профессионалов» — сразу думаю о написании скриптов, настройки системы, сборки ядра. Но никак не о векторной графики! Я понимаю, что весь этот софт под линухами крутится… Но все же!
В действительности так было не всегда, когда я в 93-м начинал свой «дизайнерский путь», я с коллегами время от времени посещал разные выставки компьютерной графики. Так вот, все, кто в ту пору представлял что-либо наиболее значащее и достойное упоминания — все они работали на SG. И там стоял самый что ни на есть Unix.
Для нас, жалких пользователей PC это все выглядело, как запредельная невиданная фантастика. А люди, которые делали графику на SG для кино, виделись полубогами.
Позднее эту нишу стали постепенно занимать Mac-и, сперва как паблишинг системы, потом и как графические станции. И только к концу 90х народ стал более-менее активно использовать PC под Windоws для создания компьютерной графики.
Для нас, жалких пользователей PC это все выглядело, как запредельная невиданная фантастика. А люди, которые делали графику на SG для кино, виделись полубогами.
Позднее эту нишу стали постепенно занимать Mac-и, сперва как паблишинг системы, потом и как графические станции. И только к концу 90х народ стал более-менее активно использовать PC под Windоws для создания компьютерной графики.
с редуцированным разрешением растровой графики.
не надо так с утра выносить мой мозг…
Это очень, очень и очень хорошая идея!
Я как раз-таки являюсь программистом и технофриком, но в том, что касается разнообразной обработки изображений — тут я в Линуксе чувствую себя крайне неуверенно.
Я как раз-таки являюсь программистом и технофриком, но в том, что касается разнообразной обработки изображений — тут я в Линуксе чувствую себя крайне неуверенно.
НЛО прилетело и опубликовало эту надпись здесь
не знаю, не пробовал. Однако, будучи человеком не чуждым разработке электроники, могу сказать, что колориметр — не самый сложный прибор. Полагаю, что отъюстировать его — не столь трудоемкая задача и, думаю, что ребята это сделали и, наверняка, предусмотрели, как это несложно сделать при самостоятельной сборке.
За ссылки спасибо. Получилась самодостаточная подборка. Есть от чего оттолкнуться, чтоб начать большое плавание в море графики.
Еще бы вменяемый аналог Lightroom!
Поставьте уже darktable :)
А! вот еще нашел в закромах закладок волшебный софт, который я не пробовал. По всем признакам должен отвечать всем самым привередливым запросам
rawtherapee.com
rawtherapee.com
С rawtherapee как-то не сложилось,
а darktable хорош.
Еще lightzone стал open source: linuxg.net/how-to-install-lightzone-on-ubuntu-13-04-12-10-12-04-and-linux-mint-15-14-13/
а darktable хорош.
Еще lightzone стал open source: linuxg.net/how-to-install-lightzone-on-ubuntu-13-04-12-10-12-04-and-linux-mint-15-14-13/
группа энтузиастов некоторое время назад разработала отличный колориметр ColorHug,
Не знал, что Ричард Хьюс — группа энтузиастов. Ну, в принципе, чувак за троих вкалывает. Можно и так сказать, наверно :)
так он там один что ли? Уважаю!
Впрочем, суть не меняет. ColorHug — отличный проект, при любом раскладе.
Впрочем, суть не меняет. ColorHug — отличный проект, при любом раскладе.
А чем он лучше той же X-Rite или какой нибудь Datacolor Spyder?
Ценой? Или есть еще какие-нибудь преимущества?
Ценой? Или есть еще какие-нибудь преимущества?
Наличием полной открытой документации и свободной лицензией. Tы можешь купить готовый или собрать собственный ColorHug, запросто модифицировать его и даже выпускать собственный вариант.
Коль скоро мы тут обсуждаем приемущества програмного обеспечения с открытым кодом, логично упомянуть и copyleft hardware.
Коль скоро мы тут обсуждаем приемущества програмного обеспечения с открытым кодом, логично упомянуть и copyleft hardware.
Ну и кстати:
Да щас! Для кого, спрашивается, АлистерКроули Робинсон бессонными ночами писал цветоуправляемый Photoprint? :)
Справедливости ради, стоит отметить, что все тонкие настройки по-прежнему доступны только в Gimp плагине
Да щас! Для кого, спрашивается, Алистер
Спасибо, очень полезно. Осваиваю сейчас открытые программы для архитектуры, ибо если открывать свою фирму, то софт — самое дорогое судя по всему…
Отличное начинание! Я сам давно работаю только на Linux (был и Win и Mac юзером) и понял, что разноплановые и комплексные задачи нигде больше не решаются с такой легкостью и скоростью. Хотел бы еще обратить внимание аудитории на один потрясающий и уникальный в своем роде графический редактор, который незаслуженно малоизвестен — Krita. (http://krita.org/) Так что не GIMPом единым… В принципе, в Linux сейчас есть все необходимое для полноценного «воркфлоу» в сфере дизайна и создания иллюстраций на продакшн-уровне.
Спасибо за статью! Мой опыт с предпечатной подготовкой в линуксе ограничился inkscape с экспортом в pdf, приличными цветопробами на своём принтере и разочаровывающе бледным голубым в буклетах из типографии. Ну и я так и не понял, как правильно задавать чёрный в CMYK: только про 100/100/100/100 для калибровочных меток однозначно понятно.
Inkscape понравился (работаю под Виндами), но с сохранением в CMYK так и не разобрался, подготовленный RGB-макет приходится дополнительно обрабатывать потом в Corel'е.
его надо просто конвертировать (см соседний комментарий). Сам не пробовал. Поэтому готовые советы давать не стану, но уверен, что это можно сделать.
Это весьма печально. Есть желание использовать легальный софт и перебираться на Линукс. Но пока, вижу, с этим большие проблемы.
Попробовал импортнуть в Scribus свою svg, но при сохранении из него в PDF с установленной цветовой схемой CMYK, цвета искажаются (бледные), т.е. корректного конвертирования (как в Кореле) не происходит.
Попробовал импортнуть в Scribus свою svg, но при сохранении из него в PDF с установленной цветовой схемой CMYK, цвета искажаются (бледные), т.е. корректного конвертирования (как в Кореле) не происходит.
вы, судя по всему, не очень хорошо знакомы с технологией. Поищите в сети что-нибудь по словосочетанию «цветовые профили».
Отвечу предметно но кратко: вам нужно выбрать цветовой профиль для RGB и для CMYK, после чего перевести ваши цвета в CMYK (найдите список цветов в Edit --> Colors, там будут все цвета из вашего импортированного SVG). В Corel, к слову, preview коррекции цвета по-умолчаню, отключено, если я не ошибаюсь. Если вам нравится видеть RGB цвет вместо эмуляции CMYK в Scrubus, вы можете сделать то же самое и там (кнопка справа внизу).
Я делаю дизайн (в т.ч. полиграфический) и массу чего еще исключительно в Linux вот уже более 6 лет. Без каких бы то ни было проблем.
Если говорить о проблемах: единственная проблема, которую я не решил (точнее которую я решил методом, так сказать, «костыля», покуда запускаю под wine старые версии) — это видео композинг уровня After Effects + Flash для интерактивной графики и игрушек (да и то, последнее практически уже не актуально да к тому же использую я специальный модуль, который подгружает SWFы старой версии в мой код AS3 и далее все можно уже компилировать и отлаживать нативно).
видеокомпозинг обещают допилить вот вот в Blender. посмотрим. Есть еще правда Nuke, но он коммерческий (хотя, по первому впечатлению несравненно более серьезный по сравнению с AE инструмент).
Отвечу предметно но кратко: вам нужно выбрать цветовой профиль для RGB и для CMYK, после чего перевести ваши цвета в CMYK (найдите список цветов в Edit --> Colors, там будут все цвета из вашего импортированного SVG). В Corel, к слову, preview коррекции цвета по-умолчаню, отключено, если я не ошибаюсь. Если вам нравится видеть RGB цвет вместо эмуляции CMYK в Scrubus, вы можете сделать то же самое и там (кнопка справа внизу).
Я делаю дизайн (в т.ч. полиграфический) и массу чего еще исключительно в Linux вот уже более 6 лет. Без каких бы то ни было проблем.
Если говорить о проблемах: единственная проблема, которую я не решил (точнее которую я решил методом, так сказать, «костыля», покуда запускаю под wine старые версии) — это видео композинг уровня After Effects + Flash для интерактивной графики и игрушек (да и то, последнее практически уже не актуально да к тому же использую я специальный модуль, который подгружает SWFы старой версии в мой код AS3 и далее все можно уже компилировать и отлаживать нативно).
видеокомпозинг обещают допилить вот вот в Blender. посмотрим. Есть еще правда Nuke, но он коммерческий (хотя, по первому впечатлению несравненно более серьезный по сравнению с AE инструмент).
В конце статьи выше есть ссылка на мою статью на английском про сохранение цмиковых цветов при переходе из inkscape в scribus.
inkscape не умеет экспортировать в CMYK. На выходе у него, что бы вы не выставляли в цветовых настройках, будет RGB. Отсюда и ваш «бледный голубой» :) Вы можете попробовать конвертировать полученный PDF в CMYK. Попробуйте поискать в сети по ключевому словосочетанию «PDF RGB 2 CMYK». Я натыкался, помнится, на какую-то релевантную заметку, но найти сходу не могу.
Есть latex. Что еще нужно?
Платформа, где нет возможности сделать контролируемое цветоделение растра в полноцвет или полноцвет + несколько плашечных, причем все растром, а не вектором, с заданной суммой красок и настройкой кривых по каналам, для офсетной полиграфии не подходит. Только если для цифровой.
внимательно ли вы прочли статью?
ОК, задача: в 6-секционной машине налит полноцвет, серебро и ядреный такой оранжевый пантон. Ваша задача — цветоделить растровое фото под эти 6 красок, используя только Linux.
GIMP разве поддерживает работу с полноцветом и плашечными цветами одновременно в одном документе и позволяет делать ручное цветоделение? Там можно задать кривую GCR?
И это я еще не начал про цветокоррекцию человеческой кожи…
GIMP разве поддерживает работу с полноцветом и плашечными цветами одновременно в одном документе и позволяет делать ручное цветоделение? Там можно задать кривую GCR?
И это я еще не начал про цветокоррекцию человеческой кожи…
GIMP нет. Там нет даже CMYK, как я написал. Но сделать это можно используя связку GIMP + Image Magic. Хотя, справедливости ради, нужно отметить, что без некоторых «трюков» здесь, очевидно, не обойтись. Однако, и задача, описанная вами также весьма специфическая. И да, с визуальным редактированием многоканальных изображений пока очевидных решений для Linux нет.
Я полагаю, что развитие и интерес публики к использованию ПО с открытым кодом подтолкнет разработчиков к созданию и такого рода инструментария (точнее сказать, поспособствует естественному появлению групп разработчиков, которые будут заинтересованы в решении все более специальных задач) в скором будущем, как это произошло с массой «неспецифического» ПО для Linux в последние 6-8 лет.
Вообще, чем хорошо сообщество ПО с открытым кодом — тут считается моветоном жаловаться на отсутствие софта или его «недопиленность». Не нравится — сделай лучше. Код открыт и в свободном доступе. Нет софта — ищи решение в рамках имеющегося инструментария. Нашел — поделись с сообществом. Что-то не устраивает — вот документация, вот библиотеки, разбирайся — пиши. Не хватает квалификации, но знаешь, что тебе нужно — организуй рабочую группу. В таком духе…
Я полагаю, что развитие и интерес публики к использованию ПО с открытым кодом подтолкнет разработчиков к созданию и такого рода инструментария (точнее сказать, поспособствует естественному появлению групп разработчиков, которые будут заинтересованы в решении все более специальных задач) в скором будущем, как это произошло с массой «неспецифического» ПО для Linux в последние 6-8 лет.
Вообще, чем хорошо сообщество ПО с открытым кодом — тут считается моветоном жаловаться на отсутствие софта или его «недопиленность». Не нравится — сделай лучше. Код открыт и в свободном доступе. Нет софта — ищи решение в рамках имеющегося инструментария. Нашел — поделись с сообществом. Что-то не устраивает — вот документация, вот библиотеки, разбирайся — пиши. Не хватает квалификации, но знаешь, что тебе нужно — организуй рабочую группу. В таком духе…
Мне очень нравится свободное ПО и не нравится перекос в визуальный интерфейс на PC, тогда как консоль и регулярные выражения выполняют сложные задачи за секунды вместо получаса мышкотаскания. Однако, полиграфия для профессионального применения — это на 50% сложное цветоделение под специфичекие красочность, бумагу и методы печати. В Linux, к сожалению, пока отсутствует базовая функциональность для этого. Цветокоррекция в RGB с последующим автоматическим цветоделением — гарантия предсказуемо похого результата.
Надеюсь, сообщество когда-нибудь обратит внимание на эту зияющую дырищу, а до тех пор все будут нести деньги Adobe (тяжко вздохнул и пошел обновлять подписку на creative cloud).
Надеюсь, сообщество когда-нибудь обратит внимание на эту зияющую дырищу, а до тех пор все будут нести деньги Adobe (тяжко вздохнул и пошел обновлять подписку на creative cloud).
вообще, есть мнение, что при наличии подключаемого цветового профиля необходимости переводить картинку в отличное от RGB пространство нет по определению до самого последнего момента. Покуда монитор показывает, как не крути, аддитивный RGB. А решающую роль играет глубина канала и качество профиля на выходе. В этом смысле при двойном переводе (сперва в CMYK а потом в RGB для эмулятивного отображения на мониторе) будут только накапливаться ошибки.
Так что, полагаю, наиболее верным решением для того же Gimp будет простая имплементация профилей для эмуляции отображения + крутилочки в палитру в разных цветовых координатах.
Так что, полагаю, наиболее верным решением для того же Gimp будет простая имплементация профилей для эмуляции отображения + крутилочки в палитру в разных цветовых координатах.
Так что, полагаю, наиболее верным решением для того же Gimp будет простая имплементация профилей для эмуляции отображения + крутилочки в палитру в разных цветовых координатах.
Да, примерно это и планируется. А если точнее — специальная проекция, где изображение раскладывается на любые компоненты, которые могут быть плашечными цветами, например.
А есть ли возможность пообщаться с рабочей группой? Есть уникальный шанс избежать кучи проблем, с которыми с разной степенью успешности воюет Adobe…
Да, конечно. В основном, мы общаемся на IRC. Ещё можно написать в список рассылки.
Но я заранее предупреждаю, что сейчас цмики с пантонами — малоприоритетная задача (в сравнении с доработкой нового движка и недеструктивным редактированием, например). Т.е. немедленной реакции в виде кода вы не увидите.
Но я заранее предупреждаю, что сейчас цмики с пантонами — малоприоритетная задача (в сравнении с доработкой нового движка и недеструктивным редактированием, например). Т.е. немедленной реакции в виде кода вы не увидите.
Ваше мнение довольно популярно в дизайнерских кругах и столь же нелюбимо полиграфистами.
Цветовой профиль проявляет себя в двух ипостасях: при отображении на экране и цветоделении. Для полиграфиста важно только последнее; мы можем работать на черно-белых мониторах, если очень уж припрет. В силу того, что диапазон полноцветной печати очень узок, нам очень важно, какая именно часть деталировки, к примеру, фотографии, попадет в зарезанный охват триады, который еще зависит от типа и плотности бумаги. Автоматизировать этот процесс пока, — до изобретения полноценного распознавания образов компьютером, — невозможно. Профиль (который, кстати, для каждой работы лучше делать индивидуально) — это рамки прокрустова ложа, в который мы вручную впихиваем невпихуемое.
При цветоделении с плашечными цветами, профили практически бесполезны.
Что же до профилей устроств, влияющих на отображение файла, но не на цвета в нем, полиграфиста они волнуют чуть менее, чем никак.
По-моему, то, что совершенно разные по природе вещи, одна из которых влияет только на отображение, а другая — еще и на контент, по недоразумению одинаково называются «цветовыми профилями» — источник кучи недоразумений.
Надо вообще писать про это пост на Хабр, да кармы не хватает…
Цветовой профиль проявляет себя в двух ипостасях: при отображении на экране и цветоделении. Для полиграфиста важно только последнее; мы можем работать на черно-белых мониторах, если очень уж припрет. В силу того, что диапазон полноцветной печати очень узок, нам очень важно, какая именно часть деталировки, к примеру, фотографии, попадет в зарезанный охват триады, который еще зависит от типа и плотности бумаги. Автоматизировать этот процесс пока, — до изобретения полноценного распознавания образов компьютером, — невозможно. Профиль (который, кстати, для каждой работы лучше делать индивидуально) — это рамки прокрустова ложа, в который мы вручную впихиваем невпихуемое.
При цветоделении с плашечными цветами, профили практически бесполезны.
Что же до профилей устроств, влияющих на отображение файла, но не на цвета в нем, полиграфиста они волнуют чуть менее, чем никак.
По-моему, то, что совершенно разные по природе вещи, одна из которых влияет только на отображение, а другая — еще и на контент, по недоразумению одинаково называются «цветовыми профилями» — источник кучи недоразумений.
Надо вообще писать про это пост на Хабр, да кармы не хватает…
я, по правде сказать, не очень хорошо понял ваш аргумент. Вы приводите в общем-то вполне очевидные для всех полиграфистов истины, но они не совсем коррелируют с моим предположением относительно того, как лучше и проще сделать работу с мультиканальными изображениями в Gimp.
Потом, вы сами себе противоречите в том аспекте, что вы выше пишите о «редактировани кожи», а тут приводите аргумент, мол, цвет на экране не имеет значения, можно и на ЧБ редактировать.
Я, если не возражаете, заглянул в ваш профиль. Полагаю, что кроме полиграфии вы так же пишете код. Так вот, если вы как программист задумаетесь, как алгоритмически устроена работа с цветом на каждом этапе, то вы неизбежно придете к выводу, что ключевые моменты — это конвертация цвета при преобразовании из RGB в CMYK (в CMYKcm или в любое другое пространство) + возможность эмулировать отображение с понятной долей погрешности на экране (т.е. обратное преобразование с коррекцией с коэффициентами калибровки для конкретного монитора). Профили — это и есть эти самые параметры коррекции туда и обратно. Природа у них общая. Нужды что-либо придумывать дополнительное тут нет.
Надо отметить, что в этой области циркулирует множество околомистических домыслов. Я позволю себе высказать совсем крамольную мысль. Мой опыт в полиграфии подсказывает мне, что зачастую редактура попадающих в «зарезанный охват триады» частей тела, приводит к худшему результату, нежели чем если бы все оставили без изменений. Я не хочу сказать, что нет смыла заниматься коррекцией цвета. Безусловно есть! Но есть цветокорректоры, которые доводят этот процесс до абсурда (сам с такими сталкивался). Это ни в коей мере не «камень в огород», но призыв отсечь мистику от логики.
Потом, вы сами себе противоречите в том аспекте, что вы выше пишите о «редактировани кожи», а тут приводите аргумент, мол, цвет на экране не имеет значения, можно и на ЧБ редактировать.
Я, если не возражаете, заглянул в ваш профиль. Полагаю, что кроме полиграфии вы так же пишете код. Так вот, если вы как программист задумаетесь, как алгоритмически устроена работа с цветом на каждом этапе, то вы неизбежно придете к выводу, что ключевые моменты — это конвертация цвета при преобразовании из RGB в CMYK (в CMYKcm или в любое другое пространство) + возможность эмулировать отображение с понятной долей погрешности на экране (т.е. обратное преобразование с коррекцией с коэффициентами калибровки для конкретного монитора). Профили — это и есть эти самые параметры коррекции туда и обратно. Природа у них общая. Нужды что-либо придумывать дополнительное тут нет.
Надо отметить, что в этой области циркулирует множество околомистических домыслов. Я позволю себе высказать совсем крамольную мысль. Мой опыт в полиграфии подсказывает мне, что зачастую редактура попадающих в «зарезанный охват триады» частей тела, приводит к худшему результату, нежели чем если бы все оставили без изменений. Я не хочу сказать, что нет смыла заниматься коррекцией цвета. Безусловно есть! Но есть цветокорректоры, которые доводят этот процесс до абсурда (сам с такими сталкивался). Это ни в коей мере не «камень в огород», но призыв отсечь мистику от логики.
Ремарка. Для вызова часто используемых консольных команд в терминале удобно использовать сочетание клавиш CTRL-R + фрагмент команды
Еще можно начать вводить, и жамкнуть таб. Если вероятных вариантов много — жамкнуть таб дважды — покажет все варианты.
Еще можно начать вводить, и жамкнуть таб. Если вероятных вариантов много — жамкнуть таб дважды — покажет все варианты.
Тут надо отметить, что это, если вы просто набираете единичную команду. А если вам нужна некогда набранная «батарея» с кучей параметров и тремя пайпами (pipe), то лучше поиском CTRL-R. Ключевое словосочетание «часто используемых».
Ну и в целом, нюансы использования консоли — это несколько за рамками настоящей статьи, все же.
Ну и в целом, нюансы использования консоли — это несколько за рамками настоящей статьи, все же.
UPD:
команда для замены фона в CMYK выгдялит так
convert input.tiff -colorspace cmyk -density 300 -background «cmyka(127, 0, 25, 28)» -alpha off output.tiff
спасибо pravos за подсказку :)
команда для замены фона в CMYK выгдялит так
convert input.tiff -colorspace cmyk -density 300 -background «cmyka(127, 0, 25, 28)» -alpha off output.tiff
спасибо pravos за подсказку :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Linux для профессионалов: как подготовить макет к печати в типографии