Поделитесь о фотовыводах

[JAW]

Ответ: Поделитесь о фотовыводах

sabos
А ничего, что этот модуль входит в PostScript ядро?
А ничего, что в различных материалах Adobe утверждает, что именно PostScript 3 поддерживает PDF...

Как это всё работает реально известно, но это не меняет сути...
И по большому счёту... Какая разница, какая именно DLL и как обрабатывает PDF.

 

[Rrro]

Ответ: Поделитесь о фотовыводах

А вот про прозрачности вы зря так... Прозрачностей хватает в дизайнах, так что поддержка прозрачностей (или хотя бы корректное сплющивание) - это уже необходимость.

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

 

[/Alexander]

Ответ: Поделитесь о фотовыводах

А считает прозрачности без сплющивания только PDF Engine.

и все RIP на ядре Harlequin
Впрочем, практическая полезность прямого растрирования прозрачностей, IMHO, почти нулевая.

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

 

[sabos]

Ответ: Поделитесь о фотовыводах

А ничего, что этот модуль входит в PostScript ядро?

А ничего, что PostScript ядро успешно работает без этого модуля?

А ничего, что в различных материалах Adobe утверждает, что именно PostScript 3 поддерживает PDF...

Еще раз - маркетологи в своих сказочных мирах.

Постскрипт - это язык. Язык состоит из набора команд. Определенного набора. В этом наборе нет "прозрачностей", нет PDF-объектов, нет "управления цветом" (icc), нет треппинга, нет спуска полос, нет workflow. Но мы можем с помощью языка постскрипт выполнить многое из перечисленного. И это не значит, что какой спуск полос "входит в PostScript ядро". То, что библиотека PDFToPS.dll лежит рядом с интерпретатором, еще не значит, что она туда "входит". Это значит лишь то, что дельта (как и многие другие) конвертирует pdf в ps перед интерпретацией. По аналогии с печатью из акробата в ps-принтер. На этой стадии происходит и сплющивание прозрачностей. Учить матчасть.

В тоже время PDF Engine обрабатывает pdf без конвертации и без сплющивания. Есть ли в этом смысл?

практическая полезность прямого растрирования прозрачностей, IMHO, почти нулевая.

У меня уже есть реально работающие проекты с PDF Engine. Статистика за три месяца - вывод (DQS-спуск) современного журнала из Indes, нашпигованного "высокими технологиями" - занимает вдвое меньше времени по сравнению с подобной цепочкой PDF Ready, и втрое-всемеро меньше времени по сравнению с обычной Normalizer-цепочкой. Ненулевая.

 

[TRANTOR]

Ответ: Поделитесь о фотовыводах

APPE - весчь хорошая. Голова болит меньше, а рип работает быстрее.

 

[zmeionline]

Ответ: Поделитесь о фотовыводах

sabos

Это так. Все рипы (в т.ч. и дельта), что построены на базе CPSI, являются постскрипт-интерпретаторами. И не более того. Постскрипт не имеет такого понятия, как "прозрачность", соответственно, поддерживать его могут лишь маркетологи в своих сказочных мирах. Если лень читать документацию, то просто подумай, чем занимается модуль PDFToPS.dll.

А как же Rendering?

 

[/Alexander]

Ответ: Поделитесь о фотовыводах

Статистика за три месяца - вывод (DQS-спуск) современного журнала из Indes, нашпигованного "высокими технологиями" - занимает вдвое меньше времени по сравнению с подобной цепочкой PDF Ready, и втрое-всемеро меньше времени по сравнению с обычной Normalizer-цепочкой. Ненулевая.

Искренне рад за пользователей. Но готовы ли Вы гарантировать, что это соотношение будет справедливо для всех входных заданий? А если цепочка будет PS -> TIFF -> спуск на растре? Имеет шансы оказаться еще эффективней.

Впрочем, дело даже не этом - я говорю о полезности прямого растрирования прозрачностей, а не полезности перехода на новое ядро. Есть разница. Согласитесь, было бы странно, если бы новое ядро работало медленнее старого?
Тот факт, что новое ядро быстрее рендерит, объясняется скорее тем, что адобовские программисты научились использовать доступную оперативную память.
Как я уже говорил, прямое растрирование прозрачностей работает в Harlequin или Nexus уже не первый год. Распределять память программисты Global Graphics и Artwork научились раньше адобовских , так что оба варианта растрирования (и прямого на PDF, и через PS) оказались в равных "стартовых" условиях. Да - для некоторых заданий PDF растрирование быстрее, но это истина не фундаментальная - есть много примеров, доказывающих обратное.
В контексте моего ответа "полезность" - не только скорость, но и функциональность. Вырастет она от перехода на прямое растрирование PDF? Пока вижу, что наоборот - снижается.

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

 

[Scorry]

Ответ: Поделитесь о фотовыводах

кто-нибудь работал с этим рипом?
вообще главное это не скорость а надежность

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

 

[sabos]

Ответ: Поделитесь о фотовыводах

А как же Rendering?

Так же, как и Screening

Но готовы ли Вы гарантировать

Я редко что готов гарантировать. Гарантии в Госстрахе .

