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

[vitus_wagner]

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

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

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

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

Comments

[vitus_wagner]

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

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

[slobin.livejournal.com]

Если дают библиотеки, то, наверное, дают и командно-строчные интерфейсы к ним? ImageMagick какой-нибудь? Или она тоже сперва всё в память распаковывает? А если всё-таки дают, то почему искомый вьюер не может быть шелловским скриптом? Юникс вей у нас или что?

... Меня окружали милые симпатичные люди, медленно сжимая кольцо ...

[abbra]

Все они сначала в память распаковывают :)

[vitus_wagner]

Кир, ImageMagick это интерфейс к libmagick. Которая как раз и имеет идиотскую архитектуру с загрузкой всего в память.

[slobin.livejournal.com]

Ага. Вот с PIL всё нормально (я это ещё вчера начал подозревать, но только сейчас руки дошли проверить). PIL -- это Python Imaging Library. Там есть среди прочих метод draft, который намекает декодеру: когда будешь читать картинку, имеешь право загрубить её до вот такого разрешения и вот такой глубины цветности. И, скажем, thumbnail предварительно вызывает draft, а потом уже масштабирует до точных значений. На практике JPEG декодер загрубляет не больше чем в 8 раз (64 по площади и тем самым по памяти), и ещё втрое, если в серое. Метод реально определён только для JPEG и TIFF (что он делает с TIFF, я не проверял, но какой-то код там есть), но, поскольку там объекты, никто тебе не мешает переопределять его самому, если умеешь. То есть, искомый тобой вьюер -- не скрипт на шелле, а скрипт на питоне. ;-)

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

... И они хитрили, и Аллах хитрил, а Аллах - величайший из хитрецов! ...

[vitus_wagner]

Увы. нужный мне вьюер, это программа на C. Потому что сам написал, что возможности вырезать кусок, не храня то, что снаружи в PIL нет.
Ну или скрипт на python, tcl ли чем угодно, но с собственной C-шной библиотекой чтения картинки. Потому что задача "показать кусок большой картинки в масштабе 1:1 (т.е. пиксел картинки в пиксел экрана)" не менее важна, чем задача "показать всю большую картинку, уменьшив до размера экрана".