Треппинг ин-рип и просто так

[sabos]

Ответ: Треппинг ин-рип и просто так

имелись в виду конструкции с pdf opacity mask

Thx, сообразил. Хороший повод подумать на досуге.

 

[1998]

Ответ: Треппинг ин-рип и просто так

Коллега, я попытался. Но увы, я уже не тот молодой и сообразительный организм, что в молодости , я не смог увидеть четкий ответ - будет ли происходить треппинг например в ситуации path+transparency->image (path+forms+transparency->image). Может уважите тугодума? Или known limitation у Kodak'a - очень страшный секрет?

Виноват, сразу не доехал (молодой, но несообразительный огранизм). На завтрак у моего РИПа (он еще не знает) будет Ваш "Test APPE IRT with Transparency.pdf". По идее, результат будет положительный во всех случаях. С учетом, конечно, limitation'а механизмов треппинга pdf2pdf Creo/Heidelberg. Э-ээ, я вообще-то никак не аффилирован с Кодаком и его секретами

Здесь какое-то недопонимание. ...

Значит, так

 

[1998]

Ответ: Треппинг ин-рип и просто так

"Test APPE IRT with Transparency.pdf" + Prinergy trapping

 

[/Alexander]

Ответ: Треппинг ин-рип и просто так

Тогда уж "до кучи" еще три варианта.

с уважением,
Александр

 

[BravO]

Ответ: Треппинг ин-рип и просто так

Я надеюсь уважаемый Олл меня простит, но позволю себе небольшое замечание (скорее всего я рискую повторить слова ув. Sabos):
RIP - это ведь растровый процессор, основная задача которого сгенерировать растр (bitmaps) - ведь так?
А различные решения, позволяющие либо внедрить в PDF некий код, которым будет руководствоваться RIP при проведении операции треппинга, либо сгенерировать треппинг физически, добавлением новых векторных объектов (каких бы-то ни было – форм, масок, дополнительных слоев и т.д.) RIPом по сути своей не являются, не имея на выходе битовых карт с растром.

С другой стороны (если я не прав – поправьте плиз) RIP рассчитывает треппинг ДО непосредственно операции screening (растеризации). Но при расчете треппинга учитывает параметры растеризации (формы растровых точек и т.д.).
Т.е. можно скатиться до обсуждения абсолютно всего софта, который позволяет так или иначе реализовывать расчет и применение треппинга.
Но тема обсуждения называется In-RIP треппинг, что подразумевает рассмотрение реализации и расчета треппинга непосредственно программой RIP, на основе предопределенных условий, так или иначе переданных RIPу вместе с файлом, который необходимо обработать.

Поэтому я бы предложил продолжить обсуждение темой, более актуальной для «широкого» применения: особенности реализации In-RIP треппинга движком APPE в различных решениях, и другими движками (напр. Global Graphics Harlequin v.8), способными «напрямую» интерпретировать PDF (напр. начиная с версии 1.6) с прозрачностями с высокой степенью получения ожидаемого результата, имея битовые карты на выходе.
Было бы интересно услышать мнения именно на эту тему, ибо в самом ближайшем времени практически все производители ПО будут активнейшим образом продвигать именно APPE-подобные движки-интерпретаторы. Более того рано или поздно CPSI-подобные движки уйдут на свалку (обоснованное IMHO – имеется ввиду обработка «разложенного» PS, напрямую сгенерированного из программ формирования макетов).


Не по теме:
Сорри, может оффтоп: Также, может кто разбирался с механизмом реализации APPE – было бы интересно каким именно образом движок обрабатывает PDF и на каком этапе происходит расчет треппинга.

