Прошлый опыт, в т.ч. научный, по JPEG (применимый к любому формату изображения):

- для каждого изображения - свой уникальный процент сжатия "без потери качества". Написание высчитывающего такой процент ПО, медленного из-за количества итераций, учитывающего размер монитора и разрешение изображения, - хорошая бакалаврская/магистерская работа. Однако с текущим качеством стажёров и практикантов: 100% придётся такую программу писать самому, т.к. они такое не осилят. А мозги в 40 уже не те, что в 23: алгоритмы хорошо работают, но кодинг уже хромает. Плюс к этому добавляется отказ от программирования как снижение нагрузки на сердце и мозги - и мозг теперь сам отторгает программирование на подсознательном уровне (по крайней мере, недружественное);

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

- 96dpi - стандартное количество пикселей на дюйм.

Попытка найти программу корректного пакетного сжатия изображений:

- если сделать скриншот PNG с помощью FastStone Capture и пересохранить его в MsPaint - размер изображения сильно увеличивается. Как минимум, говорит о том, что FastStone Capture хорошо сжимает PNG;

- онлайн-сервисы не дают возможности бесплатной большой пакетной обработки. И их можно понять: все сайтостроители ринутся к ним - и сервер ляжет;

- Image Optimizer Pro v.5.10.6010 - падает при таком количестве фотографий (или ещё по каким причинам). Также он переделывает не-JPEG-форматы в JPEG (и пересохраняет файл, если он получился большего размера). То есть, точно нужно искать современную оффлайн-программу на замену текущей. Вот так у программистов и происходит: тратишь месяцы жизни, пишешь отличную прогу - а потом бац и устарела;

- NConvert - неудобный, т.к. консольный;

- были ещё какие-то оффлайн-программы по сжатию изображений - все они провалились. Дальнейшие попытки вспомнить, что там проверял и чем - не имеют практической значимости.

И вот, наступает одно крайне раннее утро, и начинается оно скверно:

- вставать в отпуске в 5 утра, без возможности заснуть обратно, - ну такое себе;

- в ашане заказ не сделал, жрать нечего - жуёшь последние блины из морозилки;

- повторная обработка плесени белизной в ванной: приводит к тому, что хлор не выветрился до конца в нужное время, - приходится сидеть в туалете в респираторе;

- и вот, сидя в респираторе, как скульптура Огюста Родена "Мыслитель", внезапно рождается решение: XnConvert. Упоминаемая единственный раз одной строчкой в статье от 2014 года - она оказалась не просто решением проблемы сжатия изображений, а сжала их на -83%.

Изменение DPI на 96 - не влияло никак на сжатие. Выставление для JPEG 65% сжатия, вместо правильных 75%, - уменьшение с 1.14ГиБ до 790МиБ. А дальше пришло неожиданное понимание: принудительное уменьшение разрешения на 1024x768 с опцией "подогнать" с сохранением пропорций - уменьшение размера до 195МиБ. Но прикол в том, что даже для большого монитора - это разрешение оказалось достаточным для просмотра и мелких деталей (хоть и добавилась заметная зернистость при увеличении на весь экран - более чем логично). Ну а на мобильных телефонах - вообще незаметно будет (и грузиться будет быстрее, и трафик экономить).

Теперь, когда сжатые изображения были созданы (и автоматически сохранена структура их расположения), - их нужно правильно внедрить (просто копировать с заменой):

- архивная копия имеющихся фото. Несколько дней на подумать, всё ли верно сделано: уж очень низкое разрешение выбрано - не исключено, что нужно 1280x960;

- сохранение в исходном виде тех фото, что создавались, например, при анализе фотоаппаратов или проверке их матрицы;

- создание на сайте системы, отображающей все фото в фиксированном горизонтальном разрешении сколько-то там пикселей (уже давно сделано);

- все фотографии разделять на годы в настоящем и будущем. И если папка 2025 года вышла с ошибкой (новые фото к старым статьям - клал вне папки 2025), то в папке 2026 года ошибок уже не будет;

- добавить заметку о ежегодном пережатии изображений, сохранив программу с нужными настройками (она Portable).

...мерзость в том, что эта программа написана на Qt... Но при этом, реализована многопоточность - и все фото были обработаны на 23 ядрах всего за 1 минуту.

