Вьюеры картинок

[vitus_wagner]

Почему-то среди широко известных опенсурсных программ нет программы, которая бы позволяла просматривать БОЛЬШИЕ картинки. Под "большой картинкой" здесь понимается растровое изображение таких размеров, что его неупакованное RGB-представление (обычно получается по 32 бита на пиксел, но достаточно и 24) не лезет в оперативную память.

То есть в resource-constrained environments вроде maemo "большой картинкой" будет уже лист А4, отсканированный на 600dpi. На десктопе с гигабайтом жизнь попроще. Но все равно есть вполне полезные вещи вроде graphviz, которые могут сгенерировать картинку, которая будет большой и для десктопа.

Задача, казалось бы элементарно простая - читаем картинку последовательно, пересчитываем координаты пикселов с учетом текущего размера окна, масштаба и выбранного viewport и заполняем offscreen pixmap размером с экран. На неё-то места хватит практически всегда. Это в DOS real mode на копию VESA-шного фреймбуфера в памяти места не хватало. И то вьюеры картинок под DOS писали и они работали.

Оказывается проблема в том, что у современного программиста даже не возникает мысль подойти к задаче системно. Вместо этого ищется готовый инструмент. На освоение которого уходит больше времени и сил, чем на написание вышеописанного простого алгоритма с нуля. Причем, желательно инструмент поуниверсальнее. Берем какой-нибудь GEGL и обнаруживаем что ему для загрузки картинки в свой tiled формат требуется больше места, чем у нас имеется в том, что на нашем девайсе заменяет жесткий диск.

Comments

[denisioru.livejournal.com]

Ну как сказать. Зависит от ниши софта. Обычный софт, типа ACDSee или похожие - крайне редко сталкивается с необходимостью просматривать такого размера картинки. Поэтому и подход просто - читаем всю картинку. Специализированный софт - типа просмотра аэрофотоснимков и т.д. - имеет у себя в качестве ключевых требований именно работу с большими картинками, посему подход к отображению и чтению картинки там другой. Опять же с компромиссом типа удобства. Универсальный инструмент будет маловостребован массовым потребителем, поэтому и нет такого.

[ivanaxe]

Повторяю вводную -- хотя бы скан листа карты А4 посмотреть на кпк.
Не самая специализированная задача.

[abbra]

Витус, напиши сам. :)

Я вот специально просмотрел все, что есть среди свободного софта. Картина -- ровно как я тебе и описал, и как ты ее сейчас в этом посте и перепечатал. Думать не хотят, фреймворки заруливают всех остальных, задач нет для использования реалистичных алгоритмов. В больших конторах скорее напрягут поправить UI, чтобы он был в соответствии со спецификацией, написанной UI-дизайнером, чем за такие вещи.

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

[vitus_wagner]

Вот у меня есть подозрение, что надо переписывать userland весь, начиная с coreutils.
Метод последовательных приближений, которым это добро развивалось с середины 80-х, себя исчерпал.

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

[potan.livejournal.com]

Вьюер - это программа, которая кроме просмотра картинок больше ни чего делать не умеет?

[vitus_wagner]

Хотя бы такую. Есть еще несколько операций, которые хотелось бы, чтобы эта программа умела делать, но это можно в конце концов потом дописать.

[blacklion.livejournal.com]

Проблема в том, что тебе придётся писать руками обработку десятка форматов. Из которых некоторые (JPEG, TIFF) весьма нетривиальны. Готовые же библиотеки такого функционала не дают.
Ты готов написать ещё одну реализацию TIFF со всей его тысячью тегов и двумя дестяками интерпритаций “сырых” битмап-данных в зависимости от набора флагов и тегов?

[vitus_wagner]

Готовые библиотеки такой функционал дают.
В libtiff, например, есть TIFFReadScanline, в libjpeg - соответственно
jpeg_read_scanlines.

Поэтому обработку форматов писать не придется. Разве что из соображений пооптимизировать. Например в случает jpeg уменьшении более чем в 8 раз можно очень хорошо пооптимизировать. cjpeg это умеет.

