» Scan Tailor

Scan Tailor

Скриншот:

В разработке находится новая альтернатива СканКромсатору. Разработчик - ваш покорный слуга.
Задача программы - пост-обработка сырых сканов с целью их последующей сборки в PDF или DJVU.

Уже есть на что посмотреть, и возможно присоединиться к проекту. Проект с открытыми исходниками и кросс-платформенный (Windows + Linux).

По сравнению со СканКромсатором планируется большее удобство использования, большая интерактивность, но при этом не меньшая автоматизация процесса.

Сайт проекта: http://scantailor.sf.net Скриншоты

Топик программы на форуме Натахаус Англоязычный топик по ScanTailor

---

Документация

Документация (Wiki) Зоны картинок в ScanTailor

Статья: Scan Tailor. Программа для обработки отсканированных книг

Видеоурок: Создание DjVu с помощью Scan Tailor (зеркало)

Методика использования STA совместно с Djvu Imager

---

Дистрибутивы

Версия СТ с функцией выпрямления искривленных строк (dewarp от Rob)

Патч от anagnost96 Вариант ScanTailor с этим патчем (STA) Зеркало

ScanTailor для Mac

Последние изменения в дереве исходников - для сильно любопытных и владеющих английским.
Там же можно подписаться на rss/atom - для нетерпеливых.

---

Дополнительно

ST GreyText v1.0 Программа для генерации вывода как бы "Только текст (в режиме серого)" - для Scan Tailor от anagnost96.