(добавлено 04.09.2025) Работы над ошибками:

- когда применял низкое разрешение и 96dpi - забыл JPEG Quality с 65% на 75% поднять. Размер бы увеличился на 27МиБ. Здесь может быть критический момент: когда сжимал PDF - выбирал среднее качество, а не максимальное сжатие (на максимуме - артефакты ну очень сильно заметны были);

- но в случае с фото, разница в 10% практически не отразилась на качестве изображения (реально, всматриваться приходится, - дрочка на пиксели);

- качество разных фото - лучше привести в примере: оригинал (838КБ) - 75% (98КБ) - 65% (77.6КБ). На этом примере - особенность ещё: чем всратее изначальная фотография - тем менее заметны артефакты после сжатия. Поэтому, в противовес, - фотография с зеркалки Canon 350D: ранее чем-то несильно сжатый оригинал (509КБ) - 75% (82.4КБ) - 65% (66.3КБ);

- очень была заметна разница на некоторых PNG (скорее всего, являющихся скринами экрана с помощью MSI Afterburner, - плохая компрессия). Например, ранее: оригинал из Эпохи империй 2 весил 4МБ - после сжатия стал весить 1.48МБ. Но если его сохранить в JPEG, даже вручную в MsPaint, - будет весить до 367КБ. Значит, пару десятков файлов, упорядоченных по размеру и являющихся PNG, - надо пережать. А потом переименовать .jpg в .png: браузеры успешно открывают файл как надо - а ссылки исправлять при этом не требуется. А вот что делать сначала: пережимать оригинал или пересохранять в JPEG - вопрос (скорее всего, второе - и лучше оба действия сделать сразу с помощью XnConvert, если там есть такой функционал).

Сразу дописывается про PNG (доэкспериментировался - требуется переделывать):

- изначальные PNG с высоким разрешением - сжаты оказались не очень хорошо: уменьшение разрешения - все мелкие надписи видно с трудом, а на скриншотах Эпохи империй - вообще не видно;

- в идеале, нужно пересохранять без изменения разрешения - в JPG 75%. Прогрессивный - по желанию (но интуитивно - лучше, чтобы фото грузились снизу вверх а не от размытости к чёткости). Но это - ручная работа. И возникнет вопрос: как оставить пережатые JPG как есть - и заменить на сайте только PNG. Судя по всему, придётся тоже вручную по папкам лазить;

- решение - оказалось верным. Так как изменяется разрешение только у больших скриншотов - таких файлов оказалось всего 48шт из ~500шт. Пережал в JPEG автоматически XnConvert, своей программулиной изменил расширение, аккуратно залил на сайт. 63МБ было сжато до 8МБ, разница при просмотре - практически незаметна;

- а ведь то же самое надо сделать с GIF. Но таких файлов больших - уже единицы. И оказалось, возиться вообще с ними смысла нет: выходные JPEG-файлы оказываются больше по размеру, практически все из крупных.

Подгонка под размер 1024x768 - с изменением в меньшую сторону: попадались изображения вида 998x768.

Обязательно использование опции "Сохранять исходный файл, если результат кодирования больше". Несмотря на экспериментальность - прекрасно скосила ещё 30МБ. Пришлось пережимать все вчерашние исходные изображения заново - уменьшение не до 195МиБ, а до ~160МиБ. Собственно, и оказалось: сохранялись избыточные по размеру GIF, некорректно пережатые в большую сторону.

(добавлено 05.09.2025) После повторной перезаливки фото - забыл про "сохранение в исходном виде тех фото, что создавались, например, при анализе фотоаппаратов или проверке их матрицы". Об этом строго напомнил плагин Eyesite, сканирующий ежедневно сайт на изменения файлов.

(добавлено 13.09.2025) Файлы с атрибутом "только чтение" - пропускаются. Не нашёл, где исправлять в программе, - просто атрибут с файлов снял.

Сжимал фотографии домашние - получилось -30%, при JPEG Quality 65% и неизменном разрешении. Смотрел на кошку, сделанную на Canon 350D, - и не увидел разницы визуально вообще никакой, переключая фото в просмотрщике Windows. При этом, исходник весит 978КБ, а преобразованное - 615КБ.

Копируемые же фото с FTP - не имеют признака "только чтение", но оно проставляется папкам - что не влияет на функциональность обработки.