История изменений

У тебя на один чёрный квадрат 12 байт. Если даже было бы можно подмену констант, то было бы всё равно 10 байт. Выигрышь всего лишь 17%.

Допустим, чёрных и белых квадратов 50/50. В таком случае на один чёрный + один белый квадрат в монохромной картинке приходится 2 бита. Или 0.25 байта. То есть В 48 раз выгоднее (в 40 раз если бы были константы).

Даже если белых квадратов в 7 раз больше, чем чёрных (что неверно для QR-кодов, там не настолько много белых квадратов), то всё равно вышло бы 1 байт на 1 чёрный квадрат и 7 белых. И это всё равно в 10 или 12 раз выгоднее.

Обычный монохромный bmp, даже не png, вообще без никакого сжатия, рвёт представление квадратами как Тузик грелку. Не верю я, что может быть иначе (для QR-кодов). Это физически невозможно. Чтобы векторное представление выигрывало растровое, белых квадратов должно быть в ДЕСЯТКИ раз больше, чем чёрных (и это без сжатия, со сжатием там будет речь о сотнях и тысячах раз уже). Покажите мне такой QR-код.

Вы как-то неправильно вставляете картинку в PDF. Возможно, она не монохромная. Возможно, вместо генерации маленькой картинки (чтобы 1 квадрат = 1 пиксель) и её растягивания, вы делаете большую картинку.

Вот это надо фиксить, а не изобретать свои алгоритмы сжатия. Даже руками (в смысле без высокоуровневых либ) отредактировать PDF и заменить условный placeholder на самодельно скрафченную картинку (если библиотека генерации PDF прям никак не даёт вставлять картинки), будет проще и надёжнее изобретения своего алгоритма сжатия прямоугольников. Вы не туда копаете просто.

У тебя на один чёрный квадрат 12 байт. Если даже было бы можно подмену констант, то было бы всё равно 10 байт. Выигрышь всего лишь 17%.

Допустим, чёрных и белых квадратов 50/50. В таком случае на один чёрный + один белый квадрат в монохромной картинке приходится 2 бита. Или 0.25 байта. То есть В 48 раз выгоднее (в 40 раз если бы были константы).

Даже если белых квадратов в 7 раз больше, чем чёрных (что неверно для QR-кодов, там не настолько много белых квадратов), то всё равно вышло бы 1 байт на 1 чёрный квадрат и 7 белых. И это всё равно в 10 или 12 раз выгоднее.

Обычный монохромный bmp, даже не png, вообще без никакого сжатия, рвёт представление квадратами как Тузик грелку. Не верю я, что может быть иначе (для QR-кодов). Это физически невозможно. Чтобы векторное представление выигрывало растровое, белых квадратов должно быть в ДЕСЯТКИ раз больше, чем чёрных (и это без сжатия, со сжатием там будет речь о сотнях и тысячах раз уже). Покажите мне такой QR-код.

Вы как-то неправильно вставляете картинку в PDF. Возможно, она не монохромная. Возможно, вместо генерации маленькой картинки (чтобы 1 квадрат = 1 пиксель) и её растягивания, вы делаете большую картинку.

Вот это надо фиксить, а не изобретать свои алгоритмы сжатия. Даже руками отредактировать PDF и заменить условный placeholder на самодельно скрафченную картинку (если библиотека генерации PDF прям никак не даёт вставлять картинки), будет проще и надёжнее изобретения своего алгоритма сжатия прямоугольников. Вы не туда копаете просто.

У тебя на один чёрный квадрат 12 байт. Если даже было бы можно подмену констант, то было бы всё равно 10 байт. Выигрышь всего лишь 17%.

Допустим, чёрных и белых квадратов 50/50. В таком случае на один чёрный + один белый квадрат в монохромной картинке приходится 2 бита. Или 0.25 байта. То есть В 48 раз выгоднее (в 40 раз если бы были константы).

Даже если белых квадратов в 7 раз больше, чем чёрных (что неверно для QR-кодов, там не настолько много белых квадратов), то всё равно вышло бы 1 байт на 1 чёрный квадрат и 7 белых. И это всё равно в 10 или 12 раз выгоднее.

Обычный монохромный bmp, даже не png, вообще без никакого сжатия, рвёт представление квадратами как Тузик грелку. Не верю я, что может быть иначе (для QR-кодов). Это физически невозможно. Чтобы векторное представление выигрывало растровое, белых квадратов должно быть в ДЕСЯТКИ раз больше, чем чёрных. Покажите мне такой QR-код.

Вы как-то неправильно вставляете картинку в PDF. Возможно, она не монохромная. Возможно, вместо генерации маленькой картинки (чтобы 1 квадрат = 1 пиксель) и её растягивания, вы делаете большую картинку.