LayerTailor Программа для разделения сканов (после "Смешанный режим) на foreground и background слои с целью последующего раздельного кодирования в djvu. Принцип работы: Все черные пиксели (яркость==0) переносятся в foreground, остальное - в background. Функция layer принимает на входе 3 параметра: исходное имя файла TIFF, имя файла для foreground и имя файла background. Автор: U235.

Предложения к anagnost96 по поводу улучшения его модификации СТ
Сравнение выпрямления искривленных строк в СТ и в BR

---

Статья О возможности альтернативы СканКромсатору Полезные ссылки по теме топика
ArtScan - ещё одна программа для сканобработки.

Tulon
Желаю Вам успехов в этом крайне полезном начинании!

Добавлено:
Я написал трём мне известным программистам, которые ранее проявляли интерес к этой тематике. Может быть, хоть кто-то откликнется.

Tulon
У меня явно дежавю Года два назад видел opensource программу с подобным набором функций и дизайном - особенно хорошо запомнилось, как выглядит функция Deskew (этакая окружность с перекрестьем).
Вы продолжаете какой-то проект, или это просто совпадение? Или у меня действительно крыша едет?

Нет, я разрабатываю его с нуля. Может вы его видели не пару лет а пару месяцев назад? Примерно тогда я и выпустил первую публичную версию.

Tulon

Цитата:

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

А назывался он тогда так же?

Запустил Batch Processing, но в папку Out так ничего и не поступило (есть только папка Cache c thumbnail'ами). Что я делаю не так?

Назывался всегда так.

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

да, интересное начинание, между прочим. А будет пакетное выполнение, т.е. без GUI? Тогда получится альтернатива и кромсатору, и конвейеру сразу. Большое спасибо!

было бы идеально ещё приделать сюда вызов minidjvu или другие свободные djvu-кодировщики как внешние программы. Впрочем это конечно необязательно - можно потом скрипт запускать с вызовом внешних программ. Однако проблема с minidjvu в том, что там не очень доделана оболочка, запускать неудобно. Зато можно линковать minidjvu как библиотеку. Но это так, мысли вслух.

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

Что касается встроенного экспорта в djvu, то пока я такого не планирую. Разве с экспортом есть какие-то проблемы? От программы экспорта и удобств-то особых не нужно. Указание набора файлов, выставление параметров, и сам экспорт.

Tulon
Можно ИМХО попробовать поискать программистов по работе с растровой графикой на форуме CuneiForm: http://openocr.org/forum/

Tulon
Ещё ИМХО есть смысл Вам создать топик на форуме http://www.djvu.org/forum/phpbb/viewforum.php?f=1 и там рассказать о своей программе.

Также возьмите программу DjView с http://djvu.sourceforge.net/djview4.html - она тоже написана на Qt и имеет открытые исходники - т.е. не исключено, что там может найтись что-то полезное.

Запостил анонс на Planet DJVU. На форумы CuneiForm и djview4 решил не писать - все-таки не совсем та аудитория. Если и найдуться еще программисты, то они будут скорее всего из тех, кто сам сканирует книги, или хотя-бы пытался это делать. С CuneiForm кстати та же проблема - код выпустили, а привлечь сторонних программистов не смогли. Впрочем там есть свои заморочки, которых нет в моем проекте.

Может кто знает англоязычные форумы по тематеке книго-сканирования?

Tulon

Цитата:

и djview4 решил не писать

Я имел в виду - возьмите исходники этой программы - т.к. они, во-первых, написаны на Qt, а во-вторых, эта программа - в сущности по работе с растровой графикой - т.е. эти исходники могут пригодиться.

Добавлено:

Цитата:

Может кто знает англоязычные форумы по тематеке книго-сканирования?

Насколько я знаю, там этим не занимаются - в смысле, силами единичных энтузиастов. Это видно хотя бы из того факта, что на Западе о формате DjVu почти не знают. Просто у них иная психология - с точки зрения рядового западника сканирование книги и публикация её в Интернете - есть преступление. А с точки зрения постсоветского человека - это хорошо и правильно. (Это ИМХО главная причина популярности DjVu в Рунете и т.п.).

ИМХО имеет смысл искать на Западе просто Open-Source программы по работе с растровой графикой и программы из смежных областей (Pattern Recognition, Computer Vision, Artificial Intelligence). Можно поискать по запросу "image processing library" и т.п.

Кстати, в топике http://forum.ru-board.com/topic.cgi?forum=93&topic=1102&glp можно найти DjVu-скан-книги по этим тематикам. Например, с _http://lib.homelinux.org/ можно скачать порядка 600-700 МБ DjVu-книг по этой тематике - возьмите всё отсюда:

_http://lib.homelinux.org/_djvu/_catalog/index_19.html

и тут немало интересного: _http://lib.homelinux.org/_djvu/_catalog/index_10.html

Например, интересен 5-томник Graphic Gems - он есть там полностью. К нему имеются все исходные коды (из всех 5 томов) - вот тут: http://www.graphicsgems.org/

Есть там и 2-3 книжки с алгоритмами и исходниками на Си.

Большинство этих книг были отсканированы либо лично bolega, либо по его просьбе - в целях развития СканКромсатора.

Этих книг там до полусотни - и они представляют значительный интерес в плане теории по этим вопросам.

Ещё можно поискать в Рунете материалы по Pattern Recognition, Computer Vision, Artificial Intelligence - этого добра просто валом ИМХО.

Добавлено:
Посмотрите ещё раз раздел http://www.djvu-soft.narod.ru/bookscanlib/ на моём сайте - там есть всякие полезные ссылки по этой тематике.

Добавлено:
Ещё у bolega есть в ассортименте статьи в формате Pdf с сайта IEEE.org и т.п. (материалы конференций по AI и PR, и просто новости науки в этих областях) - но, вроде бы, для него проблема их выложить (некуда и нет времени и т.п.)

Да, материала много, мне надолго хватит
Впрочем, большая часть материала расчитана на математиков, а не на программистов, а с математикой у меня как раз туго. Универ я бросил еще на первом курсе, и ни разу не жалел об этом, пока за этот проект не взялся.

Впрочем, на данном этапе проблема вовсе не в алгоритмах. Проблема в том, что я один, а работы много. Что касается использования существующего кода, то это практически никогда невозможно. Даже если я нашел где-то реализацию нужного мне алгоритма, то он наверняка работает со своими собственными структурами данных. Эта проблема весьма характерна для C/C++. Стандартные библиотеки там очень бедны, так что каждый изобретает свой собственный набор колес.
Изначально я хотел использовать код leptonica (leptonlib). Но выяснилось, что он паршиво написан. О потоковой безопасности авторы похоже не слышали, проблемы переносимости, и т.д.

Кстати вот еще одна либа, которая не указана на сайте monday2000: http://opencvlibrary.sourceforge.net/
Это библиотека компьютерного зрения от Intel. Похоже заброшена, но там много вкусностей, в том числе таких, которых я больше нигде не встречал.

Tulon
Вот мне ещё Илья Межиров (автор minidjvu) прислал письмо:

Цитата:

Спасибо за ссылку. Интересный проект, но у меня нету времени на это.
Могу, впрочем, сказать, чем наш ocropus может пригодиться. Во-первых, у него все-таки не настолько сумасшедшие структуры данных. Недавно от ocropus'а откололся отдельный проект очередной CV-библиотеки - iulib (вопросы типа "на фига козе баян" не ко мне). Потом - что у нас есть... ну deskew какой-никакой. Еще, надеюсь, выложим Page Frame Detection - если в скан попали ошметки соседней страницы, PFD их вырежет. Все это под лицензией Apache, которая совместима с GPL3 ScanTailor'а, так что интересующиеся товарищи могут в нашем коде ковыряться.

Приятно, что minidjvu еще кто-то помнит

А кстати, CuneiForm живет и побеждает - Юсси Пакканен недавно CuneiForm for Linux выпустил, правда, сырую еще.

Всего хорошего!
Илья

(Илья сейчас занимается разработкой ocropus).

Tulon

Цитата:

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

ИМХО это зависит от уровня сложности. Не так уж редко вполне возможно "перебить" нужный алгоритм под свою программу. А структуры данных можно подменить на свои.

Цитата:

Изначально я хотел использовать код leptonica (leptonlib). Но выяснилось, что он паршиво написан.

А мне понравилось. Ведь это же учебный проект, о чём его автор специально написал там. То есть да, оптимальность кода там зачастую невысока - зато очень наглядна работа того или иного алгоритма. А оптимизировать можно самому попробовать.

Кстати, один рубордовец тоже применил leptonlib для аналогичной программы - см. http://akakii.net/post.html . Вот только программой он не захотел поделиться.

Для тестирования (сканы в djvu)
http://www.mediafire.com/?jxmnmxyxns2
Select content сработал не очень хорошо

Добавлено:
monday2000

Цитата:

зато очень наглядна работа того или иного алгоритма

Да, при ковырянии в чужих исходниках это главное

Цитата:

Для тестирования (сканы в djvu)
http://www.mediafire.com/?jxmnmxyxns2
Select content сработал не очень хорошо

С бинарным мусором Select Content действительно плохо справляется. А в вашем примере есть действительно тяжелые случаи, а именно мусор в виде dithering'а и кольца от переплета.
Впрочем я бы не отказался получить пару советов по вычищению мусора от мэтра

Что касается leptonlib - да, она написана в обучающих целях, и поэтому они не стремились к production quality. А жаль. Использовав ее, можно было бы много времени съэкономить.

Tulon

Цитата:

Использовав ее, можно было бы много времени съэкономить.

На мой взгляд, задавшись желанием сделать альтернативу СканКромсатору, не обязательно сразу пытаться сделать эту самую альтернативу "как можно быстрей".

Мне представляется, что сначала следует сделать хотя бы качественный вьювер (просмотрщик) графических файлов популярных форматов (TIF, BMP, ...). Я вот так и не встретил до сих пор ни одной такой программы, которая была бы написана на C++, имела бы полностью открытые исходники, свободную лицензию, была бы пристойного качества и не использовала бы GDI+. Есть лишь множество коммерческих программ такого рода. Или же, в лучшем случае, для Delphi какие-то жалкие крохи - вроде вот этого: http://melander.dk/delphi/resampler . К сожалению, эта тематика вообще крайне неразвита ИМХО у программистов.

Я думаю, что не грех потратить 1-2 года на то, чтобы сделать подобный вьювер (это дело явно не быстрое) - а задачу создания альтернативы СК отложить на будущее - до тех времён, когда подобный вьювер будет готов. Можно назвать его по-другому - "графический движок".

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

У СканКромсатора 5.6А очень пристойный графический движок (не говоря уже о СК 5.91, где применяется MMX). Надо суметь (для начала) хотя бы повторить его (графический движок). Я думаю, что даже будь у СК открытые исходники, это (практически) не помогло бы Вам создать тот вьювер, о котором я говорю - разница в языках довольно ощутима. (СканКромсатор написан на Delphi с применением коммерческой платной графической библиотеки ImageLib Delphi Corporate Suite v.6 http://skylinetools.com/imagelib/index.html - эта библиотека нашлась и у меня на покупном диске с Delphi-компонентами - только у меня она с пиратским серийником, который вводится при инсталляции библиотеки).

Создать хороший графический движок - как бы не сложнее, чем создать всё остальное, относящееся к понятию "альтернатива СК". Этот вьювер нам всем нужен как воздух - ибо на его базе прочие добровольцы могли бы создать десяток иных программ, нужных для книгосканирования. Это позволило бы в перспективе освободиться почти полностью от вареза в нашем деле. Ведь такой движок позволил бы реализовать и просмотр DjVu-файлов - разница с точки зрения программиста невелика - надо лишь прикрутить исходники DjVuLibre. А потребность в программном просмотре файлов формата Bmp, Tif, DjVu, Gif, Jpg и т.п. есть в каждой второй самодельной книгосканировочной программе - если не в первой.

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

А чем вам не нравится тот вьювер, который уже реализован в СТ? Я надо сказать весьма удивлен тем, что вы приводите в пример СК. Не уверен, что пробовал версию 5.91, но в предыдущих версиях все было весьма печально в плане отображения и интерактивного манипулирования изображениями. По моему в СТ все значительно лучше в этом аспекте.

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

Tulon

Цитата:

А чем вам не нравится тот вьювер, который уже реализован в СТ?

Навскидку:
1. Нет сглаживающего фильтра (или его действие практически незаметно).
2. Нет скроллбаров при увеличенном изображении.

Цитата:

1. Нет сглаживающего фильтра (или его действие практически незаметно).

Он есть, но специально отключается при большом зуме. В Linux он всегда отключен по соображениям производительности.


Цитата:

2. Нет скроллбаров при увеличенном изображении.

Не вижу необходимости. Драг с помощью мыши по моему удобнее.

Tulon

Цитата:

Он есть, но специально отключается при большом зуме. В Linux он всегда отключен по соображениям производительности.

Это несерьёзно ИМХО. Даже на большом зуме (т.е. на просто большом, а на сверхбольшом зуме действительно можно и без фильтра обойтись) сглаженное и несглаженное изображение - это небо и земля. Но у Вас и на малом зуме его нет. Или же он откровенно плох и потому незаметен. Вот когда только открываешь программу - картинка сразу отображается в масштабе Fit Width/Fit Height . Так вот - впечатление таково, что фильтр всё же есть - но это (на вид) низкокачественный (хоть и наиболее быстрый) Nearest Neighbor (который мягко говоря, никому не нужен).

Цитата:

Не вижу необходимости. Драг с помощью мыши по моему удобнее.

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

Вот из таких мелочей всё и складывается. Потому что это никакие не мелочи - а принципиальнейшие вопросы. И без их реализации говорить просто не о чем.

Поэтому я и говорю - что пока что не видел качественного и свободного C++-вьювера - и не жалко потратить до 1-2 года на его создание - т.к. это принципиальнейший вопрос. И пока такой вьювер не появится - идти дальше в создании альтернативы СК - довольно-таки практически-бессмысленное занятие (представляющее лишь теоретический интерес).

Сейчас специально запускал винду в виртуальной машине, чтобы проверить, есть ли там антианиазинг. Все нормально - есть. Что касается большого зума, то там замыленное изображение выглядит весьма и весьма паршиво, и к тому-же не позволяет в полной мере рассмотреть детали, например не наехал ли content box на край буквы. Насколько я помню, в СК он тоже на больших зумах отключается, там еще пиксельная решетка появляется при этом. И в Gimp кстати тоже отключается. Насчет Photoshop сказать не могу - не юзаю.


Цитата:

Тем не менее - я не припомню ни одной коммерческой программы, где был бы "драг мышью". Почему-то везде скроллбары.

Ох уж эти пользователи. Не нравится им фича только потому, что в других программах не так. Вот вам аргумент в пользу драга по сравнению со сколбарами: драгом достигается большая точность. Это в некоторых случаях важно, например если делаете deskew в ручном режиме и пытаетесь совместить край букв с контрольной горизонтальной линией.

Tulon

Цитата:

Насколько я помню, в СК он тоже на больших зумах отключается

Точно я не знаю - но скорее всего нет, сглаживающий фильтр не отключается самопроизвольно в СК при достижении сверхбольших зумов. Это визуально видно совершенно чётко. Сглаживающий фильтр можно вручную отключить в СК.

Цитата:

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

Да, есть такое. Но зато при ручной очистке от грязи, например, сглаживающий фильтр незаменим. Да и ещё наберётся несколько таких случаев важных, когда без него не обойтись.

Цитата:

Что касается большого зума, то там замыленное изображение выглядит весьма и весьма паршиво

Кому не надо - пусть отключают фильтр. Но что делать тем, кому он (фильтр) нужен?

Цитата:

Вот вам аргумент в пользу драга по сравнению со сколбарами: драгом достигается большая точность.

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

Цитата:

Ох уж эти пользователи. Не нравится им фича только потому, что в других программах не так.

Ничего не поделаешь. ИМХО хорошая сканобрабатывающая программа должна вписываться в достаточно жёсткие рамки - иначе она будет просто никому не нужна. Я себе представляю такую программу как СканКромсатор, лишённый известных недостатков, ну и Open-Source - Free License, конечно.

Добавлено:
У Файнридера хороший сглаживающий фильтр - и сглаживание приемлемое, и скорость перемасштабирования высокая.

Можно конечно понаделать опций, но во-первых это сильно усложнит код, а во вторых рискуем получить второй Кромсатор, где опций столько, что без мануала в них никак не разобраться. А мануалы будут читать только энтузиасты. Человек, который просто захотел оцифровать одну книгу, наверняка не будет читать мануал. Обилие опций его просто отпугнет. В общем я за максимум удобства при минимуме опций.

А уж если речь заходит о том, как лучше реализовать фичу, то в качестве аргументов я бы предпочел видеть конкретные use-cases, то есть "я пытаюсь сделать вот это, и оно сейчас не удобно, а вот так было бы удобно". Например по вопросу scrollbars vs drag, вы даже не сказали, зачем вам вообще понадобилось увеличение картинки.

Tulon

Цитата:

По моему в СТ все значительно лучше в этом аспекте.

Ну еще бы. Отключите в СК сглаживающий фильтр, плюс дополнительно работайте с 150dpi-изображением (как в СТ), СК будет летать быстрее, чем СТ. К тому же движок в СК поддерживает 2-й слой (для отображения зон), а также векторные примитивы (любой формы), включая и изображение поверх изображения. Для векторных объектов поддержка всех полагающихся фич: перемещение, изменение размера, закраска, прозрачность, редактирование вершин. Возможно, в движке Qt это все есть, но как это работает в условиях нормального сглаживания (а не того простенького и корявого, как сейчас), мы еще не знаем. Кроме того, при теперешнем качестве отображения в СТ (невысоком) очень трудно судить о качестве скана (и тем более ч/б резултате обработки), трудно также понять насколько скан заспеклен. Т.е. смотря на изображение в режиме fit невозможно понять, нужна ли ему какая-то пост-обработка или другой фильтр. Для этого потребуется увеличивать масштаб, но смотреть все сканы в зуме по всей площади - это слишком утомительно и практически нереально.
На мой взгляд, фильтр должен быть максимально близким к тому, что применяется в djvu-viewer или pdf, ведь именно там потом придется читать результат. И кажется Вы путаете сглаживающий zoom-фильтр и антиалиасинг-фильтр, это разные вещи

Цитата:

Ну еще бы. Отключите в СК сглаживающий фильтр, плюс дополнительно работайте с 150dpi-изображением (как в СТ)

Насчет 150 dpi вы ошибаетесь. Картинки обрабатываются действительно в основном в этом разрешении, но отображаются в исходном.

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

Что касается качества антиалиазинга, то что есть - то есть. Не буду же я в самом деле переписывать движок отображения Qt. Возможно одна из причин плохого качества антиалиазинга (хотя меня все очень даже устраивает) заключается в том, что я отображаю трансформированную на лету картинку. То есть я передаю вместе с картинкой матрицу афинного преобразования. По другому никак - подумайте как тормозил бы ручной deskew если бы я при каждом чихе вращал бы изображение в памяти и делал бы качественный антиалиазинг. Тормозил бы он наверное так же, как тормозит наклон резака в СК.

Tulon

Цитата:

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

Согласен. Тогда по-умолчанию следует сделать глаживающий фильтр всегда включённым. А где-нибудь на вкладке Advanced Options предусмотреть отключение сглаживающего фильтра. Потому что в 90% случаев пользователю захочется присутствия хорошего сглаживающего фильтра. Отключать его потребуется весьма редко - когда нужна попиксельная точность при Copy-Paste и когда большие тормоза с цветными сканами.

Цитата:

Например по вопросу scrollbars vs drag, вы даже не сказали, зачем вам вообще понадобилось увеличение картинки.

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

Приходилось ли Вам самому делать электронные DjVu-книги? Если нет, то попробуйте хоть 1-2 сделать (СканКромсатором) - многое сразу же станет ясно в плане как развивать СТ.

Цитата:

Не буду же я в самом деле переписывать движок отображения Qt.

Не исключено, что нечто в этом духе всё же потребуется. Увы, требования к СК-подобной программе довольно велики.

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

Пожалуй стоит отложить на потом вопросы с антиалиазингом и скроллбарами. Вот когда в СТ реально можно будет работать, тогда и вернемся к ним. Может реально поработав в СТ вам и расхочется иметь скролбары


Цитата:

Приходилось ли Вам самому делать электронные DjVu-книги? Если нет, то попробуйте хоть 1-2 сделать (СканКромсатором) - многое сразу же станет ясно в плане как развивать СТ.

Пытался. В результате чего и начал делать СТ. И мне в принципе ясно, куда его надо развивать. Развивать надо в сторону максимальной автоматизации процесса, а так же в сторону максимального визуального feedback'а.


Цитата:

Цитата:
Не буду же я в самом деле переписывать движок отображения Qt.

Не исключено, что нечто в этом духе всё же потребуется. Увы, требования к СК-подобной программе довольно велики.

Вы еще предложите снести и перестроить заново здание, из-за того, что оно оказалось не идеально прямоугольным

Цитата:

Я написал трём мне известным программистам, которые ранее проявляли интерес к этой тематике. Может быть, хоть кто-то откликнется.

Tulon
Ответили все трое. Из них интерес проявили двое. Я дал им Ваше мыло на sf.net.

Добавлено:
Я на днях попробовал поискать в Интернете какой-нибудь приличный вьювер графических файлов с открытыми исходниками под Windows. К сожалению, ничего путёвого найти не удалось. В лучшем случае только низкокачественные вьюверы, от которых толку ноль.

Добавлено:
http://en.wikipedia.org/wiki/List_of_open_source_software_packages#Image_viewers