В субботу, 10 октября, на Maemo Summit мы с Jussi Rautio будем рассказывать об обработке многопиксельных изображений на Maemo. Точнее, что есть сейчас с камерой и обработкой изображений во Фремантле и что мы хотим сделать в Maemo 6. Комнатку нам дали самую маленькую (25 человек) и вообще это будет BoF, но лиха беда -- начало.
Если вдруг вы будете в это время в Амстердаме и вас не интересуют обзорные рассказы о Rygel, Mer и адаптации приложений GNOME, добро пожаловать в аудиторию 770.
http://wiki.maemo.org/Maemo_Summit_2009/Schedule
Симптоматично :) А что будет в аудиториях 800, 810 и 900? :)
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
Речь идет о просмотре стандартных листов топографической карты, отсканированных на 400-600 dpi.
Под OS 2007 с этим не справлялась не только встроенная программа просмотра, но и все перепробованные из имеющихся опенсурсных.
Да я сам писал в 97 код, который на sparc IPC c 16 мегабайтами обрабатывал растры 15000x10000. Правда, тот код работал ни разу не со стандартными графическими форматами.
То есть, написать панорамный вьюер для конкретного 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 без особой потери поддержки других форматов. Хотя, по-хорошему, надо дорабатывать все плагины поддержки этих форматов.
А придется писать. Потому что то что есть - неработоспособно.
Не исключено, что отказываться надо не только от всяких gtk-шных поделий, но и от библиотек чтения форматов. Во всяком случае от некоторых. libjpeg - вроде вменяема, libtiff - неизбежное зло, уж больно формат развесистый.
А вот насчет libpng есть сомнения. Когда мне тут недавно потребовалось прописать в png-файл, сгенерированный libgd физическое разрешение, то оказалось проще написать встраивания чанка pHYs самому, чем разбираться в том, как это сделать через libpng.
Как правило форматы - проще, чем библиотеки, реализующие работу с ними.
С библиотеками стоит связываться для записи, и то не всегда, как показывает вышеприведенный пример. А вот читать часто лучше без них, по спецификации формата. Это будет быстрее чем добиваться работоспособности от библиотеки, написанной программистами с уровнем квалификации заметно ниже твоего.
С libpng у меня уже давно руки чешутся, от нее такой ужас исходит. Я не верю, что 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, который вообще-то заточен под совсем другие задачи.