Комментарии 112
А самый маленький прозрачный gif весит 43 байта и имеет практическое применение как пиксель отслеживания, широчайшим образом применяется в интернет маркетинге.
А еще во времена табличной HTML-верстки прозрачный однопиксельный GIF использовался в качестве невидимой распорки. Эта техника была придумана дизайнером Дэвидом Сигелом и называлась Spacer GIF.
Подскажите андроид программу или онлайн сервис который конвертирует изображение чертежей в черно белый скан с минимально возможным весом
Ссылки на w3.org на устаревшую версию статьи и там вылазит плашка на весь экран о том, что надо бы перейти на новую. Я заподозрил что в старой версии что-то другое и ссылка специально именно туда ведёт, но нет. Просто перевод сделан по принципу "и так сойдёт".
Например, актуальная версия https://www.w3.org/TR/png-3/#7Filtering
Старая https://www.w3.org/TR/2022/WD-png-3-20221025/#3filter
Огромное спасибо за то, что ткнули носом. Статья, естественно, не написана по указанному вами принципу, и это понятно внимательному читателю. Но сей момент я, отчасти сознательно, проглядел. Успехов вам и всех благ! P.S. исправил
Нет, не исправили. У Вас по всему тексту куча ссылок.
> Эта запись называется сигнатурой
вместо ссылки на https://www.w3.org/TR/png-3/ могла бы быть на конкретную главу. Как в оригинале, но с поправкой на версию сайта: https://www.w3.org/TR/png-3/#3PNGsignature
И такое по всей статье
> описываются четырьмя полями,
> идёт тип IHDR.
> причём регистр имеет значение.
> это битовая глубина и цветовая модель.
> них в спецификации PNG.
> отражает метод сжатия.
> касается метода фильтрации.
> является метод интерлейсинга.
> завершается контрольной суммой
и так далее, мне уже лень смотреть.
По тексту целая куча ссылок на конкретные главы. И если читать статью не по-диагонали, все эти ссылки на конкретные места в стандарте нужны. Вы часть заменили на бесполезное повторение https://www.w3.org/TR/png-3/, часть ссылок забыли и они указывают на старую версию сайта.
Сохранил картинку с этим png, но там изображение 248 x 249 и размером 804 байта. Браузер FF.
Так это же 200 кратное увеличение.
При 200-кратном было бы 200x200.
А тут еще и пропорции искажены..
Кругом обман....
В изображении 200x200 - 40 000 пикселей, так что его правильнее считать сорокатысячекратным.
С самого начала вот эти 200 глаз резанули - целый квадратный корень не извлечь...
Да, каюсь, не удалось перенести исходную из оригинала в точности...
Любой PNG-файл начинается с одинаковых 8 байт
Похоже на решение из головы без особого на то обоснования, почему например 8, а не 4 или 32 байта. Похоже нет стандарта на идентификацию файлов, а это было бы удобно. То есть первые 8 байт отдали бы на идентификацию файлов, а в единой базе данных на весь мир можно было бы посмотреть соответствие, что именно это за файл и чем его открывать.
Для PNG можно было бы не делать такого, контрольная сумма все равно отсечет лишние файлы. А сейчас получается что миллиарды файлов этими 8 байтами занимают зря место на диске и замедляют загрузку файлов.
И жаль что не сделали видео формат на основе PNG, Mjpeg есть, а чего-то вроде Mpng не создали.
Потому что сжатие видео в PNG сильно проигрывает JPEG. Не стали делать никому ненужную работу. Реализовали только APNG по типу GIF.
И формат оказался не нужен. MNG кажется интереснее, но и сложнее. Возможно так же сыграл свою роль стандарт flash анимаций, популярный в то время, который мог делать векторную/спрайтовую анимацию лучше.
Несколько лет назад видел на Stackoverflow/Stackexchange страдания удалённого препода, что фиг чем нормальную онлайн-лекцию со слайдами запишешь, чтобы на любом девайсе можно было смотреть без установки специального софта, регистрации и смс. Там ему, в итоге, посоветовали записывать видео с низким фпс, но всё равно, кажется, получались файлы неадекватного размера. А сжатие в PNG скриншотов и простенькой графики (тонких линий, стрелок, буков, фигур и т. п.), напротив, сильно выигрывает у lossless JPEG.
Весьма редкая ситуация чтобы в видео было много графиков. Самое простое - прикладывать слайды в виде html/pdf страницы. Никакого доп. софта не нужно.
А ещё лучше и лекцию в html/pdf
Препод. Читает лекцию. Типа, у доски. Голосом. Только вместо доски какие-то типа слайды меняются, там, или софтина какая-то демонстрируется. Тысячи, миллионы роликов такого контента на том же ютубе, не говоря за всякие "образовательные платформы" типа Udacidy, какая ещё "весьма редкая ситуация"?? Как предполагается эти слайды в виде html/pdf с голосовым выступлением синхронизировать? Да чтобы по-простому, а не выкатывая очередную high scalability high availability enterprise production platform?
Проверил, действительно размер большой, попробовал картинку (текст сфотографированный) в видео преобразовать
https://video.online-convert.com/ru/convert/image-to-avi
Результат
Video: MSMPEG4v2 960x1280 25fps 1359kbps [V: msmpeg4v2, yuv420p, 960x1280, 1359 kb/s]
или 15 секунд размером 2.5 мегабайт, из картинки 0.2 мегабайта.
Перекодирование в h264 обычный ухудшило качество заметно, размер стал 1 мегабайт.
Даавдыым-даавдоо, когда ещё жители галактики не стали все поголовно использовать VLC, а приходилось устанавливать в систему кодек-паки, я себе на Windows XP ставил отдельный специальный кодек, оптимизированный под скринкасты. И качество, насколько помню, сохранялось отличное, и размер видеороликов выходил всего ничего - если, конечно, действительно использовать именно для скринкастов. Но сейчас, даже если бы получилось найти что-то подобное и вкорячить на Винду, Линукс и Мак, то что делать с многочисленными пользователями смартфонов и планшетов?
или 15 секунд размером 2.5 мегабайт, из картинки 0.2 мегабайта.
Если совершенно статичные "слайды", которые при этом редко меняются, то, возможно, ситуацию можно несколько улучшить, влупив lossless compression и 1 FPS (или даже меньше, не знаю, поддерживают все актуальные на сегодня плэеры дробный FPS?) Но всё равно оверхед дофига получится, плюс о том, чтобы что-то в реальном времени дописать или мышью показать можно забыть.
Независимо от фпс, видеопоток состоит из ключевых и промежуточных кадров. Промежуточные можно просто вырезать, а ключевые расставлять в произвольные временные точки. Весят ключевые кадры как джипеги.
"Можно просто вырезать" - это теоретически, или прям взаправду? Предположим, у меня есть аудио-файл заданной длины и набор картинок, для каждой из которых известно время, когда она должна появиться на экране. Какой командой ffmpeg мне сделать вот как вы сказали - чтобы в произвольных временных точках видеопотока стояли мои картинки (хорошо, пусть в джипегах, а не в пнг), а больше чтоб в этом видеопотоке ничего не было?
Я таким не занимался, начните поиски отсюда: https://ru.wikipedia.org/wiki/VirtualDub
Программы удаленного доступа к рабочему столу так и кодируют. Remote Administrator, Any Desk, Tightvnc. Any Desk может в своем формате ролики сохранять.
Apng
Есть формат сжатия видео HuffYUV - без потерь, но хоть с каким-то сжатием. По качеству лучше, чем Motion-JPEG, но и весит больше.
Не понимаю почему первый байт 0x89. Это ‰ (per mille sign).
PNG - понятно.
Хвост тоже понятен:
0x0D 0x0A = CR LF (универсальный перевод строки)
0x1A 0x0A = SUB LF
0x1A = Ctrl-Z
"SUB character (ASCII code 0x1A) is an unprintable character, but it should not cause problems with fgets. Try to read your file character by character with the fgetc function and see what happens. In Windows, 0x1A is commonly interpreted as end-of-file tag for text files."
"This character can be used in Unix operating systems. Here it's usually used in order to terminate the currently executing interactive process."
То есть если начать читать PNG файл как текстовый, то придет 4 читаемых символа, перевод строки, и завершение файла. Удобно.
The first two bytes distinguish PNG files on systems that expect the first two bytes to identify the file type uniquely. The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as a PNG file; also, it catches bad file transfers that clear bit 7
http://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R.PNG-file-signature
Им как раз нужен был непечатаный символ с кодом >127. Чтобы программы по ошибке не приняли текстовый файл с таких началом за PNG.
почему например 8,
обычно первый int оставляют под обозначение формата. Учитывая, что некоторые форматы могут иметь длинные названия или содержать версию оставляют некоторый запас.
Самый миниатюрный PNG в мире весит 67 байт и представляет собой один чёрный пиксель. Выше вы видите его в 200-кратном увеличении.
Малевич, ты? :)
Помнится в стародавние времена, когда на телефоне нельзя было генерировать динамические картинки, это делалось через генерацию динамических PNG, которые затем и выводились. Пришлось тогда разбираться во всех этих "чанках".
Картинки видимо пережаты Хабром и испорчены. Вот правильный png на 67 байт: https://belkadan.com/blog/2024/01/The-Biggest-Smallest-PNG/squarish.png
Самый миниатюрный PNG в мире весит 67 байт и представляет собой один чёрный пиксель.
пиксель Малевича
А в параллельной вселенной бракоделы создатели сайтов просто вставляют 1000x1000px на страницу тумбой 100x100 (и таких 100шт на страницу) и вообще не понимают про какие байты вы тут рассуждаете...
это что, я знал организацию, где новости для сайта сканировали с бумаги в 300 dpi и как есть, в виде графического файла с разрешением в несколько тысяч пикселей по каждой стороне, выкладывали в раздел новостей
Когда-то в начале 2000-х я, когда я устроился эникейщиком в одну контору, первое, что я сделал - это поменял все изображения товаров на их сайте, которые менеджер заливал туда в формате bmp на jpeg. Тут же прослыл гением, т.к. сайт стал загружаться в несколько раз быстрее (а это была еще эпоха dial-up модемов)
лучшее что я пока видел - картинки в слайдере по 27мб+ каждая, штук 20. А следом вопрос, почему сайт так медленно работает, не нужно ли железо поменять
Каталог товаров эйвонов/орифлеймов на 0.5ГБ такой: аче всмысле?
Тумбы 100x100 из-за низкой плотности пикселей в вашем дисплее. Данный сайт предусматривает комфортную работу для 16K 27"
Да и на «Хабре» полно статей с огромными фотографиями в формате PNG.
Мда уж. Пока одни мучительно выбирают между avif и webp по степени сжатия без заметных потерь, вставляют кучу версий одного изображения для разных экранов через srcset – кто-то и в ус не дует с оптимизацией ))
Так это у вас в мониторе 100 пикселей, а в телефоне будет больше, поэтому нельзя вставлять туда 100х100.
Upd. Я буду читать предыдущие комментарии перед отправкой своего.
Самый миниатюрный PNG в мире весит 67 байт и представляет собой один чёрный пиксель.
А белый пиксель или даже произвольная монохромная картинка 8х1 разве будет больше? Или из-за сжатия данные увеличатся в размере?
В довольно поэтичном стиле изображения PNG завершаются также, как начинаются
Немного занудства: здесь "так же" пишется раздельно.
тратились в пустую
А здесь "впустую" - слитно.
За статью спасибо, интересно.
Лучше выделить ошибку и нажать Ctrl+Enter
ну наконец-то. хоть кто-то пытается остановить это повальное адское правописание. без сарказма.
Спасибо, исправил, но лучше, действительно, через ctrl+enter, иначе в потоке комментов могу упустить сообщение.
Я уже спросил - как на смартфоне это нажать?
@Boomburumдля мобилок надо всплывашку прикрутить, как на некоторых сайтах сделан аналогичный функционал или цитирование
А что такое чанк так и не сказали.
Chunk - кусок. Похоже, близкий родственник Bite - укус.
Да как бы судя по контексту в среде вроде общепринятый англицизм. По-русски тупо "фрагмент", реально кусок, часть...
Дело не в том, что я не знаю.
Дело только в том, что в тексте заявлено «ща я вам скажу, что такое чанк», а ответа нет.
Я так понял это термин из спецификации - его семантический смысл вполне понятен из статьи )
А перед нами обыкновенный пипидастр.
Сейчас объясню, что это такое. Пипидастры состоят из удерживающего элемента и, собственно, рабочей зоны, которая может, в свою очередь, состоять из разных материалов, использование которых остается на усмотрение его владельца.
Теперь, когда всем уже понятно, что такое пипидастр и зачем он нужен, продолжим наше повествование.
Ну как же - это вещь, совершенно очевидная для тех программистов, кто работал с чанковыми структурами данных ;-)
Нда, никогда не подумал бы, что PNG такой неэффективный формат, учитывая что предложен он был еще в эпоху модемного интернета:
Несколько раз рассчитывается контрольная сумма.
Сжатие построчное - не самый эффективный метод.
Интересно, зачем вообще потребовалось сжимать построчно ? Я помню во времена медленного интернета картинка в браузере при загрузке отображалась строками, иногда в режиме interlaced.
Так и PNG, и JPEG бывает interlaced.
В стародавние времена сложное сжатие медленно работало и само требовало ресурсов. Вот и сделали как умели.
Про построчное сжатие помню нам в универе препод показывал прикольный трюк, что PNG с черно-белыми горизонтальными полосками весит в несколько раз меньше, чем такого же размера файл но с вертикальными полосками.
А самый маленький gif - 26 байт.
Если свести воедино все части:
89 50 4E 47 ; сигнатура файла, 8 байт,
0D 0A 1A 0A ; ‰PNG<CR><LF><SUB><LF>
00 00 00 0D ; длина данных чанка - 13 байт
49 48 44 52 ; тип чанка - IHDR
00 00 00 01 ; ширина
00 00 00 01 ; высота
01 ; битовая глубина
00 ; цветовая модель
00 ; метод сжатия
00 ; метод фильтрации
00 ; метод интерлейсинга
37 6E F9 24 ; контрольная сумма
00 00 00 0A ; 10 байт
49 44 41 54 ; IDAT
78 01 ; заголовок zlib
63 60 00 00 ; "сжатый" блок DEFLATE
00 02 00 01 ; контрольная сумма zlib
73 75 01 18 ; контрольная сумма
00 00 00 00 ; 0 байт
49 45 4E 44 ; IEND
AE 42 60 82 ; контрольная сумма
Дайте угадаю, коллега: Вам хорошо так за сорок (как и мне).
Современная молодёжь, боюсь, утратила древний навык получения знаний в концентрированном виде — на любой чих из трёх строчек теперь требуется опубликовать получасовое видео.
Тогда б сразу каким-нибудь kaitai struct прикладывать.
Современная молодёжь, получасовое видео.
Сейчас модно ругать молодёжь, за то что они уже не могут сосредоточиться полчаса на видео, поэтому всю инфу им подают в сжатом виде в виде тиктоков/рилсов/шортсов. Только непонятно, это шаг назад к корням, когда всё было зеленее, и нынешняя молодёжь образумилась, или шаг ещё дальше от корней, и надо ругать ещё больше?
всю инфу им подают в сжатом виде в виде тиктоков/рилсов/шортсов
А, просмотрев тикток/шортс, они смогут сами сделать то, что им показывают?
А вот прочитав приведённую выжимку, я теперь могу сам создать PNG-файл, и я не имею в виду "тупо повторить".
я теперь могу сам создать PNG-файл
Наверное потому, что до этого знали что такое вообще бинарный формат и как с ним работать. Потому что в выжимке только сухая минимальная тех. информация, и как с ней работать в человека по-умолчанию не заложено. Тогда какая разница, вы выжимку увидите текстом или кадром видео?
Тут дело скорей не в молодежи, а в уровне. Для меня короткое представление намного понятней (хотя мне меньше 40), экономит время на чтении текста. Хотя в статье есть другая интересная информация. Но начинающим может быть сложней ориентироваться в таком формате.
Как ленивая молодёжь, которая не может концентрироваться на чём-то больше 10 секунд, заявляю: кусок кода выше это отличный формат
В теории эти файлы не имеют предельного размера, но есть ограничение по количеству пикселей, и многие декодеры тоже накладывают свои рамки.
Так имеют или не имеют? Ограничение на количество пикселей - это и есть теоретическое ограничение (если для этого не используется BigInt).
Так имеют или не имеют?
По стандарту — не имеют, а на практике сколько килобайт хватит всем волюнтаристски решает тот, кто пишет декодер.
Занятный факт: если вы декодируете эти байты в виде ASCII, то увидите буквы PNG
Ну, не столько занятный, сколько общепринятый - у jpeg увидим JFIF или Exif, у pdf - PDF, у zip - PK (от PKZIP/PKUNZIP), да и многие "магические метки в заголовках" отсылают к названию формата или к породившему софту. Разве что у PNG заголовок весь из условно нормально печатных символов - "ЙPNG"+CR+LF+EOF
Разбираем самый маленький PNG в мире