Исходники и билды для Linux (Ubuntu 25.10, Nix выражение) и Шиндошс: https://github.com/shatsky/lightning-image-viewer
Веб-демо: https://shatsky.github.io/lightning-image-viewer/
Майкрософт стор: https://apps.microsoft.com/detail/9np4j8k90smk
Заметки про разработку: https://shatsky.github.io/notes/2025-03-07_sdl3-image-viewer.html
Крайний релиз 0.5.1, основные изменения с предыдущего мажорного релиза: image-rs (растовая библиотека номер 1 для работы с изображениями) с jxl-oxide и libheif-rs (обеспечивающие поддержку всех распространенных форматов, в т. ч. JXL и HEIC); поддержка анимации (для GIF, PNG и WEBP)
Спасибо за нейровысер, особенно за оправдания.
>2021
>нейровысер
Ладно.
Спасибо за бамп)
Есть в планах заменить jxl-oxide на jxl-rs?
Да, как только он перестанет быть WIP (и скорее всего на него сразу же перейдет image-rs, достаточно будет апнуть версию и выкинуть jxl-oxide).
При увеличении лучше не сглаживать пиксели.
Лучше не растягивать мелкие изображения.
А вообщее лучше это дело вынести в настройки, хотя бы в конфиг, чтобы каждый сделал как ему нравится.
>и скорее всего на него сразу же перейдет image-rs
Вряд ли, они там отказались от формата не из-за отсутствия декодера на расте, а из-за того, что спецификации нет в свободном доступе.
В конечном итоге выдумали хуки и всё, сами пилите поддержку для image-rs в своем jxl.
https://github.com/image-rs/image/issues/1979
https://github.com/image-rs/image/issues/1765#issuecomment-3237456866
Спасибо!
>планируешь тулбар прикрутить?
А надо?)
Рантайм конфиг будет. В данный момент есть билд тайм, дефы в исходнике можно оверрайдить, в том числе SCALEMODE_LOWER/SCALEMODE_EQUAL/SCALEMODE_GREATER. Кстати, SDL3 уже есть SDL_SCALEMODE_PIXELART, https://github.com/libsdl-org/SDL/commit/3e9e22f17dcc234cf77e73af47982905bd9b6912 https://www.youtube.com/watch?v=d6tp43wZqps
Но все же в общем случае пиксель это не прямоугольник, пиксель это сэмпл непрерывного 2д сигнала https://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf
Ох уж эти пуристы. Ну ладно, тогда хуком, как и сейчас.
Насколько я понимаю, декодирование лосслесс транскодед жпегов (чуть менее чем 100% пользовательских жпег-хл файлов) jxl-oxide поддерживает полностью без каких-либо изъянов, выигрыш будет только в скорости
1. не проприетарщина
2. не шиндошс онли
3. не депрекейтед
4. UX HoneyView - выглядит как типичный вьювер, в том числе:
- обычное окно, когда зумишь в нем - отображение ограничено его границами, нужно ресайзить или разворачивать окно, лишнее движение. У меня в прозрачном оверлее прямоугольник картинки при зуме "расширяется" соответственно сам
- зум скроллом только с контролом и в точку, которая в центре окна, а не под курсором. Я хочу, наведя курсор на нужную деталь, зумить скроллом ее, а не то, что в центре окна оказалось или где-то еще
- чтоб закрыть - надо тянуться к крестику или эскейпу, лишнее движение. Я хочу кликом по любому месту или энтером, чтоб быстро тугглить между файл менеджером и просмотром
Если ты не чувствуешь дискомфорта при просмотре сохраненок с HoneyView по сравнению с просмотром на дваче или других картинкосайтах с "лайтбоксом" или как это называют - для тебя нет смысла переходить
если ты хочешь прикрутить тулбар - то ты не понял сути проекта ящитаю
Вероятно, ты только под себя делаешь, и других вариантов не предусматриваешь. Это был намёк посмотреть, что уже придумано в куче других таких же утилит, не обязательно этой конккретной.
Я вообще не вижу никакого окна, когда смотрю картинки, они открываются на полный экран без всякого интерфейса и исчезают так же. В оконном виде то же самое. Довольно странно сначала показывать картинку в маленькой части экрана, а потом туда-сюда менять масштаб. Это решение с веб-страничек, которые не могут выйти за свои границы и вынуждены изобретать рюшечки. Вообще, возить туда-сюда колесом что-то странно, я пользуюсь только масштабом по ширине и на полный экран (оригинал, если меньше). Например, при чтении манги из архивов вообще используется один пробел и иногда смена масштаба. Если там елозить мышкой к каждому пузырю с текстом, это же пиздец сколько времени уйдёт. Такое ощущение, что возвращаемся к беспомощному просмотру картинок из Windows XP с бесполезной вознёй и отсутствием рефлекторного управления.
Всё это было ещё в древнем HoneyView3, если CDisplay не вспоминать. Улучшать там нечего, поэтому компания изобретает функции для совершенно другой аудитории.
Для любых клавиш мыши назначается любое действие. Это и так должно быть очевидно без примера.
могу похвалить что в одной точке стабильно зуммируется
стоило оно того, большой вопрос, задача тривиальная решается уже существующими програми
Открывай форточку.
>только под себя делаешь
>других вариантов не предусматриваешь
Я считаю, что в огромном "пространстве" возможных UX нужно выбрать тот, который нравится больше всего, и делать под него, с ограниченной конфигурабельностью для охвата его "окрестности", чтоб он был максимально удобен определенной группе, которой больше всего нравится этот UX или очень близкие. Вот для этой группы и делаю. Пытаться понравиться всем нет смысла. Но предполагаю, что данный сайт в какой-то степени "фильтрует" людей, которым может понравиться именно он, поэтому есть смысл показывать его здесь. Просто потому, что здешний встроенный почти такой же.
>посмотреть, что уже придумано в куче других таких же утилит, не обязательно этой конккретной
Я перепробовал много вьюверов, но не нашел такого, который бы можно было настроить вести себя 100% так, как я хочу.
>открываются на полный экран без всякого интерфейса и исчезают так же
У всех, что я видел, открываются либо в окне (и с ним надо возиться для произвольного размещения произвольной части картинки на дисплее), либо в полноэкранном с непрозрачным фоном не занятой картинкой области (мне это субъективно некомфортно, ощущение "разрыва контекстной непрерывности", что ли, плюс еще масштаб в фулскрине обычно для полного заполнения, мне предпочтительно, когда при зуме масштабы идут в дискретной геометрической последовательности, как карты, при этом включающей 1:1 и другие :2^n, и в начальном "прозрачном полноэкранном оверлее" начальный масштаб - "максимальный помещающийся" из этого ряда, а в фулскрине, который тугглится средней кнопкой или F - "полностью заполняющий" и с черным фоном, как и у большинства).
>решение с веб-страничек, которые не могут выйти за свои границы
Обычно страничке доступно 95% поверхности дисплея, и в браузерах давно есть фуллскрин апи. Полагаю, причина решения не в этом, а в "сохранении контекстной непрерывности". Начиная рассматривать картинку (которая занимает большую часть доступного пространства, но не все), юзер видит по краям страницу, и ментально "продолжает оставаться на странице" (если не решит включить фуллскрин).
>странно сначала показывать картинку в маленькой части экрана, а потом туда-сюда менять масштаб
Не в маленькой, но см. выше. Менять не странно. У меня часто бывает желание зазумить/запанить какую-то деталь или объект, чтоб она полностью заполнила определенную часть моего поля зрения, кажется, это называется "область наибольшей остроты зрения", под нее еще обычно рассчитывается правильное расстояние до дисплея на рабочем месте. Иногда картинка еще и хайрезная и это нужно, чтоб увидеть детали.
>возить туда-сюда колесом что-то странно
Мне - удобно. Судя по распространенности зума скроллом в том или ином виде - много кому удобно.
>при чтении манги
Твой юзкейс слишком специфичен, как и оптимальный для него CDisplay, который ты упомянул.
>Для любых клавиш мыши назначается любое действие. Это и так должно быть очевидно без примера.
Я вот пробовал "скриптуемые" вьюверы, в которых вроде бы максимальные возможности такого рода, и все же среди их "любых действий" обязательно не хватает чего-то, что работало бы 100% так, как нужно мне. Например, надежного зума в точку картинки под курсором почти нигде нет, даже если он вроде бы есть - обычно при этом не дает картинке частично выйти за границу области просмотра, пока есть место с другой стороны, сдвигая ее туда и сбивая точку.
При этом я считаю, что это UX достаточно хорош и одновременно прост, чтоб накодить специализированный вьювер, в котором он в основном захардкожен, с ограниченной конфигурабельностью и минимумом лишней "кастомизационной" логики для пользователей, которым нужен совсем другой, и которые этим все равно не будут пользоваться (см. начало ответа).
>>3683845
>на вейленде окно не может себя позиционировать, а иксоговно не нужно.
Не очень понял, зачем ты это упомянул. Он и не пытается позиционировать окно, он создает полноэкранное безрамочное прозрачное окно и позиционирует в нем прямоугольник картинки так, как нужно.
>стоило оно того, большой вопрос, задача тривиальная решается уже существующими програми
Любая отдельно взятая часть этого UX доступна в каких-то уже существующих вьюверах, по дефолту или с конфигом, а все вместе - нет. Во всяком случае, я не нашел.
>>3683637
>>3683788
Вообще как минимум для анимаций (возможно, в будущем и видео) стоит сделать всплывающее что-то, можно заодно и кнопки общих для изображений и видео функций
> Твой юзкейс слишком специфичен
Не поверишь, но фотосессии голых баб листаются точно так же, одной-двумя-тремя клавишами. Возить колесом ближе-дальше, как на картографических сервисах — совершенно лишняя работа, хватает простого перетаскивания картинки (если она в текущем режиме больше экрана).
> оптимальный для него CDisplay
Это давным-давно антиквариат без поддержки Unicode, его сегодня поставит только совсем поехавший. Упомянут он как прародитель принципа листания с минимальными затратами энергии, без лишних движений.
>хватает простого перетаскивания картинки (если она в текущем режиме больше экрана).
То есть, сначала зумить куда-то непонятно куда, а потом перетаскивать туда, куда надо. Ладно, каждому свое
>>3684208
>Это ты типа feh изобрёл?
Это ты типа прочёл "Без рамки окна, без меню, без тулбаров" и решил сразу написать коммент в духе "не нужно, уже есть"? Если ты знаешь, как заставить feh вести себя точь-в-точь так, как описано в оп посте - поделись конфигом, буду признателен (конечно, это не полное описание UX, но хотя бы эти пункты; подчеркну: прозрачный полноэкранный оверлей, в котором прямоугольник изображения позиционируется при зуме и пане - обязательно; зум в точку под курсором, не требующий перемещать курсор для зума, то есть позволяющий одновременно с зумом перетаскивать для пана - обязательно; прогрессия масштабов с 2^n - обязательно). Я пробовал фех и увидел следующее:
- что-то вроде зума в точку под курсором требует зажать среднюю кнопку и двигать мышь горизонтально (то есть зумить и панить одновременно нельзя, после зума курсор оказывается над другой точкой, а на тачпаде ноута это вообще не работает)
- лагучий пан, особенно в фуллскрине (похоже, у феха перерисовка программная, я через сдл загружаю картинку в текстуру, рендеринг с блитированием на гпу)
- в процессе зума рисуется целое число пикселей по ширине и высоте окна, из-за чего изображение некрасиво дергается
- при прерывании зума, если с какой-либо стороны есть свободное место, картинка сдвигается, чтоб занять его, сбивая точку под курсором
> То есть, сначала зумить куда-то непонятно куда, а потом перетаскивать туда, куда надо.
Я и пытаюсь объяснить, что произвольные масштабы «непонятно куда» в 99 процентах случаев не используются вообще. Можно изобрести робота, который будет клеить обои под любым заданным углом, но обычно всем нужно вертикально, так что только этим он и будет заниматься. Изображение смотришь либо целиком (и переключаешь на следующее), либо по ширине (чтобы двигать строго в одном направлении сверху вниз одной кнопкой), либо в 100% масштабе, если в первых двух вариантах оно выходит слишком мелким для имеющегося разрешения экрана (и только тогда перемещаешь окно вывода). Ещё кнопки поворота так же вслепую нажимаешь, если надо, для фоточек.