oculante — просмотрщик изображений с аппаратным ускорением

А что там ускорять-то?

Терминалы с ускорением тебя не удивляют?

Удивляют, конечно

Сходил по тегу, вот такой запрос увидел

Просмотрщик изображений без пропуска кадров

Сравнил с loupe, loupe стартует почти две секунды, а эта штука – мгновенно.

Ну, текстура с билинейной фильтрацией натянутая на два треугольника всяко быстрее чем ту же фильтрацию на процессоре долбить

Как надо долбиться в глаза, чтобы для просмотра фото использовать билинейную интерполяцию?

Треугольники - это прошлый век. Рейтрейсинг Вычислительные шейдеры изобразят любую интерполяцию без ненужных world-, view-матриц.

Если не рассматривать шизоидные юзкейсы типа того, что привёл выше greenman, то есть два возражения:

• Я не уверен, что для отрисовки одного прямоугольника это будет быстрее, быстрее это будет, когда таких прямоугольников миллионы

• У кого-то возникала проблема с тем, что фоточка не отрисовывается слишком быстро?

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

А что там ускорять-то?

Скорее всего редактирование:

SIMD-accelerated image editing

Программку не видел, но если там есть плавное увеличение и прокрутка - то либо два треугольника с текстурой, либо онанизм.

У кого-то возникала проблема с тем, что фоточка не отрисовывается слишком быстро

Вообще да, если это какие-то мега-панорамы (хоть с сайта Nasa), или ты зажимаешь стрелку и пытаешься посмотреть серию фото как можно быстрее.

PS: на маке, родное приложение Фото, так же использует видеоядро для вывода, а не процессор - посмотрел только что. И как раз можно зажать стрелку и быстро быстро смотреть всё.

Raw image data can be sent to Oculante and will be loaded if possible, regardless of format. Streams of images will be played as a video. You can send images from cameras or headless systems such as a Raspberry Pi for example.

Вот это настоящая киллер-фича, я джва года искал приложение, которое так умеет.

UI, конечно, уровня «автор должен мне новые глаза», но хоть что-то

А шо там ускорять?

В просмотрщике более 90% вычислительной мощности тратится на декодирование файла.

Ответ выше

А в цветовую калибровку умеет?

Возможно это может быть полезно, если фотографий очень много и они очень большого размера, моя сонька отдает равы по 40мб весом, в более новых моделях (какие-нибудь A7IV используя пиксельшифт могут делать фотографии чуть ли не по пол гига), если там просмотр будет быстрее то нужно

хотя что-то мне подсказывает, что все равно все будет упираться в io накопителя, сколько раз пробовал листать фотки с флешки напрямую - там всегда лютые тормоза.

Сравни с этим Simple Viewer GL v3.1.0 — просмотрщик изображений

Это не то. Гуй из разряда feh мне не очень хочется.

Я про скорость запуска

Upd. Есть ещё viewnior, он с гуем

А что там ускорять-то?

Добиваться моментального вывода фотографий >20 MP и их быстрейшего переключения.

Ускорять Zoom

Ускорять переключение фотографий

И т. д.

более 90% вычислительной мощности тратится на декодирование файла.

И так случайно совпало, что у многих пользователей в системе есть аппаратные декодеры JPEG.

Есть базовое неразрушающее редактирование: обрезка, изменение размера, раскрашивание, контрастность, HSV, поворот, размытие, шум и т. д.

А переключение изображений колесом мыши есть?

https://github.com/woelper/oculante/pull/303

В недавно вышедшей версии 0.8.22 (2024-05-19) этого в настройках не вижу.

базовое неразрушающее редактирование

Это на каком языке вообще?

Плюс немного рисование.

Не UNIX-way = ненужно

Всё приложение — один бинарный файл

33.3 MB под просмоторщик картинок? ненужно2

rust

ненужно3. Все народ, закапывайте.

33мб в 2024 году это просто пыль, как бы это не звучало

Проект переехал на GitHub: https://github.com/andreyugolnik/simple-viewer-gl

Вот такие как ты и клепают hello world по 200 MB.

При чем тут я? Сейчас половина софта на электроне и подобном написана, 33мб это еще по божески выходит, рыночек порешал, не я

Не понравился.

33.3 MB под просмоторщик картинок? ненужно2

Этак штука мало того что имеет размер 30+МБ, так еще и:

1. поддерживает только захардкоженный перечень форматов файлов
2. при этом еще и имеет внешние зависимости:

$ ldd /usr/bin/oculante
	linux-vdso.so.1 (0x00007a98f82a6000)
	libturbojpeg.so.0 => /usr/lib/libturbojpeg.so.0 (0x00007a98f8198000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007a98f5c00000)
	libheif.so.1 => /usr/lib/libheif.so.1 (0x00007a98f80de000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007a98f5fd3000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007a98f5ee8000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007a98f5a14000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007a98f82a8000)
	libx265.so.199 => /usr/lib/libx265.so.199 (0x00007a98f4600000)
	libde265.so.0 => /usr/lib/libde265.so.0 (0x00007a98f5991000)
	libaom.so.3 => /usr/lib/libaom.so.3 (0x00007a98f3c00000)
	libsharpyuv.so.0 => /usr/lib/libsharpyuv.so.0 (0x00007a98f5edd000)
	libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007a98f4508000)

И так случайно совпало, что у многих пользователей в системе есть аппаратные декодеры JPEG.

Так случайно совпало, что сабж просто вызывает libjpeg-turbo и всё:

        #[cfg(feature = "turbo")]
        "jpg" | "jpeg" => {
            let jpeg_data = std::fs::read(img_location)?;
            let buf: RgbImage = turbojpeg::decompress_image(&jpeg_data)?;
            let d = DynamicImage::ImageRgb8(buf);

            _ = sender.send(Frame::new_still(d.to_rgba8()));
            return Ok(receiver);
        }

А еще так случайно совпало, что прямо в README написано:

• Image loading time is still worse than feh or xv This is now very close, in particular after switching to turbojpeg

Кагжетаг.