А если цепочка будет PS -> TIFF -> спуск на растре?

DQS и есть спуск в растре.

я говорю о полезности прямого растрирования прозрачностей, а не полезности перехода на новое ядро. Есть разница.

Есть.

Согласитесь, было бы странно, если бы новое ядро работало медленнее старого?

Не соглашусь. Одно из второго не следует. Если обобщать новое->лучшее, то чаще наблюдаю обратное.

но это истина не фундаментальная

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

В контексте моего ответа "полезность" - не только скорость, но и функциональность. Вырастет она от перехода на прямое растрирование PDF? Пока вижу, что наоборот - снижается.

Потери функционала не увидел. Изучал лишь два решения, но ни в мете, ни в апогее потери функционала нет.

Если разбирать детально, то прирост производительности наблюдается в трех местах - нет конвертации в ps и сплющивания, нет дополнительных объектов (порожденных сплющиванием) -> быстрее треппинг, нет дополнительных объектов (порожденных треппингом по объектам, порожденным сплющиванием) -> быстрее интерпретатор.

Я не собираюсь устраивать религиозные войны ps-pdf. Я знаю, как подготовить "лаконичный" ps, который пролетит сквозь рип с огромной скоростью. И знаю, что представляет собой макет «современного журнала из Indes, нашпигованного "высокими технологиями"». И стараюсь смотреть трезво на эти вещи.

 

[/Alexander]

Ответ: Поделитесь о фотовыводах

DQS и есть спуск в растре.

Я в курсе.

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

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

Потери функционала не увидел. Изучал лишь два решения, но ни в мете, ни в апогее потери функционала нет.

Не буду приводить весь список "Limitations" из release notes ApogeeX 4. Ограничусь упоминанием PDF Trapper.
Еще упомяну такую категорию "полезности", как надежность.
И про стоимость решения давайте не забывать - потребности нового ядра в памяти выше, а разница в цене standard и enterprise windows заметная. А если требуется хотя бы от некоторых заказчиков регулярно принимать PS - будьте добры занести денег за вторую копию рендера! CPSI у ApogeeX, конечно же, в комплекте, только вот одновременно с APPE работет при наличиии отдельной лицензии.

Если разбирать детально, то прирост производительности наблюдается в трех местах - нет конвертации в ps и сплющивания, нет дополнительных объектов (порожденных сплющиванием) -> быстрее треппинг, нет дополнительных объектов (порожденных треппингом по объектам, порожденным сплющиванием) -> быстрее интерпретатор.

Если разбирать детально, то сразу возникают вопросы. DiapalyList создается? Возможно параллельное порождение из него сепараций несколькими одновременно запущенными копиями рендера? Не эффективнее ли выполнять треппинг ДО расчета прозрачностей? Не эффективнее ли треппинг выполнять на растре? Не эффективнее ли расчет прзрачностей не перекладывать на рендерер, сознательно создавая "узкое место", а выполнять на рабочих станциях при генерации PDF.

Я не собираюсь устраивать религиозные войны ps-pdf.

Понимаю. Поддерживаю.

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

 

[igors]

Ответ: Поделитесь о фотовыводах

Я не собираюсь устраивать религиозные войны ps-pdf. Я знаю, как подготовить "лаконичный" ps, который пролетит сквозь рип с огромной скоростью. И знаю, что представляет собой макет «современного журнала из Indes, нашпигованного "высокими технологиями"». И стараюсь смотреть трезво на эти вещи.

Sabos я знаю Вас только по форуму, а /Alexander я знаю боле 10 лет, я не знаю в России более знающего человека, чем он в вопросах совремменого workflow. Он знает PS, легко пишет на нем, он главный специалист в Россиии по подуктам Artwork System, и я думаю в реалиализациях Адобовских подходов, но дело не в этом. Пока я не вижу предмета спора.

 

[sabos]

Ответ: Поделитесь о фотовыводах

igors, я думаю что /Alexander в этом разговоре поддержка (да еще такая) не нужна. Мы лишь уточнили позиции. И похоже согласились в том, что обобщать наши частные случаи на всю индустрию не станем. Есть места, где "практическая полезность прямого растрирования прозрачностей" почти нулевая, есть места, где ненулевая. Здесь нет спора, как и нет его предмета - простой обмен мнениями.

 

[sabos]

Ответ: Поделитесь о фотовыводах

Не буду приводить весь список "Limitations" из release notes ApogeeX 4.

Замечание принимается.

И про стоимость решения давайте не забывать - потребности нового ядра в памяти выше, а разница в цене standard и enterprise windows заметная.

Замечание принимается. Впрочем, скорость всегда стоит денег. Использование 4-8 cpu в т.ч.

А если требуется хотя бы от некоторых заказчиков регулярно принимать PS - будьте добры занести денег за вторую копию рендера! CPSI у ApogeeX, конечно же, в комплекте, только вот одновременно с APPE работет при наличиии отдельной лицензии.

Замечание принимается. Хотя оно, пожалуй, относится уже не к APPE, а к политике уважаемой фирмы агфа и некоторых неудобствах в workflow. Переключится с PDFRender на Render вполне возможно и при наличии одной лицензии.