[vadiml.livejournal.com]

Я тоже на таком спотыкался, из-за этого ставил себе линукс версию xnview, которая давно не развивается, хотя автор давным-давно обещал виндовую версию переписать на Qt4 и потом портировать и портировать её на Mac и Линукс.

[san-sanych-r.livejournal.com]

aptitude show nip2 не это нужно?

[jek-hor.livejournal.com]

Да-да, когда я пытался рендерить карты в интересном мне разрешении из вектора, то либо конверторы, либо просмотрщики падали с воплями о нехватке памяти, а на самом деле им не хватало адресного пространства (!). А там всего-то картинки чуть больше, чем 20000х20000 были. Или даже не больше...

[amarao-san.livejournal.com]

аха. Я как-то сгенерировал картинку 20кХ10к. Потом был тест, что раньше упадёт. geeqie прорвалась и показала (ужрав весь своп). Браузеры молча не показали (все три штуки), остальные вьеры жрали память и не показывали.

оффтопик

[dil.livejournal.com]

товарищ маинтейнер ru_debian!
а нельзя ли там премодерацию ввести? а то спам достал.
вот свежий:
http://community.livejournal.com/ru_debian/185147.html
http://community.livejournal.com/ru_debian/185009.html

Re: оффтопик

[vitus_wagner]

Уже ввел.

[brazhe.livejournal.com]

А как же nip2 ?

[vitus_wagner]

А он - не вьюер. Поэтому тащит за собой по зависимостям хренову кучу библиотек. Для resource constrained environments это как-то некузяво.

[grundik.livejournal.com]

Ну это, если требований нет, то почему надо тратить своё (и тестерское) время на это? ;)
Фотошоп, например, картинку в 8 гигабайт на 2 Гб ОЗУ показывает хорошо. Но там в ТЗ было такое требование.

[vitus_wagner]

Мы ж вроде про open source. Во-первых, требования есть. Многие работают на слабых машинках. Во-вторых, просто сделать качественный и быстрый вьюер - в порядке самовыражения.

[captain-hell.livejournal.com]

у меня полтора гигабайта очень медленно открывается и работает.

[os80.livejournal.com]

А что из гуйных библиотек разрешается использовать?

[vitus_wagner]

Для десктопной версии - пофиг. Для простоты портирования на maemo лучше бы gtk.

[captain-hell.livejournal.com]

сильное, слабое. Такого софта вообще нет. Скан своей пленки в полтора гигабайта на моем ноутбуке открывается минуты. А сделать что-то с ним в фотошопе - сродни подвигу. Как сапер, ей богу.

[grundik.livejournal.com]

Странно. Когда у меня был древний комп (amd64 3200+, 2Gb RAM), то тормозить начинало с файлов размером в 3-4 гига, 8 гигов - ещё можно было работать (но комп становился однозадачным). Полтора гига вообще без проблем было обрабатывать (ну, если со слоями не баловаться сильно). Загружается - да, медленно, и потом тоже небыстро, но терпимо.

Скан поди в tiff?

Хотя может на буке винт медленный, это ведь влияет...

[ckotinko.livejournal.com]

дело в загрузчиках картинок. в том же maemo стоят гтковые загрузчики, а оне могут растянуть загрузку во времени, но не в пространстве. а иначе загрузчик придётся радостно писать ручками.

[vitus_wagner]

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

[yarikas.livejournal.com]

Чем-то знакомая задача (http://newsgroup.xnview.com/viewtopic.php?t=16479)...

[cgem.livejournal.com]

У вас какой-то бзик по поводу браузеров изображений. GEGL это библиотека для редактора изображений, а не для браузера изображений, чувствуете разницу?

[vitus_wagner]

Я-то чувствую разницу. А вот многие авторы опенсурсных вьюеров - не чувствуют.

[kh13.livejournal.com]

берем .png и ужасаемся тому, что "произвольную часть картинки" с диска так просто не вытащить.

[vitus_wagner]

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