> Есть варианты. Берёшь jxl 96/97 и у тебя всегда одинаковоВспомнилось. BBS. Sysop вызывает юзера закачавшего файло на чат.
- Что ты мне сейчас залил? "icons.zph"? Это что?!
- Новая коллекция иконок для Windows!
- Это я вижу, но что такое zph?!
- Новый крутой архиватор, жмет на 10% лучше чем ZIP!
- Отлично, а где его взять? Ты его залил?
- Понятия не имею. Мне не нужны эти иконки.
- Ах так?! Вот тебе, с$%^а!!! (банит юзера - disconnected)
Это я намекаю - чего мне с jxl потом делать? Его поддержка в софте - никакая. По поводу чего он то редактором не откроется, то той вьюхой, то тумбнайлы не сгенерятся. И все это счастье - например зачем?
> идеальный файл в треть лосслесс размером.
Меня не интересуют такие уровни сжатия в lossy, как категория. Для меня lossless - это исходники. С каждым последним битиком в LSB. Я выделяю минимум 2 случая:
1) Равки с камер и т.п.. Они вообще без сжатия бывают, их никто никогда "внутри" не трогает, все RAW процессоры гоняют "пайплайн процессинга" с оригиналом на входе, а выхлоп - на экран или в НОВЫЙ файл, при том в этом случае - в менее эзотеричном формате (обычный софт не готов столкнуться с байеровским порядком пикселей и проч). У них иногда бывает (мелкий и пережатый) жыпег встроен - в этом случае тумбнайлеры могут кой-как показать что это было, а суперкачества в плитке превью с кошкин зад и не надо, там важно понять что это такое. Это не подлежит трансмутации в другие форматы из-за потерь довольно много чего в этом процессе, начиная с того что дебайер можно делать по разному и это уже "не совсем lossless" операция (для получения RGB часть пикселей интерполируется).
2) То что я отрисовал или перерисовал, bitmap graphics. Это обычно PNG, если нет каких-то специальных соображений. Оно уже сжатое и это исходник для редактирования, lossy там не катит из-за постепенного накопления ошибки при многократных кодированиях и/или очень острых границ которые lossy принципиально не подарок.
> Если можно пожать лучше, то ещё и пожмёт, без вот этих вот рандомных спайков размера
> из-за кучи артефактов.
Рандомные вариации размера - следствие того что разное содержимое разное в "сложности кодирования" и "содержит разное количество информации". Однотонный серый фон содержит меньше информации чем картинка с множеством мелких деталей. Уравниловка в размере ведет лишь к тому что кто-то или получает избыток битов и жрет место зря и/или получает недостатк битов и картинка портится.
Поэтому все сколь-нибудь продвинутые форматы - "VBR" если можно так сказать (это скорее актуальнее для видео/аудио, но идея зависимости размера от сложности материала остается). В этом случае мы просим энное визуальное качество, а битов накинуто столько, сколько надо чтобы обеспечить его, для конкретно той сцены.
> Или можно взять jxl lossless и получить самое эффективное кодирование без потерь.
Эффективное по срвнению с чем? В каком случае? И что мне потом с таким "лосслессом" делать, учитывая никакую поддержку в софте?
> Проблема плохих кодеров в том, что там где на одном файле почти незаметно, на
> другом будет совершенно невыносимое вырвиглазие,
Это то что вы получаете за желание одинакового размера. Не все сцены созданы равными с точки зрения их кодирования и объема информации в них.
> больно, но исходные данные это какие-нибудь сканы в 600dpi например и
> хранить такие гигабайты тоже такое себе.
А вот файлов в именно 600 dpi у меня не особо много и они, скажем так, специфичные (и жмутся PNG'ом просто офигенно).
И это... в этих сканах реально содержится столько инфо что там реально каждый пиксел важен? Или может быть, есть смысл сделать 600x600dpi -> 300x300 допустим, хорошим ресайзером? Это в 4 раза меньше пикселей сразу на старте. При том редкий сканер и документ настолько хорош, чтобы вот реально каждый пиксел был информативен. Но это довольно специфичная область, опять же. У меня вообще сканера нет и оцифрованные бумажные документы мне как таковые малоинтересны. Я как-то на более общеупотребилельном материале экспериментировал, типа фото и/или рисунков, мне такие применения сильно актуальнее.
