Comments 44
А можете показать пару графиков изменения «реального» размера файла? Ну или количества нулей, что то же самое.
Странно, я думал что наоборот сильно скрученная картинка (левая картинка из первой тройки) имеет больше плотность переходов между «кольцами» спирали => имеет больше градиентов => больше размер => меньше нулей в конце.
Или имеется ввиду сравнение количества нулей в последовательно идущих искаженных изображений?
Или имеется ввиду сравнение количества нулей в последовательно идущих искаженных изображений?
Именно, между двумя последовательными.
Не вдавался в нюансы формата JPG, но если в заголовке там указывается «размер тела», то не обязательно концовку нулями заполнять, можно просто мусором. Хотя если есть размер тела в заголовке, то нули в конце не обязательно подсчитывать. Можно просто размеры тела сравнивать.
Спасибо! А вот тут автор уложился в 23 строки
с вероятностью практически 100% будут иметь различный размер в байтах
Вообще-то, если говорить строго, то есть вероятность больше нуля, что размеры изображения будут совпадать с точностью до байта. Даже если разброс в размерах JPEG-изображений одинакового размера будет колебаться от 1Кб до 1000Кб, то вероятность того, что следующая картинка будет такого же размера, что и предыдущая равна 1/1000. Что не так уж и мало.
А чем меньше изображение, тем этот разброс в размерах в байтах будет меньше.
Вы такой умный.
Для тех, кто не заценил мой острый комментарий:
а) то, что с некоторой вероятностью размеры могут и совпасть — очевидно, и нет большой заслуги в том, чтобы явно указывать на это.
б) то, что для разброса в n байт вероятность совпадения 1/n в общем случае не верно. Предположение о равномерном распределении ничем не подкреплено, и, как минимум, интуитивно понятно, что оно неверное. С таким же успехом можно утверждать, что вероятность совпадения 1/2 — ведь либо совпали, либо не совпали.
Так что не стоит оперировать понятиями теории вероятностей, не будучи знакомым с ней в какой-то минимальной степени.
Принимая во внимание два вышеуказанных тезиса, смело заявляю, что комментарий Error_403_Forbidden не содержательный, а частично и вовсе содержит неверные утверждения.
а) то, что с некоторой вероятностью размеры могут и совпасть — очевидно, и нет большой заслуги в том, чтобы явно указывать на это.
б) то, что для разброса в n байт вероятность совпадения 1/n в общем случае не верно. Предположение о равномерном распределении ничем не подкреплено, и, как минимум, интуитивно понятно, что оно неверное. С таким же успехом можно утверждать, что вероятность совпадения 1/2 — ведь либо совпали, либо не совпали.
Так что не стоит оперировать понятиями теории вероятностей, не будучи знакомым с ней в какой-то минимальной степени.
Принимая во внимание два вышеуказанных тезиса, смело заявляю, что комментарий Error_403_Forbidden не содержательный, а частично и вовсе содержит неверные утверждения.
Да, это так. Для примера — обе jpg-картинки имеют одинаковый размер и весят по 20304 байт каждая:
и
и
Интересно, интересно… Правда сжаты они в Lossless-режиме, в хедере у обоих картинок: «CREATOR: gd-jpeg v1.0 (using IJG JPEG v80), quality = 100».
Но странно, почему после Хаффмана они все еще совпадают байт-в-байт? Впрочем, к этим картинкам подход совершенно другой нужен.
Но странно, почему после Хаффмана они все еще совпадают байт-в-байт? Впрочем, к этим картинкам подход совершенно другой нужен.
Ничего странного нет. Обе картинки состоят из разных данных и после сжатия их размер непредсказуем. А раз так, то ничто не мешает им случайно совпасть.
Скажем, приведённые выше изображения в данном размере, таких же примерно насыщенности деталями и степени сжатия, будут примерно в пределах от 5000 байт до, например, 35000 байт.
Получается, что уникальных по объёму изображений может быть только 30000. Ведь и миллион таких картинок будет укладываться в этот диапазон объёма. Иначе были бы мегабайтные картинки, что невозможно при данных условиях сжатия JPEG.
Скажем, приведённые выше изображения в данном размере, таких же примерно насыщенности деталями и степени сжатия, будут примерно в пределах от 5000 байт до, например, 35000 байт.
Получается, что уникальных по объёму изображений может быть только 30000. Ведь и миллион таких картинок будет укладываться в этот диапазон объёма. Иначе были бы мегабайтные картинки, что невозможно при данных условиях сжатия JPEG.
Более того, у некоторых алгоритмов сжатия (того же JPEG2000) можно кодеку прямо указать, сколько байт нужно получить на выходе.
Да и так как бе, тоже можно. Но байт в байт сомневаюсь.
О, у JPEG2000 совсем другая, отдельная, очень интересная, достойная отдельного поста алгоритмическая база: вейвлеты.
Значит, нужно добавлять шум во все картинки. Это может помочь.
Или наоборот слегка размывать — основную побольше, остальные поменьше.
Или просто в лосслесс выводить в bmp) Или его можно сжать в jpg и прогнать алгоритмом автора?)
Безусловно, может. А тогда мы берем «Решение MintEye CAPTCHA в 23 строки кода» на Python.
Им нужно доработать алгоритм так, чтобы сжатие было с возрастающим «к краям гистограммы» уровнем качества. Тогда результирующий размер будет выравниваться и такой статистический подход перестанет работать.
А почему нельзя концы картинок заполнить не нулями, а рандомным содержимым? Причем, разным у образца и у той картинки которая в списке.
...«блок кодирования» — это линейный массив из 64 байт, получаеый из блока изображения размером 8x8 пикселов путем обхода его по вот такой хитрой траектории, напоминающей «змейку»;
К «блокам кодирования» применяется дискретное косинусное преобразование...
Вы видимо решили, что к линейному массиву применяется DCT-II с N = 64? Нет, на самом деле, матрица 8x8 исходных значений (Y, Cb или Cr), подвергается DCT-II с N = 8 сначала по всем строкам (итого 8 раз DCT), а затем, по полученным коэффициэнтам еще 8 раз, но по столбцам. Можно наоборот, сначала по столбцам, затем по строкам, результат будет тот же.
Короче, у вас перепутаны этапы кодирования. Сначала блок 8x8 подвергается ДКП, результатом которого является матрица коэффициэнтов. Левое верхнее значение — самый значащий коэффициэнт — DC. И чем дальше от этого значения, тем более высокочастотны и менее значащи коэффициэнты. Затем квантование этой матрицы (вообще, там нет никакого порога, значения матрицы умножают на значения матрицы квантования) И поэтому, именно эти коэффициэнты, а не сами исходные значения, записывают в зигзагообразном порядке, чтобы обойти сначала более, а затем менее значащие. А длинный хвост обнуленных значений кодируется очень хорошо :)
Ну и справедливости ради отмечу, что согласно спецификации, преобразование в YCbCr не обязательно. Downsampling выполняется не всегда, и не обязательно 1:2. А вот разбиение на блоки именно 8x8 заданы спецификацией.
К «блокам кодирования» применяется дискретное косинусное преобразование...
Вы видимо решили, что к линейному массиву применяется DCT-II с N = 64? Нет, на самом деле, матрица 8x8 исходных значений (Y, Cb или Cr), подвергается DCT-II с N = 8 сначала по всем строкам (итого 8 раз DCT), а затем, по полученным коэффициэнтам еще 8 раз, но по столбцам. Можно наоборот, сначала по столбцам, затем по строкам, результат будет тот же.
Короче, у вас перепутаны этапы кодирования. Сначала блок 8x8 подвергается ДКП, результатом которого является матрица коэффициэнтов. Левое верхнее значение — самый значащий коэффициэнт — DC. И чем дальше от этого значения, тем более высокочастотны и менее значащи коэффициэнты. Затем квантование этой матрицы (вообще, там нет никакого порога, значения матрицы умножают на значения матрицы квантования) И поэтому, именно эти коэффициэнты, а не сами исходные значения, записывают в зигзагообразном порядке, чтобы обойти сначала более, а затем менее значащие. А длинный хвост обнуленных значений кодируется очень хорошо :)
Ну и справедливости ради отмечу, что согласно спецификации, преобразование в YCbCr не обязательно. Downsampling выполняется не всегда, и не обязательно 1:2. А вот разбиение на блоки именно 8x8 заданы спецификацией.
Sign up to leave a comment.
Решение MintEye CAPTCHA в 31 строку кода, даже не открывая картинку