Если разбирать детально, то сразу возникают вопросы. DisplayList создается? Возможно параллельное порождение из него сепараций несколькими одновременно запущенными копиями рендера? Не эффективнее ли выполнять треппинг ДО расчета прозрачностей? Не эффективнее ли треппинг выполнять на растре? Не эффективнее ли расчет прзрачностей не перекладывать на рендерер, сознательно создавая "узкое место", а выполнять на рабочих станциях при генерации PDF.

Все непростые вопросы, такие впопыхах не обсудить. Могу лишь свой подход к некоторым вещам огласить - избегал пользовать BMO (а порой и PageOverlap) по причине «такой категории "полезности", как надежность». Значительного ускорения не наблюдал (разве что при пруфинге), а cpu's и так есть чем занять .

 

[igors]

Ответ: Поделитесь о фотовыводах

igors, я думаю что /Alexander в этом разговоре поддержка не нужна. Мы лишь уточнили позиции.

Спасибо. Просто, зная /Alexander, я знаю, что он никогда не напишишет, выводов и фактов, которые не подтверждаются его обширной практикой.

 

[JAW]

Ответ: Поделитесь о фотовыводах

sabos
Таки замечу, что поддержка PDF (как и плющенье прозрачностей) встроена и в ядро CPSI.
Как это реализовано второй вопрос.

Лучше ли эта реализация, чем ядро APPE...
Вот это - второй вопрос.
Помнится я слышал маты людей, поднимающи Мету на 2-х гигах оперативки и поднимающих APPE. Правда это тестовые подъёмы... Но маты весьма громкие.

А DELTA с CPSI прекрасно, помнится, работала на двухпроцессорном PII ещё...

 

[/Alexander]

Ответ: Поделитесь о фотовыводах

Здесь нет спора, как и нет его предмета - простой обмен мнениями.

Который мне, например, помогает сформулировать (хотя бы для себя) некоторые, важные в моей работе, моменты.

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

 

[TRANTOR]

Ответ: Поделитесь о фотовыводах

Помнится я слышал маты людей, поднимающи Мету на 2-х гигах оперативки и поднимающих APPE.

2 гига - маловато. 6-8 желательно. Правда не уверен, что это особенность именно APPE в Мете, а не самОй последней Меты в целом.

Кстати говоря, Мета больше 2 ядер не загружает. А жаль.

 

[sabos]

Ответ: Поделитесь о фотовыводах

Таки замечу, что поддержка PDF (как и плющенье прозрачностей) встроена и в ядро CPSI.

По большому секрету расскажу, что у меня есть тайное "ядро CPSI" с поддержкой bmp, jpg, tiff и psd. Знаю, что есть еще более тайное "ядро CPSI", там поддержка doc, cdr, dwg и txt. Разработаны в отделе маркетинга Самой Главной Фирмы.

Что мешает почитать обычную документацию? Подсказываю, 55 страница User Guide: «"CPSI" stands for "Configurable PostScript Interpreter" and refers to the internal PostScript interpreter. The internal PostScript interpreter . always required PostScript code ... converted to Delta Lists which, for example, are to be output to an imagesetter». Видишь, как все просто – потрудился прочитать один абзац, и вся маркетинговая чепуха сразу осыпалась.

А DELTA с CPSI прекрасно, помнится, работала на двухпроцессорном PII ещё...

Ничто не мешает её и на 16-процессорном кластере запустить. Только смысл?

В дельте не пользуют такие CPSI-фичи, как BMO и PageOverlap, так что рендер там всегда оставался bottleneck - только один cpu.

2 гига - маловато. 6-8 желательно. Правда не уверен, что это особенность именно APPE в Мете, а не самОй последней Меты в целом. Кстати говоря, Мета больше 2 ядер не загружает. А жаль.

Да, последние Prinect'ы монструозные у них получаются. Нормальный функционал (PR+PPI+MD+CPP) требует недетских ресурсов и при этом своей производительностью не впечатляет. Особенно если знаешь, какие показатели имеет подобное решение (аналогичное по функционалу и заметно более скромное по железу).

 

[AVorobyoff]

Ответ: Поделитесь о фотовыводах

Раз пошла такая пьянка, то и я вставлю свои 5 копеек (тем более это с моей подачи пошло обсуждение).
Как практик скажу, что после появления прозрачностей в Иллюстраторе очень много дизайнов приходит с прозрачностями. Так как дизайнеры (уж не знаю почему) мало задумываются, как потом их творения обрабатывать (во флексе и высокой печати цветокоррекция и треппинг делаются врчную), то переработать такой дизайн (а иногда и серию дизайнов) - дело очень долгое и муторное. Если РИП не поддерживает прозрачности или плющит их неправильно, то количество работы, которую надо сделать, увеличивается в разы.
Поэтому поддержка прозрачностей или хотя бы их корректное сплющивание, причем с корректной поддержкой спотовых цветов - я считаю необходимое условие для современного растрового процессора. Без этого трудно...

 

[Scorry]

Ответ: Поделитесь о фотовыводах

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

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