Яндекс давно различает региональные сайты. Учитывается множество показателей, в том числе например код города в номерах телефонов указанных на сайте, место размещение сервера по geoip, где хостится сайт и ряду других признаков.
Поэтому жителям разных городов яндекс в поиске преимущественно выдает сайты учреждений относящихся к их городам. Так называемый региональный поиск.
Даже грамотнее будет следуя спецификации зафиксировать первые 4 как IHDR, затем перебрать все возможные разрешения и сочетания параметров, их не так много.
При желании можно даже подобрать все возможные сочетания для 17 байт, от которых считается CRC и получается равным IDAT, посмотреть, есть ли среди них вменяемые.
А что в этом плохого? Если на картинку будут смотреть из космоса, то использование разрешения в 1dpi будет единственной возможностью не получить графический файл для многокилометровой картинки в пару петабайт и не загрузить компьютер вычислениями на несколько лет.
В полиграфии параметр dpi используется повсеместно и они находят это вполне удобным. Например рекламные щиты печатаются реально с очень низким dpi, на них будут смотреть из далека, а работать гигантским файлом было бы много сложнее. Хотя плоттеры на которых эти щиты печатаются чаще всего используют гораздо большую разрешающую способность. Кроме того когда я передаю файл в печать, мне чаще всего ничего не известно о технике, которую они там используют. И не стану же я для каждого принтера, каждого печатающего устройства готовить свой, отдельный файл? Мне проще сгенерировать один с заданным разрешением, которого мне вполне достаточно и использовать его повсюду.
Кроме того параметр dpi позволяет судить о четкости и реальном разрешении картинки. Например я знаю, что для моих графиков разрешающей способности в 600dpi достаточно для 100% передачи всех нюансов и заложенной в них информации. Поэтому генерирую их и сохраняю всегда с таким разрешением в независимости от того, где собираюсь их печатать. Зачем порождать избыточные данные?
Формат хранение графических данных PNG не предусматривает сохранения информации о дюйма или сантиметрах. Вместо этого, как и все он хранит разрешение, в px/дюйм. Что являлось по мнению экспертов, когда придумывали стандарты являлось более грамотным решением. И я с ними согласен. Поскольку если хранить просто размеры в дюймах или сантиметрах, то всякий раз, когда мы захотим вырезать из картинки кусочек, или подрезать ее по краям графическому софту пришлось бы изменять не только разрешение в пикселях, но и заботится о метрические размерах. И если софт сделает это некорректно или не умеет этого, то мы бы получали искаженную информацию внутри файла и рисковали бы навсегда потерять сведения о реальных физических размерах картинки.
Алгоритм сжатия тут не причем. IDAT чанк как раз и содержит сжатые данные картинки. Так что до первого IDAT чанка у нас никакой сжатой графической информации в принципе не встречается.
В png-шках получаемых из GD перед первым IDAT чанком только стандартный идентификатор PNG и IHDR чанк содержащий:
Width: 4 bytes
Height: 4 bytes
Bit depth: 1 byte
Color type: 1 byte
Compression method: 1 byte
Filter method: 1 byte
Interlace method: 1 byte
Какова вероятность того, что в сочетании этих параметров или в CRC32 от них+заголовок мы получим последовательность байт которая будет соответствовать ASCII «pHYs»?
Я указал в топике, что не претендую на грамотный алгоритм вставки чанка, мне сей код нужен только чтобы для себя пару картинок в неделю генерить.
Я могу распечатать квадратный дюйм из картинки любого размера. =)
Если я имею картинку 1x1px, то достаточно указать разрешение 1dpi.
Если 10x10 то 10dpi, а если скажем 10000x10000 то 10000dpi.
Также я получу картинку в один дюйм из файла 50x666 если пропишу ему по горизонтали 50dpi, а по вертикали 666dpi.
При печати во всех случаях я получу картинку в в один дюйм. Качество может быть разным, но если это квадрат малевича, то разницы не будет.
Я в своем классе могу задать графику любые физические размеры. При этом какой бы я dpi не задал, он будет на печати ровно с теми физическими размерами которые я указал, хотя будет сгенерировано разное количество пикселей.
Это даже не рекомендация. Это некоторая гарантия того, что кому бы я не послал свой график и чьим бы принтером не воспользовался, распечатав его, все увидят миллиметровку нанесенную на нем действительно миллиметровой. =)
Фактически Word просто изменит при этом dpi по вертикали. Ни разрешение принтера, ни количество пикселей в картинке при этом не изменится. Они будут экстраполированы в разрешение принтера, только при передаче документа принтеру.
Совершенно верно. В файле и с картинкой никаких метаморфоз не происходит. Это просто способ придать безразмерным пикселям какие-то реальные физические размеры и при этом не зависеть от разрешающей способности устройств вывода.
Я пересчитал, но Word об этом ничего не знает. Он понятия не имеет какого физического размера я хочу увидеть ее в документе. Раньше мне приходилось либо изменять разрешение в графическом редакторе, а потом сохранять и вставлять картинку в ворд. Либо сначала вставлять ее в Word, а потом там, в свойствах, указывать ее физические размеры на листе.
Это зависит от софта. Подавляющее большинство смотрят на параметр dpi указанный для картинке и при печати экстраполируют ее до разрешения принтера (если оно отличается).
При этом если в файле не указан dpi, то за дефолт часто берется системное разрешение (например 96 dpi).
К тому же это вы знаете разрешение своего принтера, а если я хочу печатать картинку на разных принтерах? И хочу при этом получать всегда одинаковые физические размеры отпечатка. Кроме того текстовые редакторы, куда эту картинку вставляют, ничего не знают о разрешении принтера и картинка размещается на в редакторе с теми физическими размерами относительно листа, которые соответствуют dpi в файле, а в противном случае экранному (что неприемлемо).
Да, вы правы. Но вероятность встретить ее в заголовке cгенерированным GD (а функция ищет первое такое вхождение) ничтожна и для моих личных целей хватило и такого примитива. В идеале конечно было бы неплохо пройтись по чункам.
Я для себя написал класс. Который принимает данные и генерирует особого вида графики по этим данным. Эти графики мне надо вставлять в документы в OpenOffice или же в Word и затем распечатывать.
Так вот, когда я хочу получить график размером 10x15см к примеру. То я передаю в свой класс эти размеры в сантиметрах, а также мне известно, что мой старенький лазерный принтер хорошо печатает с разрешением 600dpi. Эту цифру я тоже передаю в свой класс. В итоге получаю картинку 2362px × 3543px с прописанным внутри разрешением 600dpi. Теперь если я ее вставлю в «Word» или «OpenOffice Редактор текстов», то она там будет действительно 10x15см.
Поэтому жителям разных городов яндекс в поиске преимущественно выдает сайты учреждений относящихся к их городам. Так называемый региональный поиск.
В полиграфии параметр dpi используется повсеместно и они находят это вполне удобным. Например рекламные щиты печатаются реально с очень низким dpi, на них будут смотреть из далека, а работать гигантским файлом было бы много сложнее. Хотя плоттеры на которых эти щиты печатаются чаще всего используют гораздо большую разрешающую способность. Кроме того когда я передаю файл в печать, мне чаще всего ничего не известно о технике, которую они там используют. И не стану же я для каждого принтера, каждого печатающего устройства готовить свой, отдельный файл? Мне проще сгенерировать один с заданным разрешением, которого мне вполне достаточно и использовать его повсюду.
опечатался, IDAT конечно.
В png-шках получаемых из GD перед первым IDAT чанком только стандартный идентификатор PNG и IHDR чанк содержащий:
Width: 4 bytes
Height: 4 bytes
Bit depth: 1 byte
Color type: 1 byte
Compression method: 1 byte
Filter method: 1 byte
Interlace method: 1 byte
Какова вероятность того, что в сочетании этих параметров или в CRC32 от них+заголовок мы получим последовательность байт которая будет соответствовать ASCII «pHYs»?
Я указал в топике, что не претендую на грамотный алгоритм вставки чанка, мне сей код нужен только чтобы для себя пару картинок в неделю генерить.
Именно чтобы из 1 получить 3 и служит dpi в файле.
Если я имею картинку 1x1px, то достаточно указать разрешение 1dpi.
Если 10x10 то 10dpi, а если скажем 10000x10000 то 10000dpi.
Также я получу картинку в один дюйм из файла 50x666 если пропишу ему по горизонтали 50dpi, а по вертикали 666dpi.
При печати во всех случаях я получу картинку в в один дюйм. Качество может быть разным, но если это квадрат малевича, то разницы не будет.
Я в своем классе могу задать графику любые физические размеры. При этом какой бы я dpi не задал, он будет на печати ровно с теми физическими размерами которые я указал, хотя будет сгенерировано разное количество пикселей.
При этом если в файле не указан dpi, то за дефолт часто берется системное разрешение (например 96 dpi).
К тому же это вы знаете разрешение своего принтера, а если я хочу печатать картинку на разных принтерах? И хочу при этом получать всегда одинаковые физические размеры отпечатка. Кроме того текстовые редакторы, куда эту картинку вставляют, ничего не знают о разрешении принтера и картинка размещается на в редакторе с теми физическими размерами относительно листа, которые соответствуют dpi в файле, а в противном случае экранному (что неприемлемо).
Так вот, когда я хочу получить график размером 10x15см к примеру. То я передаю в свой класс эти размеры в сантиметрах, а также мне известно, что мой старенький лазерный принтер хорошо печатает с разрешением 600dpi. Эту цифру я тоже передаю в свой класс. В итоге получаю картинку 2362px × 3543px с прописанным внутри разрешением 600dpi. Теперь если я ее вставлю в «Word» или «OpenOffice Редактор текстов», то она там будет действительно 10x15см.