Почему не сохраняет в тиф
| Написано: 19 января 2010 года в 10:33 |
| Написано: 19 января 2010 года в 10:48 |
могу предположить из-за чего
- изменение битности с 8 на 16 (32)
- изменение цветового пространства
- изменение размеров изображения
- сохранение пирамиды слоев и прозрачности
- добавлено много цветовой инфы (но в 2 раза это уж надо постаратся огого)
мало инфы, давайте конкретнее
| Написано: 19 января 2010 года в 10:57 |
битность, цветовое пространство, размер не меняла. Слои сводила командой Слой - Выполнить сведение. ОБработка - выравнивание кожи штампом. ПРи сохранении сжатие не включала. Исходник 60 метров, результат 120!
| Написано: 19 января 2010 года в 11:15 |
save image piramid - убрать галочку (это при сахронении)
| Написано: 19 января 2010 года в 11:29 |
| Написано: 19 января 2010 года в 14:23 |
А если сохранить в .psd (psb)?
| Написано: 19 января 2010 года в 15:30 |
не пойдет, нужен .tif
при ZIP сжатии размер меньше, но незначительно. Буду копать дальше.
| Написано: 20 января 2010 года в 00:26 |
No God Can Judge Me
| Написано: 20 января 2010 года в 12:53 |
| Написано: 5 марта 2010 года в 17:31 |
Возможно вопрос снят, но всё же хочу добавить:
если Вы перегоняли файл из Raw, он в любом случае 16 бит, и эту установку нужно менять на 8 бит на самом последнем этапе работы с фото.НО если Ваш файл не 8 бит, содержит слои или альфа каналы- программа не даст Вам сохранить в jpeg. Только вот ещё один момент To: Fearell
Известно ли Вам, что jpeg является форматом с высокой степерью компрессирования, расчитанный на использование для veb. Побочный эффект этого формата- сильная потеря качества при каждой последующей обработке. Т.е. если Вы открыли этот jpeg файл снова в ФШ, и даже просто чуть подняли в нем контраст, файл теряет в качестве. Это становленный факт.
Так что не стоит давать такие советы. Если Вам данная фотография дорога. Тиф - "тяжёлый" формат, но в нём Вы не теряете качество никогда.
| Написано: 5 марта 2010 года в 17:43 |
| Написано: 5 марта 2010 года в 18:18 |
Подождите, подождите. Вы НЕ меняете на 8 бит при сохранении??
| Написано: 5 марта 2010 года в 18:23 |
| Написано: 6 марта 2010 года в 10:39 |
Ну вообще- то это обязательно надо делать т.к. в 16 бит вы не сможете переводить в jpeg, вы не сможете печатать снимки в лабораториях, ваш файл может весить до 70 Mb. и больше.
Может вы говорите о так сказать недоделанных работах, которые вы не сводите из соображений продолжения работы. Ну несведёнка конечно не может быть "лёгкой".
| Написано: 6 марта 2010 года в 10:43 |
| Написано: 6 марта 2010 года в 11:08 |
А вы сохраняете по окончании работы в каком формате? Если Tiff- рекомендую просто внимательнее читать все диалоговые окна при сохранении. Обязательно делайте LZV сжатие, и в том же окне всегда следите за pixel order!! Там галка должна стоять на interleaved(rgbrgb)
И не нужно ничего переустанавливать.
Я сейчас конечно же говорю об окончательном сохранении!
Промежуточное сохрарнение как раз совсем не требует этих значений- наоборот
| Написано: 6 марта 2010 года в 11:36 |
| Написано: 6 марта 2010 года в 12:25 |
Добавлю,Ю может поможет.
Там при сохранении есть еще галочка - "сохранить структуру" - ее надо снять.
И надо не просто объединение слоев, а выполнить сведение. Ну это вроде как Вы и делали.
| Написано: 6 марта 2010 года в 16:22 |
Спецы! Я полагаю, что что то подобное уже рассматривалось. однако я не нашел вразумительных концов. Опять таки дизайн-студия требует файлы в tiff и при этом предупреждает, что файлы, созданные в Corel требуют допечатной подготовки (я так полагаю, что именно перевод). В одном из рекламных объявлений в Интернет одна фирма любезно рекомендует как это можно сделать. Вроде бы Corel по хитрому меняет размер картинки и это дело можно обмануть путем двойного экспорта из него:
1. указать расшерение 1 и экспортировать несмотря на тупые цифры в размерах картинки;
2. при вторичном сохранении нужно указать нужное разрешение и размер правильный установится сам собой.
Причем Corel 8 тестировался ими под XP и все работало.
Пробовал, не получается.
С великим уважением.
Ответ: Сохранение из cdr в tiff больших форматов
Честно понять проблему сложновато, вообще у меня все изображения в газете проходят в TIFFе правда версия корела 12 , я при экспорте просто задаю разрешешние и сохранение пропорций вида(в смысле пропорций изображения на холсте, ну для пущей увереннности я бы ещё задал размеры холста по размеру макета при его создании) вот вобщем и все заморочки есть только выход краёв изображения при заливке градиентом с тёмными краями так это пожалуй мои недочёты при помещении изображений в полосу во время вёрстки что вполне исправляемо.
P.S. Если есть другие заморочки поделитесь-поэксперементируем.
Ответ: Сохранение из cdr в tiff больших форматов
Ответ: Сохранение из cdr в tiff больших форматов
Ответ: Сохранение из cdr в tiff больших форматов
Попробовал более тщательно выполнить двойной экспорт из Corel 12 в PhotoShop CS макета размером 2 на 5,5 метров. Вроде получилось. Однако дизайнер из фирмы в которую я планирую обратиться сказал, что если у вас PhotoShop настроен правильно и машина мощная, то можно просто тот макет, который экпортировался из Corel в PhotoShop взять и тупо растянуть до нужных размеров. Однако PhotoShop говорит, что это не его размерчик (слишком большой). Как же его надо настраивать и какая же мощность машины должна быть?
Ответ: Сохранение из cdr в tiff больших форматов
Ответ: Сохранение из cdr в tiff больших форматов
Насколько понимаю, речь в первом посте идёт о невозможности Корела до 13-й версии экспортить растр, размером более 10000 пикселей. Не знаю, как "одна фирма любезно рекомендует", но решение было мной достаточно чётко сформулировано и описано года три назад. На этом форуме помоему не выкладывал. Поищите в Гугле фразу "Пресловутые 10000 пикселей". Найдётся.
Ответ: Сохранение из cdr в tiff больших форматов
Ответ: Сохранение из cdr в tiff больших форматов
Не понял. Это хумор?
Экспорт из Корела скорей всего можно сделать больше чем способен открыть Шоп. У шопа ограничение на 30000х30000 пикселей.
Ответ: Сохранение из cdr в tiff больших форматов
Не понял. Это хумор?
Да вроде как нет, не стану говорить за всех но макет размером 10 Х10 метров в девятом делали при стандартном разрешении (300 dpi) но не я лично, другой дизайнер нашей конторы. В шопе поскольку не особо силён поэтому поводу конкретно что либо точно писать не стану (если нужна конкретика то постораюсь прояснить детально). Но вот что касаемо первого поста то макет 5,5 Х 2 метра всё же он должен вывезти или не это не так? Тогда прошу прощения или я не правильно понял размеры и тип конечного вывода, либо вам стоит повнимательнее отнестись к возможностям фотошоп CS 2. А вот по поводу величины разрешения выдаваемого корелом то тут вопросов и не может быть в идее.
Moderatorial
Не надо полностью цитировать предыдущее письмо
Ответ: Сохранение из cdr в tiff больших форматов
Ответ: Сохранение из cdr в tiff больших форматов
Большая благодарность заинтересованным. В принципе, все именно так и решилось. Когда по телефону дизайнер из фирмы попытался мне пояснить что такое допечатная подготовка, то все улеглось на свои места. Однако соглашусь с тем, что а почему бы и не быть из размера в размер без проблем просто так? Если это в принципе возможно?
Когда получатся все макеты, всех приглашу на показ большой аудитории в военном авиационном инженерном училище (стольный град Иркутск). Если в теме есть иркутяне, то не мешкайте, помогайте, так как дело стоит около 120 кв. метров.
Заинтересованные пишите на email.
Ответ: Сохранение из cdr в tiff больших форматов
Простая математика:
10 метров переводим в дюймы: 1000 (cm) /2.54 = 393.701"
393.701" по 300 пикселей на дюйм: 393.701 * 300 = 118110.236 пикселей
У Шопа ограничение в 30000 пикселей: 118110.236 / 30000 = 3,94
Ответ: Сохранение из cdr в tiff больших форматов
Ответ: Сохранение из cdr в tiff больших форматов
Ну вы блин даете.
Вот, читайте на здоровье.
Ответ: Сохранение из cdr в tiff больших форматов
Ну а для баннеров, в таком "стандартном" их проявлении, как то 6х3, 9х1.5 - даже не 60, а 25-40 дпи вполне хватает, более того, некоторые уверяют что и этого много.
См. скриншот. (видно, что ломанные линии и текст растянутый. )
Скорее всего, что ошибка была не один раз, поскольку сохранение работ в различных кусках планшета производилось несколько раз в разное время.
Такое впечатление, что во время сохранения происходит "запирание" (может процессорное время, может оперативка) и программа не умеет правильно обрабатывать нехватку ресурсов.
Но из-за этих ошибок возникают серьезные проблемы при работе с картматериалами у проектировщиков, земельщиков, геодезистов и т.д., поскольку изображение с погрешностями.
Кроме того, чтобы восстановить правильное отображение всего планшета, нам необходимо потратить УЙМУ времени: найти самую старую отсканированную копию планшета, после этого обрезать все карты, которые попадают на этот планшет, чтобы они не налазили друг на друга и перевдавить по-новой.
К сожалению, нам сложно отследить, когда и в какой версии это происходило, т.к. это возникает периодически, а каждый раз просматривать после сохранения планшет и выискивать пару пикселей сбойных очень сложно, особенно когда в день нужно порядка 40 таких планшетов сделать.
В основном, такие ошибки находятся, когда организация работает в каком-то месте и сдает вектор, а рядом я вижу проблемы с изображением.
Очень нужно решение этой проблемы, т.к. это ОЧень серьезная ошибка в нашей отрасли работ.
При тестировании режима сохранения изображения документа в файл TIFF средствами ГИС Карта2011 (ГИС Панорама Мини) получить описанный Вами результат не удалось.
Для дальнейшего анализа сложившейся ситуации прошу выслать исходные данные, при сохранении которых в TIFF появляется смещение строк изображения, в составе: файл TIFF исходного планшета с файлом привязки, карта с обновленной информацией на территорию исходного планшета. Также прошу выслать полученный Вами средствами ГИС Карта2011 (ГИС Панорама Мини) некорректный файл TIFF с файлом привязки, не подвергавшийся трансформированию и сжатию.
Добрый день. Был в отпуске, поэтому только увидел сообщение.
Вначале опишу общие моменты, а потом отвечу на вопросы.
1. Параметры всегда одинаковые, идея в том, что такие "запирания" происходят хаотично. Т.е. при равных условиях один и тот же планшет может один раз сохраниться нормально, а в следующий раз "проглючить". Поэтому сложно отследить и поэтому варианты выбора параметров в диалоге сохранения не столь важны, ведь мы их не меняем. Возможно, проблема возникает только на нашем компьютере. Но конфигурация достаточно мощная. Сохранение и работа с ГИС Карта происходит через удаленный рабочий стол (сервер терминалов.
Параметры:
- Копирование масштаба. = не выполнять
- Масштаб = 500
- Разрешение = 400 (точек/дюйм)
- Бит на пиксель - 1
- RGB
Используется XnView, но сжатые файлы (М 1:1000) передаются в смежный отдел, а мы в последующей работе используем несжатое изображение 500 масштаба, то которое на выходе из Карты получили.
Предлагаю вам два файла, один "глючный" планшет и такой же, но пересохраненный нормальный.
Карту смысла кидать нет, т.к. это не зависит от конкретной карты, ведь сбои идут полосами хаотично по планшету, а не в границах карты.
Могу любую карту скинуть, просто это мало что даст, поскольку пока я не смог отследить цепочку по конкретному объекту - нормальный планшет - карта - "глючный" планшет.
1. Дмитрий написал: ". важно, чтобы параметры (масштаб, разрешающая способность, размер элемента в метрах) сохраняемого изображения соответствовали параметрам растровой карты исходного планшета."
Возможно проблема именно в том, что Вы используете опцию "Копирование масштаба. = не выполнять".
При использовании такой опции параметры сохраняемого растра могут чуть-чуть отличаться, что может приводить к появлению систематических сдвигов в 1 пиксел полос изображения растра с некоторым шагом. При многократных итерациях операций "загрузки из TIFF-сохранения в TIFF" без сохранения основных параметров растров сдвиги могут накапливаться.
2. Кто может гарантировать правильность работы программы XnView?
| Цитата |
|---|
| Alexander Kruzhkov пишет: 2. Кто может гарантировать правильность работы программы XnView? |
XnView не участвует в нашем внутреннем круговороте планшетов, а только при передаче планшетов в смежный отдел. Ошибки изображения появляются именно при сохранении в растр и до обработки XnView.
Еще возможная причина, что отсканированные планшеты не всегда квадратные, т.е. количество пикселей по горизонтали может отличаться на пару пикселей от количества по вертикали, поскольку раньше, когда их сканировали с калек, то после этого делали обрезку рамки вручную через Автокад при максимальном приближении и "тыкании" курсором в пересечение и последующей обрезкой и трансформацией.
Попробую поиграться с параметрами привязок, может удастся воспроизвести ошибку.
Я проверил один растр. за последние полтора года "вдавливание" с ним происходило 15 раз.
Действительно, при каждом сохранении происходит смещение на несколько пикселей полос растра.
Но вот вопрос, почему именно "полосы растра" и почему изображение "сжимается"?
Ведь, по сути, если отличаются параметры входного и выходного изображения, то изображение должно отсекаться по краям, а не в центре изображения двигаться. причем интересно, что оно в конкретном месте происходит при все последующих итерациях.
Мне кажется, что это баг в функции сохранения растра.
На счет копирования параметров из загруженного RSW: при выборе копирования параметров из соответствующего RSW подставляется масштаб 1000 и разрешение 800, тогда как нам необходимо формировать 500-ку (и соответственно разрешение 400).
Скорее всего это из-за того, что первичными были отсканированные планшеты в 1000 масштабе (и соответствующие привязки в мировом файле). Но средствами ГИС Карты мы сохраняем растр в 500 масштабе и соответствующую привязку в мировом файле. После этого я подгружаю этот растр опять в RSW и, если выбираю при сохранении копирование параметров из этого RSW, то подставляется 1000 масштаб. Не пойму в чем причина.
Планшеты с привязками есть в предыдущих постах.
| Цитата |
|---|
| Алексей Чайка пишет: На счет копирования параметров из загруженного RSW: при выборе копирования параметров из соответствующего RSW подставляется масштаб 1000 и разрешение 800, тогда как нам необходимо формировать 500-ку (и соответственно разрешение 400). Скорее всего это из-за того, что первичными были отсканированные планшеты в 1000 масштабе (и соответствующие привязки в мировом файле). Но средствами ГИС Карты мы сохраняем растр в 500 масштабе и соответствующую привязку в мировом файле. После этого я подгружаю этот растр опять в RSW и, если выбираю при сохранении копирование параметров из этого RSW, то подставляется 1000 масштаб. Не пойму в чем причина. |
Получаем, что MetInElement_1 равно MetInElement_2.
Если сохраняемый TIFF всегда используется с файлом привязки, тогда зачем лишние манипуляции с изменением масштаба и разрешения, не влияющие на результат?
При загрузке файла TIFF+tfw в растровую карту ключевым параметром для нас является РАЗМЕР ЭЛЕМЕНТА РАСТРА В МЕТРАХ НА МЕСТНОСТИ из файла tfw (и конечно, координаты левого верхнего угла изображения). Масштаб и разрешение подбираются таким образом, чтобы в растре RSW РАЗМЕР ЭЛЕМЕНТА соответствовал значению, прочитанному в файле tfw.
| Цитата |
|---|
| Dmitry_ пишет: |
Код
Содержимое файла 275711_new.tfw:
0.031750
0.0
0.0
-0.031750
57499.987681
27500.022733
На счет координат.
Теоретически, планшет должен иметь "верные" математические координаты = 57500.00 и 27500.00.
Однако, как я писал выше, исходные растры получались путем ручного сканирования, обрезки и дальнейшей обработки. Тем самым, мы имеем рестровые данные с "неверными" математическими координатами и размерами.
У нас есть карта sit с "верной" математической разграфкой (площадные объекты по координатам растров).
При сохранении в tif, я выбираю кнопку "По объекту" и указываю площадной объект на карте с разграфкой.
По идее, на выходе я хочу получить сформированное изображение по размеру, который ограничен ранее выбранным объектом разграфки (обрезанное изображение с "верными" математичесими координатами и привязкой вида 57500.00 и 27500.00).
Но на выходе я получаю те же параметры привязок, что и на входе. Кроме того изображение получается размером 7875*7875 пикселей (как и входной файл tif).
Если же я при сохранении нажимать на кнопку "По растрам", то формируемое изображение будет иметь размер 7880*7885.
К слову, получившаяся RSW из исходного тифа 7875*7875 имеет как раз такие размеры (7883*7885). Т.е. при формировании RSW растр немного растягивается, если я правильно понимаю.
Но вот почему на выходе не получается изображение с "верными" математическими привязками и размерами я не пойму (при использовании 1-го метода сохранения).
Это к слову о существующей технологии.
Теперь перейдем к методу, предложенному Вами.
При запуске указанного приложения (правда называется оно "Дорисовка векторной карты на растре". еле нашел).
1. Загружаем растр из tif. В окне "Загрузка растровой карты" указано, что Количество цветов = 2(RGB), Размер пикселя = 1.
2. Запускаем указанное приложение - вылетает окно, в котором говорится: "В документе нет открытых однобитных(черно-белых) растров. Работа режима невозможна.". как так?
3. Говорим OK и появляется окошко с выбором параметров, где указано имя исходного растра, имя создаваемого растра, размер (7880*7875) и стоит галочка "Вывод карты в принтерном виде". Если нажать на кнопку "По объекту" и выбрать объект разграфки, то размер выходит 7874*7874 (непонятно, почему при обычном сохранении и выборе "По объекту" размер будет 7875*7875).
4. Говорим "Выполнить", получаем сообщение об ошибке "Отображение векторной информации на растре не выполнено". В итоге растр создается, но без изменений.
Сейчас стоит версия 11.10.4. До этого была 11.10.3, вот в ней сохранение происходило, хотя выдавало те же ошибки. Но на выходе получалось цветное изображение (например, отображение инженерных сетей разными цветами (газ-голубой, канализация-коричневая, водопровод-зеленый и т.д.), которое при дальнейшем сохранении в tif с указанием параметра "Бит на пиксел" = 1 получается ненасыщенное (половина пикселей теряется). Хотя если просто сохранять карту в растр (как и делаем сейчас), то все линии прорисовываются четким черным цветом.
Вот и возникает ряд вопросов по работе этого "приложения", которое работает не совсем корректно.
Заранее благодарю за конструктивные ответы на возникшие вопросы.
официальный блог компании
Для примера возьмем кадр со среднеформатной камеры Hasselblad 503cw, сделанный на пленку Kodak Portra 400. Отсканируем его на Nikon Coolscan 9000 с максимальным разрешением 4000 dpi (
8800 x 8800 px) и сохраним в двух форматах — TIFF и JPEG с качеством 100%. Прежде всего сравним размеры этих файлов:
TIFF — 465 Mb
JPEG — 90 Mb
Разница, согласитель, приличная, в 5 раз. Для одной 12-кадровой пленки разница в требуемом объеме дискового пространства составит [(12 х 0,465) = 5,58 Gb] — [(12 х 0,09) = 1,08 Gb] = 4,5 Gb. То есть в одном случае сканы пленки займут 5,58 Gb, а в другом 1,08 Gb. Что мы получаем за эту разницу?
Итак, в одном углу ринга TIFF весом 465 Mb, в другом JPEG 90 Мб. Кто победит? Что дает нам 5-кратный прирост веса с точки зрения качества картинки? Проведем наглядный эксперимент. Возьмем изначально сканированный TIFF, сохраним его JPEG-версию с качеством 100% (именно так делает софт всех сканеров) и сравним. Важно — при сравнении вся работа ведется в 16-битном растровом файле TIFF, нижеприведенные скриншоты сделаны соответствующим образом. То есть сравнение абсолютно корректно, т.к. ни в коей мере не является сравнением двух jpeg’ов.
Итак, посмотрите на заглавную картинку в этой статье. Слева TIFF, справа JPEG. Видите разницу? Вряд ли, потому что оба файла при публикации в интернете — уже джипеги, к тому же маленького размера. Поэтому теперь посмотрим на сильно увеличенный (до 500%) фрагмент кадра:
Видите ли вы разницу теперь? Очень сомнительно, хотя, конечно, не исключено. И ведь это при 500%-ом увеличении! При таком, при котором никто никогда, включая вас самих, эти файлы смотреть не будет.
И всё же — попробуем найти разницу, пусть глазами ее и не видно. Для этого наложим JPEG на TIFF в Adobe Photoshop двумя слоями в режиме Difference:
Там, где разницы нет, цвет будет черным. Там, где она есть, каким-то, отличным от черного.
Но все-таки. Должна же быть хоть какая-то визуальная разница между TIFF и JPEG, спросите вы? Иначе какой вообще смысл в формате TIFF? Да, разница действительно есть. Но она сугубо техническая, настолько несущественная, что в реальных условиях вы с ней никогда не столкнетесь. Чтобы ее увидеть, нужно очень сильно повысить контраст у нашей разницы Difference. Очень сильно — это значит настолько сильно, насколько в реальной практике мы никогда задирать не будем. Но даже при таком невероятно мощном контрасте цвет разницы будет оставаться черным. То есть разница снова не наблюдается:
И только если задрать контраст до такого предела, когда белая и черная точки на инструменте Levels схлопнутся в одну (что абсолютно никогда невозможно в реальной обработке фотографий), только тогда можно увидеть некоторую несущественную разницу, проявляющуюся на уровне естественного шума самого цифрового формата и матрицы сканера.
Продемонстрируем гротескный (то есть нарочито усиленный) пример — возьмем два наших файла и применим к ним очень сильную контрастную кривую. Настолько сильную, какую в реальной жизни применять мы вряд ли будем.
Именно после значительного повышения контраста на плавных градиентах (обычно в небе) чаще всего проявляется постеризация, однако в нашем случае этого не произошло. Для уверенности сохраним результат сравнения в виде PNG файла, чтобы исключить вмешательство JPEG при просмотре.
На всякий случай посмотрим на фрагмент скана при 100% увеличении, и снова никакой постеризации.
При работе с цифровыми файлами появление постеризации более вероятно, однако в случае пленки 8-битность сканов (именно сканов) не является проблемой, в частности и потому, что пленочное зерно работает как естественный дитеринг, т.е. сглаживает градации и не дает появиться постеризации. Для цифровых файлов разница между 8 и 16 битами более существенна.
Получается, что формат TIFF довольно бессмысленен для сканирования и хранения сканов. Намного разумнее делать это в JPEG — работать с такими файлами намного быстрее, занимают они на порядок меньше места, а визуальное качество картинки в них не отличается. Однако, тут есть несколько важных нюансов:
1) Качество сохранения такого JPEG файла должно быть 100%. Если же, например, вы сохраните JPEG c качеством даже 95%, то наблюдаемая разница в приведенном примере начнет наблюдаться гораздо быстрее, и такой файл уже будет действительно проигрывать формату TIFF. Поэтому обязательно проверьте в настройках вашей программы сканирования качество JPEG файла. Если же вы сканируете в фотолаборатории, выясните, какое качество JPEG файла они используют. Например, в лаборатории SREDA Film Lab всегда используется только 100% качество JPEG-файлов, на всех сканерах.
TIFF или JPEG? : 20 комментариев
Для чистоты эксперимента файл разницы нужно сохранять в PNG. 🙂
Пробовали — тоже самое, но размер файла для статьи сильно увеличивается.
Тут опечатка — (12 х 0,9) = 1,08 Gb — должно быть 0,09
Из предложенных вариантов однозначно только TIFF, и только в 16 бит/канал. Поскольку получая отсканированнные изображения в JPEG, Вы получаете их с глубиной цвета 8 бит/канал. А это серьезно снижает запас информации на обработку и стадиально увеличивает шансы получения постеризации.
И это действительно будет так, разницу не заметите. Ровно до того момента, пока Вы не попробуете пиво на вкус. Так и картинкой: все одинаково, пока не начал обрабатывать.
Паша, ну ты же ходил на мои занятия. От кого, а от тебя такой глупости не ожидал.
Андрей, я всю теорию знаю великолепно, поверь. Только вот реальная практика этого не подтверждает. Я добавил в статью наглядную демонстрацию. Важные моменты — речь идет о сканах (не о цифровой фотографии), где есть естественный диттеринг, и речь идет о 100% джипеге (даже при 95% результаты будут другие). Если не веришь, приведи реальный пример с постеризацией, после этого приноси этот негатив, мы его отсканируем и я продемонстрирую, что никакой постеризации при грамотном сканирровании и сохранении файлов не будет и в 8-битном файле.
Верю, Паша, что знаешь великолепно.
И вижу, что опять путаешь теплое с кислым.
Когда человек получает исходник, а отсканированное изображение — это по определению исходник, его интересует не столько, как картинка выглядит сейчас, сколько, что с ней можно будет сделать в процессе обработки.
Ох, извини, перечитал еще раз. Речь шла не о масштабировании до 95%, а об уменьшении фактора качества при сохранении. Так это вообще уже не про холодное/теплое, или сладкое/кислое, а про свежее/тухлое. Право слово, не стоили еще и алгоритмы jpg-сжатия в этот разговор приплетать.
После сканирования мы имеем оцифрованное изображение, с заданными техническими параметрами. История его создания не важна. И если повышать контраст этого изображения, то в 8-битном режиме полезет пастеризация. Более ядреные пленочные шумы до какого-то момента будут ее маскировать, но всему есть предел. И в некоторый момент она вылезет.
Предложение пользователям переводить файл перед обработкой в 16-битный режим сродни предложению пришить яйца быку-осеменителю. Перевести-то можно, да вот только тех градаций, которые изначально давал 16-битный режим, в картинке уже нет. И при повышении контраста ее величество ПОСТЕРИЗАЦИЯ (отнюдь не мифическая) будет стучаться в дверь так же активно, как Навальный в сердца борцов с коррупцией.
А кстати, хороший вопрос: если ты так уверен, что 8 бит хватит, зачем вообще предлагать пользователю переходить на этапе обработки в 16? Ведь у него, о ужас, все файлы увеличатся в ДВА РАЗА! А ведь именно размер файлы был основным доводом к написанию этой статьи.
Искусственный перевод в 16-битный режим может защитить только от набегающей погрешности округления, то есть, от понижения контраста, но никак не от его повышения.
Завершая тему. Ты в точности повторил холивар десятилетней давности (а может и больше, время летит так быстро). Когда Маргулис доказывал всем, что 8-битное представление не имеет никаких минусов, а многие специалисты ему здраво возражали. При этом Ден использовал точно такое же передергивание: давайте все переведем все сначала в 8 бит, а затем желающие переведут это обратно в 16 и мы будем сравнивать. К большому сожалению Брюс Линдблюм ликвидировал свой сайт. У него была самая толковая и развернутая статья на эту тему. Желающие найдут ее в интернете самостоятельно (на английском языке).
Все сказанное мной выше отнюдь не означает, что сканировать в 8 бит/канал нельзя. Во многих случаях можно пойти на уменьшение глубины цвета, и, как следствие, позволить себе получить исходники в jpg. Когда-то мы работали только в таком представлении, и делали очень даже неплохие вещи. Но пользователь должен понимать, когда ЕМУ нужно 16-битное представление, а когда ОН может позволить СЕБЕ обойтись 8-битным.
Людей нужно образовывать, а не оболванивать. Желание отдавать файлы на носителях меньшего размера не должно преобладать над здравым смыслом.
Не удаляйте, пожалуйста, эту заметку. Я обязательно напишу подробную статью у себя в ЖЖ с разбором этой темы. Очень хотелось бы иметь хорошую ссылку для разбора заблуждений.
Андрей, все это я очень хорошо знаю. 10 лет уже нас этими сказками кормят технические специалисты. Есть теория, а есть реальная практика. В очередной раз я вижу много слов и пафоса, но пока всё впустую. Пиши статью, показывай примеры и — обязательно (это принципиально важно) приноси потом нам свой негатив на сканирование.
Также обрати внимание на то, что я допускаю чисто теоретическую постеризацию про очень сильной (конечно же, не имеющей никакого практического смысла) обработке, но считаю, что ради этого чисто теорерического (то есть не встречающегося в реальной практике) исключения бессмысленно приносить такую большую жертву. Если скан нужно обрабатывать до такой степени, что для этого потребуется 16 бит, его место в корзине. Есть большая разница между фотографами, которые могут (и должны) переснять плохую фотографию и цветокорректором, который хочешь не хочешь должен вытянуть что-то из заведомо негодного снимка. Эта статья для фотографов и задачи здесь решаются фотографические.
Насчет размера файла ты передергиваешь. Он увеличивается не в 2 раза. Читай внимательно статью.
Читайте также: