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

[vitus_wagner]

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

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

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

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

Comments

[abbra]

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

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

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

[vitus_wagner]

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

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

[andrzejn]

Живо вспоминается "зрелая среда программирования" в описании В.Винджа.

[abbra]

Вопрос чисто экономический -- найди проект, где это переписывание будет экономически выгодно и дело в шляпе.

[deztructor.livejournal.com]

У меня когда-то в одной конторе (2000 год) был такой проект: смысл его - оцифровка всей бумажной документации различными путями, основные клиенты - конторы с большим запасом чертежей форматов A1 и больше. Использовал замечательный activex компонент (image gear, если помню правильно), который как раз быстро и качественно с минимальным использованием памяти загружал, масштабировал, двигал картинку в окне просмотра (очень шустро). Вот тут-то это и будет экономически выгодно.

[vitus_wagner]

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

Но где ж найти сейчас того, кто готов вкладываться в среднесрочные проекты.

[abbra]

Именно, нигде их и не найти. Всем нужно краткосрочное решение.

[vitus_wagner]

Значит надо искать за пределами софтверного бизнеса. И, возможно, за пределами бизнеса вообще.