P.S. На днях будет Apogee PrePress (ApogeeX v.6 (не кандидат релиз, правда) с APPE2, где AGFA пообещала повысить производительность в два раза и заимпрувить отработку треппингов с комбинациями прозрачность+оверпринт (по словам девелоперов - оверпринт они каким-то образом "дорабатывают" сами - до передачи интерпретатору). Если интересно – можем попробовать.

 

[sabos]

Ответ: Треппинг ин-рип и просто так

2 1998 /Alexander
Спасибо. Позволю себе небольшой комментарий.

Все четыре варианта справились с простеньким тестом.

Во всех четырех вариантах треп-элемент сильно заметен, не видно работы механизмов понижения заметности (ink reduction, trap color reduction, trap color scaling). Не сомневаюсь в том, что они есть - видимо по-умолчанию отключены.

Удивило то, что ни Prinergy, ни Esko не сделали "скользящего" треппинга на градиенте. Там градиент специально подобран так, что в начале он светлее фона (требуется spread), а в конце темнее (требуется choke). Harlequin sliding выполнил правильно.

Позабавил разнобой с формой треп-элемента. Одинаковый глюк и у Prinergy, и у Esko - похоже одного происхождения наши товарищи.

 

[/Alexander]

Ответ: Треппинг ин-рип и просто так

Во всех четырех вариантах треп-элемент сильно заметен, не видно работы механизмов понижения заметности (ink reduction, trap color reduction, trap color scaling). Не сомневаюсь в том, что они есть - видимо по-умолчанию отключены.

Естественно есть.
Но упаковщики ink reduction недолюбливают .

Удивило то, что ни Prinergy, ни Esko не сделали "скользящего" треппинга на градиенте.

Уточню: я приложил результаты для двух вариантов треппинга от Esko: у 4Stage "уши растут" от Artwork (на текущий момент с некоторыми вариациями работает в ArtPro, Nexus, Odystar), ColorStitch -- родной Esko (PackEdge, DeskPack, Backstage).
Оба вариант sliding делать не умеют.
Обещан, правда, в последней версии 4Stage для Odystar, но руки проверить не дошли...
Опять же, консервативные флесо-пользователи на sliding смотрят с сомнением: у меня есть установки растрового треппинга Nexus -- так sliding, не сговариваясь, отключают.

Позабавил разнобой с формой треп-элемента. Одинаковый глюк и у Prinergy, и у Esko - похоже одного происхождения наши товарищи.

Меня больше позабавило, что у программистов Artwork и Esko оказались разные предпочтения в этом вопрсе. Как будно "в пику" друг-другу...

Впрочем, я с настройками сознательно "не шаманил". Сделал все "по умолчанию".

с уважением,
Александр

 

[sabos]

Ответ: Треппинг ин-рип и просто так

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

Результаты треппинга "народными" методами:
1. Встроенный треппинг Indesign. Учтите то, что Indes здесь "сплющил" прозрачности перед треппингом.
2. Heidelberg PDF Toolbox. Ему бы "сплющить" также не помешало.

 

[1998]

Ответ: Треппинг ин-рип и просто так

Prinergy не делает sliding. Я, выше, заранее оговорился об ограниченниях механизмов Creo/Heidelberg (вот уж кто одного происхождения), это один из них. Color reduction я обычно выключаю (если печатня заказывает треппинг 30 мкм, то какой тут reduction), но в моем примере он был включен для максимального подобия другим примерам в теме. И, как можно заметить, Creo/Heidelberg не делают reduction, если один из объектов в паре -- image

 

[sabos]

Ответ: Треппинг ин-рип и просто так

Prinergy не делает sliding ... Creo/Heidelberg (вот уж кто одного происхождения)

Thx, сообразил. Да, у Heidelberg-алгоритма еще со времен DeltaTrap лишь слабенький centerline был для борьбы со скачками.

если печатня заказывает треппинг 30 мкм

Маньяки однако .

Color reduction у Heidelberg также мне не нравился. Там очень простенький алгоритм, он часто лажает.

Я PDF Toolbox 4 заставить обрабатывать объекты с прозрачностью не смог - похоже некоторая разница между Creo/Heidelberg все же есть.

 

[TRANTOR]

Ответ: Треппинг ин-рип и просто так

похоже некоторая разница между Creo/Heidelberg все же есть.

Может быть Creo предварительно сплющивает? Втихомолку.

ЗЫ. А уж не по битмабу (contone) ли трепит Арлекин? Как-то ему "по-барабану" получаются все прозрачности. Особенно если учесть, что 7-я версия напрямую их держать не обязана.

 

[sabos]

Ответ: Треппинг ин-рип и просто так

Может быть Creo предварительно сплющивает?

А потом расплющивает взад? Нетрудно увидеть, что transparency 90% сохранился (у form).

А уж не по битмабу (contone) ли трепит Арлекин?

Треппить внутри битмапа(within image) нереально - результат сильно напоминает блур. Возьми шоп и поэкспериментируй с его trap.

 

[TRANTOR]

Ответ: Треппинг ин-рип и просто так

А потом расплющивает взад?

Виноват: поторопился с предположением (так и есть - прозрачность на месте).

Возьми шоп и поэкспериментируй с его trap.

Как раз попробовал (вложения).

Не, я согласен, что у ФШ трепинг "детский" и с артефактами. Но может у Арлекина "взрослый"? Можно же антиалиасинг не делать, например. И фильтрацией добиться нужного распознавания пар для трепинга. Как говорится, почему нет?

 

[/Alexander]

Ответ: Треппинг ин-рип и просто так

Треппить внутри битмапа(within image) нереально - результат сильно напоминает блур.

It depends...
Если изображение "синтетическое" (мультяшное или вроде комикса) -- еще как реально.
Я даже рисовал по запросу пользователей Nexus workflow с подобным треппингом (TIFF на входе и выходе).

Но может у Арлекина "взрослый"? Можно же антиалиасинг не делать, например. И фильтрацией добиться нужного распознавания пар для трепинга. Как говорится, почему нет?

Фантазии могут далеко завести.

Первоисточник (http://www.globalgraphics.com/products/trapping/) вполне недвусмысленно сообщает: "The TrapPro object-based ..."
И это утверждение не противоречит тому, как RIP себя ведет при обработке задания и что пишет в логи...
Проверить, какой именнго механизм (объектный, растровый, или гибридный) использует тот или иной алгоритм треппинга можно довольно простыми средствами -- подать на вход заведомо некорректные данные.

с уважением,
Александр

 

[niki81]

Ответ: Треппинг ин-рип и просто так

2 TRANTOR
Вы так убедительно говорили товарищ, что мол пдф тул бокс вычисляет ТВ попиксельно и даже прилагали файл, ну так вот
>Что-то же он по ходу дела для трепинга справа добавляет? И оно разное такое...

А это то же самое, такая же картиночка с градиентом с вычитанным каналом
никакого измерения ND попиксельно PDF toolboks на картинках не производит
еще раз могу повторить это )))

 

