Сразу предупреждаю, о существенном недостатке знаний в этой области.

Инструментарий:
R270; драйвер GutenPrint; ArgylCMS; GPlin; Сканер V700+IT8.7/2 (знаю-знаю, что это не лучшее решение).

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

Первый подход к снаряду
1. targen -v -d4 -s64 -e4 -f0 Printer
2. printtarg -v -s -iSS ...
3. scanin ...
4. printcal ....
- В итоге получаем вот такие кривые: скриншот(JPG, 800x815px, 76 KB)
- Заталкиваем их в настройки GutenPrint'а в Gimp'е, в printrc
- После этого выглядит это примерно так: скриншот1 (400Кб), или так: скриншот2 (600Кб)
- И дальше я вообще ничего не понимаю!.. Судя по предпросмотру и последующей печати - это, как бы НЕ корректирующие кривые, а кривые показывающие реальное отклонение. Т.е. кривые изменяют изображения так, как оно бы было напечатано по умолчанию, соответственно, применение этих кривых еще больше усиливают искажения.

Второй подход к снаряду
- Попытка проделать тоже самое но через GUI GPlin - привела к аналогичному результату.
- Кривые были извлечены с помощью: exportlin
- Плюс ко всему:
- - я совсем не понимаю куда вписывать поканальный Ink limit. Потому что единственный параметр с таким ключевым словом это общий "InkLimit", со значением от 0 до 6. Вписал их в Density на каждый канал - но получилось что-то совсем невразумительное.

Итог
Я явно что-то делаю не так!

Помогите кто-нибудь!

ищите метод BlackRed -а. у него кривые корректирующие закладываются в профиль.
печатать через фотошоп ( плагин Дикобраза для фотошопа ) : применяется профиль и печать гутенпринтом.

Из документации argyllcms тема Workflow without native calibration capability.
During the subsequent profiling, the calibration curves will need to be applied to the profile test chart in the process of using printtarg. Once the the profile has been created, then in subsequent printing the calibration curves will need to be applied to an image being printed either explicitly when using cctiff to apply color profiles and calibration, OR by creating a version of the profile that has had the calibration curves incorporated into it using the applycal tool.
Т.е. после получения калибровочных кривых и перед печатью, их надо "применить" к выводимым картинкам. Что делается через cctiff или профилем с внедренными "кривыми". Насколько я помню, когда их глядел, то они действительно представляют собой "реальную текущую" (тестовую) картину краскополива, а не уже скоррективанную как вам надо. Корректировку как раз делает cctiff.
И, ИМХО, со сканером у вас так и останется сдвиг в цвет на сером клине на небольшом участке

gameoff,
Нашел его сайт: http://blackred.spb.ru/
но там, соответствующий раздел в стадии разработки.

Плюс ко всему, хорошо бы OS незвисимую методику, без фотошопа и коммерческих, программ профилирования.

Опять же, при драйвере GutenPrint закладывать линеаризацию в профиль, как мне кажется, не самая лучшая идея, так как этот костыль, судя по всему, применяется для ограниченных в возможности официальных драйверов. Это хорошо демонстрирует вот этот фрагмент настройки GP: линк (400Кб).
Главное понять как правильно манипулировать полученными кривыми.
Тем более - в том же GPlin есть уникальный функционал по настойке: Density, InkLimit, и размера капли, что уже не может быть впихнуто в профиль.
Нужно только понять - как получить кривые линеаризации, а остальное уже дело техники.


parasolid
Вот в этом то весь и вопрос - нужно как-то получить корректирующую кривую, что бы внести ее в драйвер и построить потом профиль.

inspirra (10th March 2010 - 12:39 PM) писал:

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

inspirra (10th March 2010 - 12:45 PM) писал:

Вот кстати экселька блекреда как раз и получает корректирующие кривые в формате фотошопа. Правда что вы с ними потом будете делать?

ps: а что у вас такой интерес к гутенпринту? Не уж то 270-й эпсон так плохо печатает на родных дровах?

parasolid
Родные дрова запускать негде. (-; Епсон не делает дров для моей ОС.
Надо попробовать как-то найти это макрос, но боюсь он мне мало чем поможет, так как у меня кривые в CMYK, а там наверное будут в RGB, плюс еще и фотошоповские кривые. Хотя, главное алгоритм, а там может и переделать получиться. Вот только разделы на его сайте пустые.

inspirra (10th March 2010 - 02:16 PM) писал:

Понял, у вас линукс.
А вы печатаете фото в формате CMYK?

Ссылка на тему на форуме рудтп. Ищите последние сообщения в теме.

Inspirra, посмотрите вот здесь.
Может поможет.

так не ясновидящий, что не на виндовс. на счет костылей согласен, но как вводить в гутенпринт точные кривые, точнее, как их точно рассчитать, если все относительное.
если будут идее, то поделитесь.

[quote name='gameoff' post='157373' date='10th March 2010 - 07:25 PM']но как вводить в гутенпринт точные кривые, точнее, как их точно рассчитать, если все относительное.[/quote]
Ввести-то их не проблема, и получить тоже. Но проблема в том, что кривые не корректирующие, а отображающие нелинейности, т.е. их надо как-то перевернуть (просто перевернуть - положительного результата не дало).
Есть и еще одна проблема, из за которой я и затеял это пост - я плохо себе представляю вообще процесс линеаризации. Должны ли кривые содержать не только поканальную линеаризацию, а еще и баланс каналов для приблизительно-правильной цветопередачи, или эти данные берутся уже из InkLimit'ов, например как тут: скриншот (дубль) - но куда их пихать(?) - в Density, или же их тоже надо конвертировать? Опять же, если кривые содержат только лишь поканальную линеаризацию, то зеленая картинка воплне допустима, а уже цветопередача всецело ложится на профиль, но тогда зачем нужны инклимиты. Я запутался! Еще один день и я начну нервно хихикать.

Я вроде не дурак, но от нехватки знаний не могу пока зацепиться за ниточку...

[quote name='parasolid' post='157330' date='10th March 2010 - 02:29 PM']А вы печатаете фото в формате CMYK?[/quote]
Не, печатаю то я в RGB. Просто кривые и прочие настройки должны задаваться в CMYK, в драйвере (дубль) (222Кб).
За ссылку спасибо! Ссылку курю... Но пока безрезультатно.

[quote name='gameoff' post='157373' date='10th March 2010 - 07:25 PM']если будут идее, то поделитесь.[/quote]
Всенепременно.

P.S.
А вот еще такой момент не понятен... Если смотреть на приведенные мной кривые в первом посте - то возникает вопрос - как, все предлагающие услуги по удаленному профилированию, делают профили без линеаризации? Ведь такая нелинейность не позволит делать адекватные профили.

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

gameoff (10th March 2010 - 10:29 PM) писал:

любить надо в фотошопе...У меня был по молодости лет случай, когда один гламурный инженер из Подольска( Лёшей вроде звали) приехал в 98 годе настраивать минилаб...и говорит:"тебе серый сделать потеплее или похолоднее...?" мой ответ поставил его в тупик "посерее"...Надо штобы профайл передавал на печать сигналы адекватные видимому на мониторе цвету, остальное можно дофантазировать руками в ФШ.(не имхо- аксиома).

inspirra (10th March 2010 - 10:01 PM) писал:

Не так. Линеаризованная система будет позволять использовать тест-карту максимально полезным образом. Т.е., например, монаковская мишень представляет из себя равномерно разбитый куб. Но на нелинеаризованной системе равномерные входные данные перейдут в неравномерно распределенные выходные. Для системы управления цветом лучше, если выходные данные будут равномерно распределены, т.к. лучше "тестируется" система. Т.е. желательна линейная зависимость между входными и выходными данными.
Конечно, витеевато написал, надеюсь что-то понятно. Если коротко, то линеаризованная систему будет требовать меньше патчей тест-карты при том же качестве профиля, чем нелинеаризованная.
Но опять же, "вторым проходом" в аргилле (спасибо автору, а x-rite только сейчас в prism делает тоже самое) мы добиваемся того же результата, что и при настроящей линеаризации.

Дважды прочитал ветку с методикой BlackRed'а. В своем окружении применить ее конечно не смогу - как минимум, вряд ли его ексцелька корректно заработает в OпенОфисе. Но из обсуждения и самой методики, потихоньку начинает что-то проясняться в голове.

...Попробую ка я не мудрить пока с внедрением кривых в сам драйвер, а начать с коррекции профиля и внедрения в него... И если все получиться, тогда только пробовать дергать кривые в драйвере.
Через драйвер важно потому, что можно управлять краскополивом и размерами капли, так как стандартные пресеты бумаги, не дают необходимого результата (одни переливают, другие недоливают).

2 parasolid,
Да, это я примерно представляю. Наверно я не совсем корректно выразил недоумение... Просто, если отклонения достаточно резки, то патчей надо уж шибко много, и надо что бы они еще скучковались в местах отклонений. (если я вообще правильно понимаю это)
Собственно, эти мысли были к тому, что если я сделаю линеаризацию посредством сканера, а потом пошлю патчи на промер - это будет куда лучше чем просто патчи, без предварительной линеаризации хотя бы сканером.

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

gameoff
Я наверное не очень объяснил. Дело в том, что кривые в этом случае будут не в профиле, а в самом драйвере - т.е. я получаю именно новое, независимое, линеаризованное, устройство (настройки+бумага+чернила) и на нем уже печатаю мишень и посылаю на промер. В этом-то и состоит преимущество gutenprint'а, в котором изначально заложено, что он должен быть линеаризован в виду своей универсальности. И в этом случае, профилирование линеаризованного, пусть даже сканером, условного устройства - даст в разы лучший результат.

а сканер кто линелизовал ? он тоже весьма далек отлинейности. сканером свою нелинейность добавит.
можно конечно попробовать ...

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

ждемс результата от эксперимента ( буду весьма рад, если получится ). удачи !

В общем убил я неделю и ничего-то у меня пока не вышло.

Линеаризовать в режиме "Uncorrected" не получается, так как сильно теряется динамический диапазон.
А вот в "Raw" режиме, теоретически, можно получить качество на не оригинальной бумаге и чернилах, если не сопоставимое с оригиналами, то достаточно близкое. Плюс ко всему тонкая настройка в "Raw" позволяет печатать на проблемной бумаге, даже которая сильно дыбется (в моем случае, это 100гр. двухсторонний ломонд), за счет точного регулирования лимита чернил (точность регулирования в диапазоне 0-65536). Да и можно было бы создавать супер-точные xml-конфигурации не просто под принтер, а под всю связку: принтер/конкретные_чернила/конкретная_бумага.

Но! Просто так взять и линеаризовать в Raw не получится, а точнее - невозможно... Предварительно, как минимум, необходимо: а) вычислить соотношение размеров капель; б) соотношение lite'овых чернил к темным; в) определить Ink_Limit'ы для бумаги/разрешения и т.д.

Половину времени я только искал и читал как это сделать... Ссылки и выборка из майл-листов основного разработчика и активных участников и известных разработчиков других пересекающихся проектов я собрал тут:
http://docs.google.c...9g5_149fmtrsrcp (С правленым машинным переводом. Ниже расположены наиболее старые посты)

Но все оказалось гораздо сложнее чем я предполагал. Так как нет оф. документации по генерации pattern'ов, то приходится разбираться экспериментально, на что уходит уйма времени. Например, я так и не понял, как вычислить Drop Size если требуется ограничить Ink Limit'ы - что бы понять окончательно надо было напечатать еще с десяток тестов. Либо необходимо хорошо знать английский и помучить девелопера вопросами.

Может быть кто-нибудь, у кого есть ресурс, смог бы написать отлаженную пошаговую инструкцию к пред-линеаризации "Raw" режима?