Почему при переносе изображения из фотошопа в корел меняется размер изображения?

  • Автор темы Автор темы Valery 333
  • Дата начала Дата начала
Статус
Закрыто для дальнейших ответов.
Как это не имеет?
Повторю еще раз. НЕ ИМЕЕТ. Перечитайте еще раз ссылку, которую дал suntory. Там есть даже такая строка: "The JPEG standard does not include any method of coding the resolution or aspect ratio of an image."
 
Так это общий случай сферического JPEGа в вакууме. Следующей строкой написано что JFIF (под которым все обычно понимают JPEG) очень даже имеет.
 
К чему я и клоню. Уточняйте свои мысли и все будет в порядке. Я ж не зря написал «в общем случае» и я не оперирую понятиями «обычно все понимают» :).
 
Так, с этой точки зрения, и в TIFF наличие разрешения вовсе не обязательно. Более того, и JPEG и TIFF являются достаточно гибкими стандартами, чтобы создать формально корректный абсурдный самоисключающий файл, скажем, без ширины или высоты, да и вообще не содержащий растровых данных. Я бы уточнил фразу так: "современный JPEG файл, корректно обрабатываемый графическими программами, должен содержать в себе размеры изображения и разрешение"
 
Так, с этой точки зрения, и в TIFF наличие разрешения вовсе не обязательно.
Опять мимо :). В спецификации TIFF теги 282 (XResolution), 283 (YResolution) и 296 (ResolutionUnit) являются обязательными.
Но, с уточненной фразой я согласен.

Не по теме:

И охота вам спорить ни о чем. Я уже как-то Высоцкого цитировал:

Да он всегда был спорщиком,
Припрешь к стене - откажется.
Прошел он коридорчиком,
И кончил стенкой, кажется.
:)

 
  • Спасибо
Реакции: Skvoznyak

Не по теме:
Толстый, толстый намек - опять мыться отправят.
 
Дык, истина дороже! Все, исключительно ради нее! ;)
В спецификации TIFF теги 282 (XResolution), 283 (YResolution) и 296 (ResolutionUnit) являются обязательными.
Тоже, не совсем так. Вот пример вполне себе живого и работоспособного TIFF файла, в котором все эти три поля отсутствуют.
 

Вложения

  • 1.zip
    1.zip
    694 байт · Просм.: 385
Отсутствуют вышеперичисленные тэги 282, 283 и 296, собственно, ответственные за разрешение. Разрешение берется "от фонаря". Убедиться можно скажем, через TIFFdump:
Код:
1.tif:
Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 1048 (0x418) next 0 (0)
SubFileType (254) LONG (4) 1<0>
ImageWidth (256) LONG (4) 1<357>
ImageLength (257) LONG (4) 1<22>
BitsPerSample (258) SHORT (3) 1<1>
Compression (259) SHORT (3) 1<1>
Photometric (262) SHORT (3) 1<1>
ImageDescription (270) ASCII (2) 34<image description        ...>
StripOffsets (273) LONG (4) 1<58>
Orientation (274) SHORT (3) 1<1>
SamplesPerPixel (277) SHORT (3) 1<1>
RowsPerStrip (278) LONG (4) 1<22>
StripByteCounts (279) LONG (4) 1<990>
511 (0x1ff) RATIONAL (5) 1<72>
511 (0x1ff) RATIONAL (5) 1<72>
511 (0x1ff) SHORT (3) 1<2>
34016 (0x84e0) ASCII (2) 0<>
34017 (0x84e1) ASCII (2) 0<>
34018 (0x84e2) ASCII (2) 0<>
34019 (0x84e3) SHORT (3) 1<0>
34020 (0x84e4) SHORT (3) 1<8>
34021 (0x84e5) SHORT (3) 1<16>
34022 (0x84e6) BYTE (1) 0<>
34023 (0x84e7) BYTE (1) 1<00>
34024 (0x84e8) BYTE (1) 1<00>
34025 (0x84e9) BYTE (1) 0<>
34026 (0x84ea) BYTE (1) 0<>
34027 (0x84eb) BYTE (1) 2<00 00>
34028 (0x84ec) BYTE (1) 1<00>
34029 (0x84ed) ASCII (2) 0<>
34030 (0x84ee) LONG (4) 1<0>
34031 (0x84ef) BYTE (1) 0<>
 

Не по теме:
Точно. Пора корел поставить. А то все как-то забываю.
 
Дык, истина дороже! Все, исключительно ради нее!
Это да, все ради нее. Но истина в том, что этот «живой и работоспособный» TIFF получен несколько, эээ.... противоестественным путем :). Что я имею в виду. Любой уважающий себя и желающий добиться успеха на рынке разработчик должен (вернее прям-таки обязан) следовать принятым стандартам при работе с общеупотребительными типами файлов.
Вот, например, придумали вы какой-нибудь PainCAD :) и делаете в нем модуль экспорта в JPEG. Для совместимости с _любыми_ другими графическими программами вам необходимо и достаточно, чтобы полученные файлы соответствовали стандарту. Хотите улучшить свой модуль, чтобы еще и передавать инфу о линейных размерах - не вопрос, добавляете еще и JFIF (или EXIF). Все аплодируют и вы имеете свой кусочек хлеба и чего-то там еще. Захотите добавить экспорт в TIFF - и вам придется блюсти все заданные стандартом теги, ибо в противном случае цена вашему продукту - ноль.
К чему это я? А! К противоестественности вашего примера и истине. Так вот, вы показали, что такие файлы могут существовать. Я и не сомневался в ваших способностях творить подобных франкенштейнов. Но я пытаюсь показать, что нет на рынке программ, которые бы сознательно делали такие файлы, обманывая ожидания пользователей. Так в чем истина?
 
На самом деле этот файл - всего-навсего иллюстрация того, что тезис "TIFF, в отличие от JPEG, надежнее передает разрешение графического файла" - надуманный. Ибо JPEG с отсутствующим полем разрешения технически сделать гораздо сложнее, чем аналогичный TIFF. Причем, как выяснилось, основной массе графических программ глубоко фиолетово наличие этих полей в TIFF - они молча подставляют свои умолчательные значения (к примеру, у меня виндовый проводник в сводке показывает для этого файла 96 dpi)
 
И дайте угадаю речь идет небось о какой-нибудь "оперативной полиграфии"? Тогда возможны любые чудеса. Они там вообще все файлы открывают через... корел.

Вот не надо так всех одним махом. Я непосредственно в "оперативке" срок немалый отмотал. Никто там корелем ничего не открывает кроме кореловских же файлов. На цифру иногда предпечать сделать сложнее чем на офсет, особенно когда залихватские градиенты в макет напиханы или плашка в 3% по каналу. А заказчик желает, чтоб всё выглядело "как вот тут" и тычет тебе в нос офсетное изделие да еще в 5 цветов выполненное.
 
Статус
Закрыто для дальнейших ответов.