[niki81]

Ответ: Треппинг ин-рип и просто так

2 sabos
Вы меня удивляете....

Здесь хотелось бы уточнить нашу терминологию.

Сперва о понятии "ин-рип". Это однозначное понятие, говорящее о том, что треппинг идет внутри рипа. При всем уважении к Prinergy Trap Editor, Prinect PDF Toolbox, DeltaTrap и прочих PressTouch - "ин-рипом" я назвать их не могу.

Второе. Sliding Trap - это вид треппинга двух объектов, при котором один из них (или оба) имеет переменный ND. Типичный такой объект - градиент (shading). В такой паре вполне возможна ситуация, когда происходит скачек spread->choke, он визуально сильно заметен, его нужно прятать. Как это происходит, можно увидеть в моем
В вашем исследовании треппинга таких пар не обнаружено. Соответственно, не на чем делать "тесты на sliding trap". Если же вы интересуетесь треппингом по пестрым подложкам-изображениям

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

Более того там отчетливо виден sliding trap в исполнении MD 7.0
отриповано на 2 движках CPSI и АРРЕ

APPE по сравнению с CPSI неправильно обрабатывает прозрачности (цветовой сдвиг) и пропускает их при треппинге (единственное различие кста)

В архиве еще лежит файл обработанный pdf toolbox, специально чтобы показать беспомощность хейделевского press touch )) по сравнению с ин-рип треппингом

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

 

[sabos]

Ответ: Треппинг ин-рип и просто так

It depends...

Я догадываюсь . И даже сам применяю. Например в ситуации, когда дилетант присылает макет "из легкого Corel" в виде tiff'а, и вернуть overprint черному тексту (ставшему композитом) уже не представляется возможным.

Переформулирую: "Треппить внутри битмапа в потоке нереально".

В макетах неизбежно попадаются картинки (обычные изображения), для которых такой треппинг смерти подобен, а пояснить треп-алгоритму, что из images обрабатывать, а что нет - непросто. Часто невозможно (например нет поддержки trap zone).

 

[/Alexander]

Ответ: Треппинг ин-рип и просто так

Переформулирую: "Треппить внутри битмапа в потоке нереально".

Согласен абсолютно.
Аминь.

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

с уважением,
Александр

 

[BravO]

Ответ: Треппинг ин-рип и просто так

Вы меня удивляете....
...
APPE по сравнению с CPSI...<скипнуто>
В архиве еще лежит файл обработанный pdf toolbox<скипнуто>