Вот это надо фиксить, а не изобретать свои алгоритмы сжатия. Даже руками отредактировать PDF и заменить условный placeholder на самодельно скрафченную картинку (если библиотека генерации PDF прям никак не даёт вставлять картинки), будет проще и надёжнее изобретения своего алгоритма сжатия прямоугольников. Вы не туда копаете просто.

У тебя на один чёрный квадрат 12 байт. Если даже было бы можно подмену констант, то было бы всё равно 10 байт. Выигрышь всего лишь 17%.

Допустим, чёрных и белых квадратов 50/50. В таком случае на один чёрный + один белый квадрат в монохромной картинке приходится 2 бита. Или 0.25 байта. То есть В 48 раз выгоднее (в 40 раз если бы были константы).

Даже если белых квадратов в 7 раз больше, чем чёрных (что неверно для QR-кодов, там не настолько много белых квадратов), то всё равно вышло бы 1 байт на 1 чёрный квадрат и 7 белых. И это всё равно в 10 или 12 раз выгоднее.

Обычный монохромный bmp, даже не png, вообще без никакого сжатия, рвёт представление квадратами как Тузик грелку. Не верю я, что может быть иначе (для QR-кодов). Это физически невозможно.

Вы как-то неправильно вставляете картинку в PDF. Возможно, она не монохромная. Возможно, вместо генерации маленькой картинки (чтобы 1 квадрат = 1 пиксель) и её растягивания, вы делаете большую картинку.

Вот это надо фиксить, а не изобретать свои алгоритмы сжатия. Даже руками отредактировать PDF и заменить условный placeholder на самодельно скрафченную картинку (если библиотека генерации PDF прям никак не даёт вставлять картинки), будет проще и надёжнее изобретения своего алгоритма сжатия прямоугольников. Вы не туда копаете просто.

У тебя на один чёрный квадрат 12 байт. Если даже было бы можно подмену констант, то было бы всё равно 10 байт. Выигрышь всего лишь 20%.

Допустим, чёрных и белых квадратов 50/50. В таком случае на один чёрный + один белый квадрат в монохромной картинке приходится 2 бита. Или 0.25 байта. То есть В 48 раз выгоднее (в 40 раз если бы были константы).

Даже если белых квадратов в 7 раз больше, чем чёрных (что неверно для QR-кодов, там не настолько много белых квадратов), то всё равно вышло бы 1 байт на 1 чёрный квадрат и 7 белых. И это всё равно в 10 или 12 раз выгоднее.

Обычный монохромный bmp, даже не png, вообще без никакого сжатия, рвёт представление квадратами как Тузик грелку. Не верю я, что может быть иначе (для QR-кодов). Это физически невозможно.

Вы как-то неправильно вставляете картинку в PDF. Возможно, она не монохромная. Возможно, вместо генерации маленькой картинки (чтобы 1 квадрат = 1 пиксель) и её растягивания, вы делаете большую картинку.

Вот это надо фиксить, а не изобретать свои алгоритмы сжатия. Даже руками отредактировать PDF и заменить условный placeholder на самодельно скрафченную картинку (если библиотека генерации PDF прям никак не даёт вставлять картинки), будет проще и надёжнее изобретения своего алгоритма сжатия прямоугольников. Вы не туда копаете просто.

У тебя на один чёрный квадрат 12 байт. Если даже было бы можно подмену констант, то было бы всё равно 10 байт.

Допустим, чёрных и белых квадратов 50/50. В таком случае на один чёрный + один белый квадрат в монохромной картинке приходится 2 бита. Или 0.25 байта. То есть В 48 раз выгоднее (в 40 раз если бы были константы).

Даже если белых квадратов в 7 раз больше, чем чёрных (что неверно для QR-кодов, там не настолько много белых квадратов), то всё равно вышло бы 1 байт на 1 чёрный квадрат и 7 белых. И это всё равно в 10 или 12 раз выгоднее.

Обычный монохромный bmp, даже не png, вообще без никакого сжатия, рвёт представление квадратами как Тузик грелку. Не верю я, что может быть иначе (для QR-кодов). Это физически невозможно.

Вы как-то неправильно вставляете картинку в PDF. Возможно, она не монохромная. Возможно, вместо генерации маленькой картинки (чтобы 1 квадрат = 1 пиксель) и её растягивания, вы делаете большую картинку.

Вот это надо фиксить, а не изобретать свои алгоритмы сжатия. Даже руками отредактировать PDF и заменить условный placeholder на самодельно скрафченную картинку (если библиотека генерации PDF прям никак не даёт вставлять картинки), будет проще и надёжнее изобретения своего алгоритма сжатия прямоугольников. Вы не туда копаете просто.