Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
Maemo Summit 2009
Speaker Rabbit
abbra
В субботу, 10 октября, на Maemo Summit мы с Jussi Rautio будем рассказывать об обработке многопиксельных изображений на Maemo. Точнее, что есть сейчас с камерой и обработкой изображений во Фремантле и что мы хотим сделать в Maemo 6. Комнатку нам дали самую маленькую (25 человек) и вообще это будет BoF, но лиха беда -- начало.

Если вдруг вы будете в это время в Амстердаме и вас не интересуют обзорные рассказы о Rygel, Mer и адаптации приложений GNOME, добро пожаловать в аудиторию 770.

http://wiki.maemo.org/Maemo_Summit_2009/Schedule
Tags: ,

  • 1
> добро пожаловать в аудиторию 770

Симптоматично :) А что будет в аудиториях 800, 810 и 900? :)

Они отсортированы по размерам и переименованы, потому что большинству произносить местные названия будет тяжело: http://www.youtube.com/watch?v=wSkAFGGv5nY
4 post-industrial spaces surrounded by culture, parks, canals and fun in WesterGasFabriek:

    * Transformatorhuis: keynotes & track 1.
    * Machinegebouw: track 2.
    * De Kapel: track 3
    * Oostelijk Meterhuis: special activities. 


Вот последний и есть 770: http://www.westergasfabriek.nl/english/engels_zalen_detail.php?detail=453

Кстати, об обработке изображений в Маемо - а есть уже программа ПРОСМОТРА графических файлов для maemo, которая их показывает, а не говорит "недостаточно памяти"?

Речь идет о просмотре стандартных листов топографической карты, отсканированных на 400-600 dpi.

Под OS 2007 с этим не справлялась не только встроенная программа просмотра, но и все перепробованные из имеющихся опенсурсных.

Пока нет, это мой план на Maemo 6. Извини, но во Фремантль я пришел уже фактически к готовому коду.

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

Нет такой, к сожалению.

Ну вот что их совсем нет - как-то не верится. 15-20 лет назад задача визуализации изображений, которые не лезут ОЗУ была еще как актуальна. Надо порыться по старым архивам свободного софта вроде sunsite.unc.edu, может что полезное и сохранилось.

Да я сам писал в 97 код, который на sparc IPC c 16 мегабайтами обрабатывал растры 15000x10000. Правда, тот код работал ни разу не со стандартными графическими форматами.

Печаль как раз в этом -- все современные свободные библиотеки вроде тех, что используют GNOME, KDE, Qt, GraphicsMagick, просто игнорируют необходимость работы с файлами очень большого разрешения. Памяти хватает. :(

А без костылей слабо? Ну без gtk под maemo тяжко. Какой идиот завязал экранную клавиатуру на такой высокий уровень, вместо того чтобы через XTEST события пихать. Но, насколько я знаю, то что менюшки и прочая мишура через gtk не мешает графику рисовать непосредственно средствами xlib.

Рисовать можно, без проблем. Даже с клавиатурой не так страшно, нужно выставить определенный атом в свойствах окна и события будут приходить.

То есть, написать панорамный вьюер для конкретного jpeg или там png -- не проблема. Хочется же, чтобы оно поддерживало все внятные форматы. В этом случае приходится либо самому писать эту абстракцию над libjpeg/libpng/..., либо пользоваться тем, что есть.

И вот тут проявляется мрачная действительность "памяти хватает". gdkpixbuf loaders со времен 770-й научились использовать сканирующий режим libjpeg, как раз тогда его в апстрим запихали. Но так и не научились в API прокидывать Region of Interest до загрузки изображения. После загрузки приложение получит сигнал с размером bounding box и даже может его изменить, gdkpixbuf отреагирует, но это будет уже после того, как 100Мпиксельное изображение засосано в память.

В Qt все ровно наоборот. В API QImageIOHandler присутствует возможность указать как ROI, так и то, что нам надо масштабировать читаемое изображение. Но совершенно отсутствует оптимизация масштабирования при чтении, например, jpeg, хотя бы на уровне DCT. То есть, всегда читаем сканлинию, распахиваем все символы и после этого делаем программную интерполяцию с потерей информации.

Хорошо, что оба этих популярных тулкита хотя бы поддерживают подсовывание потока из памяти, а не только из диска. То есть, по крайней мере без особых наворотов в Qt можно реализовать многопроходный панорамный вьюер без особых затрат -- в стиле "размер файла" + 3х3 размера экрана, то есть с достаточно предсказуемым поведением. В GDKPixbuf и такое сделать нельзя.

Qt на Maemo 5 будет -- он уже есть в extras-devel, народ даже собирается сделать так, чтобы темы и виджеты базовые совпадали с предоставляемым Hildon-стилем. Так что вполне реально такое написать на Qt без особой потери поддержки других форматов. Хотя, по-хорошему, надо дорабатывать все плагины поддержки этих форматов.

В этом случае приходится либо самому писать эту абстракцию над libjpeg/libpng/..., либо пользоваться тем, что есть.

А придется писать. Потому что то что есть - неработоспособно.
Не исключено, что отказываться надо не только от всяких gtk-шных поделий, но и от библиотек чтения форматов. Во всяком случае от некоторых. libjpeg - вроде вменяема, libtiff - неизбежное зло, уж больно формат развесистый.
А вот насчет libpng есть сомнения. Когда мне тут недавно потребовалось прописать в png-файл, сгенерированный libgd физическое разрешение, то оказалось проще написать встраивания чанка pHYs самому, чем разбираться в том, как это сделать через libpng.

Как правило форматы - проще, чем библиотеки, реализующие работу с ними.

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






Посмотри на QImageReader и QImageIOHandler в Qt 4.5, API там неплохое, реализация страдает.

С libpng у меня уже давно руки чешутся, от нее такой ужас исходит. Я не верю, что PNG должен так медленно обрабатываться и быть таким запутанным в использовании.

То есть, технически есть GEGL, который пытается представить буфера в виде коллекции плиточек (tiles), которые он хранит на диске в виде отдельных файлов или одного большого файла и в памяти, в виде отдельных подбуферов. Он умеет грузить jpeg и png в свои буфера, используя построчный интерфейс (сканлиниями).

Когда я попробовал создать простейший 100Mpix объект в GEGL и сохранить его в png (gegl -i bigrect.xml --output bigrect.png), он должен был бы занять около 380Мб памяти без всяких оптимизаций. Реально же было съедено на 100Мб больше.
<gegl>
    <rectangle width='10000' height='10000' color='red'/>
</gegl>


Процесс этот уже идет более 20 минут под Валгриндом на Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz с 3Гб ОЗУ.

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


Edited at 2009-09-27 02:54 pm (UTC)

ля вьюера все это не нужно.
Для вьюера нужно создать X-овый pixmap размером с экран (благо для этого памяти сейчас хватает. Вот под DOS в real mode приходилось в этом месте извращаться, потому что 1024x768 в память уже не лезло. Но у тебя и экран не 1024x768) и прямо в процессе чтения её заполнять. А при масштабировании/панорамировании - читать прямо из исходного файла еще раз.

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

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



Я собственно вот ровно такими методами и собираюсь все это делать. Это примитивный вариант, но даже он будет уже достаточен. Во Фремантль пропихнуть не удалось, бойцы испугались за полгода до релиза переписывать. Но в Харматтане у меня на это есть и время, и средства.

А чем примитивнее, тем надежнее. Альтшуллер говаривал, что идеальная система, это когда системы нет, а функция выполняется. Куда уж примитивнее.

  • 1
?

Log in

No account? Create an account