Уважаемый niki81!
На мой взгляд вы пытаетесь сравнить несколько несравнимые вещи:
CPSI (PostScript Interpreter): PS in -> bitmap out
APPE (PDF Interpreter): PDF in -> bitmap out
PDF Toolbox (и прочие «псевдо-рипы»): PDF in -> PDF (CT/LV) out
Исходя из чего фраза

APPE по сравнению с CPSI неправильно обрабатывает прозрачности

Не имеет права на жизнь, ибо (читай выше) в PostScript language в принципе нет такого понятия как transparency (см. PS language reference .
Поэтому, получив PDF с массированно применяемыми прозрачностями, Вы всегда по-сути сталкиваетесь с дилеммой:
1. Обрабатывать и трепить его APPE (зная об особенностях треппинга этим интерпретатором), но получить максимально возможно корректную интерпретацию прозрачностей;
2. Обрабатывать и трепить его CPSI (зная об особенностях треппинга этим интерпретатором), но очень внимательно отследить как отрабатывается flattening (опять же зная все нюансы этой операции - а их немало), и возможность НЕ получить корректную интерпретацию макета;
3. Потрепить его чем-либо "внешним" (методом добавления новых векторных объектов, которые собственно и будут представлять из себя "треппинг"), после чего передать его APPE (решение "непоточное").

Во всех рассматриваемых случаях при реализации треппинга применяются различные механизмы, имеющие различное происхождение проблем (типов взаимодействующих объектов) и их решений. И сравнивать их IMHO все равно, что решать кто победит в сражении – слон или кит? (Поправьте плиз, если это не так.)
Как я уже говорил, IMHO, было-бы более интересным сравнить каждый из приведенных механизмов в различных реализациях (мы говорим о "поточном треппинге"). И наиболее стоящие дискуссии механизмы это PDF->"physical" trapping->PDF и PDF->APPE trapping->bitmap.

Приаттачил предложенный Вами тест обработанный "поточно" следующим образом (настройки треппинга взяты из приведенного ув. Sabos последнего примера post#48): flattening->CPSI(InRIP trap) и APPE(InRIP trap). JPEG сделаны из "склеенного" растра.
Кстати, sliding trap достаточно хорошо виден.

Хотя и считаю обработку CPSI InRIP trapping - не показательной и "несовременной" (см. мой post#45).

 

[niki81]

Ответ: Треппинг ин-рип и просто так

Bravo, вот какие дела:

На мой взгляд вы пытаетесь сравнить несколько несравнимые вещи:
CPSI (PostScript Interpreter): PS in -> bitmap out
APPE (PDF Interpreter): PDF in -> bitmap out
PDF Toolbox (и прочие «псевдо-рипы»): PDF in -> PDF (CT/LV) out

Да, естественно механизм разный, но операция одна - треппинг, поэтому и сравниваю. Получаю между прочим разные результаты, в чём и цимес )

фраза APPE по сравнению с CPSI неправильно обрабатывает прозрачности
Не имеет права на жизнь, ибо (читай выше) в PostScript language в принципе нет такого понятия как transparency (см. PS language reference .

Тут разрешите с Вами не согласиться потому что интересует меня не механизм а результат. Обрабатывает ли CPSI прозрачности? Да, по-своему, он их плющит.
PDF с массированно применяемыми прозрачностями, это моя реально каждодневная к сожалению дилемма, описана вами без прикрас. К ней и был мой тест.

1. Обрабатывать и трепить его APPE (зная об особенностях треппинга этим интерпретатором), но получить максимально возможно корректную интерпретацию прозрачностей;

Вроде концептуально все хорошо и правильно и так и хочется сделать, но присмотревшись к моему тесту, можно заметить, что АРРЕ не только пропустил треппинг на прозрачных обьектах, но и допустил цветовой сдвиг при их обработке (нижняя пара колец). Стало быть в нынешней реализации (по крайней мере в мете 7) APPE еще очень сыр и не может быть рекомендован к практике.

2. Обрабатывать и трепить его CPSI (зная об особенностях треппинга этим интерпретатором), но очень внимательно отследить как отрабатывается flattening (опять же зная все нюансы этой операции - а их немало), и возможность НЕ получить корректную интерпретацию макета;

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

3. Потрепить его чем-либо "внешним" (методом добавления новых векторных объектов, которые собственно и будут представлять из себя "треппинг"), после чего передать его APPE (решение "непоточное").

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

2 Sabos: виноват, у Вас там тоже sliding trap на нижних парах с градиентом.