Проект по созданию программы для управления коллекцией фотографий digiKam (http://www.digikam.org/) отметил переход в фазу зрелости выходом (http://www.digikam.org/node/491) релиза 1.0.0. Для загрузки доступны как пригодные для сборки в большинстве Linux дистрибутивов исходные тексты (http://sourceforge.net/projects/digikam/files), так и сборки для MacOS X и Windows.
По сравнению с digiKam 0.10 в новой версии можно отметить следующие улучшения:- Исправлено 485 ошибок;
- Добавлен мастер первоначальной настройки (First Run Assistant (http://www.digikam.org/node/442)), после первого запуска digiKam задает несколько наводящих вопросов на основе которых формируются базовые настройки, оптимизированные для конкретного пользователя;
- Добавлен (http://www.digikam.org/node/427) менеджер очередей автоматизированного выполнения заданий, позволяющий осуществить такие типовые операции, как преобразование форматов, устранение эффекта красных глаз и изменение размера для группы...
URL: http://www.digikam.org/node/491
Новость: http://www.opennet.me/opennews/art.shtml?num=24764
> Для кэширования эскизов фотографий вместо ~./thumbnails теперь используется новая БД, эскизы при этом сохраняются в формате PGFОн что, лучше чем JPEG 60% жмёт?
JPEG 60% давно стал жать без потерь?
Так нафига превьюшки размером 100 на 150 жать без потерь?
What is PGF?* A new image file format
* Based on discrete, fast wavelet transform with progressive coding features
* Lossless and lossy compression
* Best for natural and aerial images
* For such images with a better compression efficiency than JPEG
* PGF is one of the best algorithms available these days for compression of natural imagesЗачем жать чем то ещё, если этот - better и the best? :-)
Затем, что он better только на natural and aerial images. Другими словами, на ровных заливках или градиентах он проигрывает gif и jpeg, и выигрывает на изображениях с большим количеством мелких деталей.
Брат аноним, мне стыдно за тебя.
http://en.wikipedia.org/wiki/Progressive_Graphics_File
В двух словах. Да, лучше. Но это не та фича, ради которой вся затея. Основная фича - не нужно хранить тумбы как отдельные файлы!
Это не фича, это баян 5-летний http://tech.inhelsinki.nl/dbfs/
$ eix dbfs
No matches found.Кому нужен боян, если его никто не использует?
$ uname -a |grep -i gentooКто сказал, что то, чего нет в портежах никем не используется?
>$ uname -a |grep -i gentoo
>
>Кто сказал, что то, чего нет в портежах никем не используется?Опровергните. В официальных репах основных дистрибутивов не нашел.
>>$ uname -a |grep -i gentoo
>>
>>Кто сказал, что то, чего нет в портежах никем не используется?
>
>Опровергните. В официальных репах основных дистрибутивов не нашел.http://www.opennet.me/openforum/vsluhforumID3/62271.html#34
просто не то ищете
>$ eix dbfs
>No matches found.
>
>Кому нужен боян, если его никто не использует?Дык, батенька, dbfs это не файловая система и не пакет, это разновидность хранения метаданных файлов, даже не так это идея, концепт, ... и каждый её реализует по своему.
Вот ешё http://ritmark.com/ritmark/
eix ritmarkfs
No matches found.Все же склоняюсь, что данная концепция мне не нужна.
>eix ritmarkfs
>No matches found.
>
>Все же склоняюсь, что данная концепция мне не нужна.emerge moo - вот что тебе пойдёт;
>Основная фича - не нужно хранить тумбы как отдельные файлы!Они изобрели thumbs.db? :-) IMHO так вообще тумбы не надо хранить (согласен, спорное утверждение, но меня вполне устраивает скорость генерации на лету (не в digiKam - эту прогу не смотрел ещё) + моя "коллекция" очень диамична - не знаю как он будет отслеживать постоянное перемещение, добавление, удаление, переиманование, редактироание).
Лучший фотоальбом.
если бы не тянуло за собой кеды
<flame>
Зато mono не тянет
</flame>
юмор оценил.но лучше бы оно запускалось в дотнете, который хотя бы установлен практически у всех.
а ещё лучше - отвязать от kde
> но лучше бы оно запускалось в дотнете, который хотя бы установлен практически у всех.speak for yourself
speak russian на русскоязычном ресурсе.
дотнет идет в поставке, начиная с nt5.1. сейчас та или иная версия этой среды инсталлирована почти на 100% персональных машин.
>speak russian на русскоязычном ресурсе.
>дотнет идет в поставке, начиная с nt5.1. сейчас та или иная версия
>этой среды инсталлирована почти на 100% персональных машин.а причем тут nt5.1 и выше на ресурсе о свободном ПО и юникс системам?
и какой из фреймворков идет установленный по умолчанию?
а остальные?
Что? У меня под Windows XP его нету. А вот Java, например, установлена. И у многих знакомых так же.
Вот под линухом у меня Mono стоит, лол. Потому что много программ появилось, которые ее используют. Парадокс, казалось бы. Под виндами я вообще не знаю хоть сколько-нибудь полезных мне десктопных программ, которым бы нужен был этот дотнет.
Это чего "много"? F-Spot, Beagle, Banshee, Tomboy, Moonlight, и... Всё?
Человек, видимо, хочет сказать, что Ubuntu - это законодатель мод, это самый нириальнопоцанскей дистрибутив, у кого не Убунту тот козёл, Моно стоит у фсех, а у кото не стоит тот не модный. А KDE аццтой, он в Убунте по-дефолту не стоит... Как бы сторонники KDE ни убеждали, что 4-я версия всё-таки хорошая - люди не сговариваясь уходят на Gnome как на запасной вариант... Или остаются с 3-ми. И подобные комментарии тому свидетельство.
>speak russian на русскоязычном ресурсе.
>дотнет идет в поставке, начиная с nt5.1. сейчас та или иная версия
>этой среды инсталлирована почти на 100% персональных машин.А при чем тут венды?
Ну у емня допустим mono вообще не установлен. И не нужен он мне
>но лучше бы оно запускалось в дотнете, который хотя бы установлен практически
>у всех.Восхитительно. Аноним нас всех посчитал.
Хорошо что в кедах
Интересно когда до них дойдет, что во время обработки фотографии фильтрами не стоит блокировать кнопки масштабирования, при этом автоматически выбирать масштаб от балды. Да и фильтр для удаления эффекта красных глаз как был идиотским так и остался.
Классно! Судя по всему, DigiKam догнала версию 0.9.0 по возможностям! Уже ставлю! А вообще у меня стоит 2 DigiKam, старый и новый. Сравню - отпишусь.
Использовал день - впечатления хорошие. Отшлифован. Функционал не весь (видимо, новый API KDE не освоил ещё никто), но почти весь. Зато новые функции появляются. Хотелось бы поддержку RAW, хотя бы через интеграцию с другими KDE-шными утилитами. Хотя, их ещё не портировали в 4-ю версию до сих пор.
Ещё, применительно, именно, к коллекции, мне видится интересной такая идея - вытянуть все графические файлы с заданной точки ФС, свалить их в одну служебную директорию, стереть все имена и заменить id-ами какими-нибудь, и всю работу с коллекцией осуществлять через такого типа программу-оболочку, организуя файлы исключительно по тегам и характеристикам. Есть где-нибудь такое?
>Ещё, применительно, именно, к коллекции, мне видится интересной такая идея - вытянуть
>все графические файлы с заданной точки ФС, свалить их в одну
>служебную директорию, стереть все имена и заменить id-ами какими-нибудь, и всю
>работу с коллекцией осуществлять через такого типа программу-оболочку, организуя файлы исключительно
>по тегам и характеристикам. Есть где-нибудь такое?Это MacOS-way, ищите под неё.
>>Ещё, применительно, именно, к коллекции, мне видится интересной такая идея - вытянуть
>>все графические файлы с заданной точки ФС, свалить их в одну
>>служебную директорию, стереть все имена и заменить id-ами какими-нибудь, и всю
>>работу с коллекцией осуществлять через такого типа программу-оболочку, организуя файлы исключительно
>>по тегам и характеристикам. Есть где-нибудь такое?
>
>Это MacOS-way, ищите под неё.Но хочется-то под Linux и Windows :-) Не буду же я ради этого ставить макось.
Если организуешь исключительно по тегам и характеристикам, то:
Не будешь же каждый раз сканировать все файлы на предмет какие где теги, а будешь держать кэш в какой нибудь базе.
Раз работаешь только через программу-оболочку, то она же при изменении тегов, будет обновлять как файл так и кэш, либо только кэш.А тогда какая разница где и как файлы лежат?
Тем более у большинства файловых систем есть ограничения на количество файлов в директории.
>Если организуешь исключительно по тегам и характеристикам, то:
> Не будешь же каждый раз сканировать все
>файлы на предмет какие где теги, а будешь держать кэш в
>какой нибудь базе.
> Раз работаешь только через программу-оболочку, то она
>же при изменении тегов, будет обновлять как файл так и кэш,
>либо только кэш.
>
>А тогда какая разница где и как файлы лежат?Не знаю, кошерность какая-то :-) Порядок. Думаю многие меня поймут, может даже Вы догадываетесь о чём я (да не в обиду будет сказано, я это строго в прямом смысле).
Сейчас у меня на одном из винчей такой лес, что сам чёрт гойлову сломит. Сливались годами папки (и архивы, кстати, и многотомники, и даже, где-то, исошки с клипартами) одна в другую, с именами и содержанием самого разного характера как только может быть. Стереть жалко, очень много там было красивых "обоев", клипартов, фоток с фотоаппарата мегатонны, да и баб голых, подруг детства :-) - ностальгия:-), в глубине гдето, помнится. А разгребать это вручную совершенно нереально - это как небольшой город по кирпичикам разобрать и собрать снова. В последнее время всерьёз занялся упорядычиванием нажитого, наведением порядка, вот пригодилось бы. Я задумывался на тему что то, о существовании конкретно чего в своих завалах я не знаю и чем не пользуюсь - как бы и не нужно, и можно всё удалить, но не поднимается рука как-то, особенно при нынешних объёмах хардов.
> Тем более у большинства файловых систем есть ограничения на количество файлов в директории.
А у болльшинства софта (как кто-то недавно подметил - это ограничения самих прог, а не ФС) есть ограничения на максимальную длинну полного имени, об которое я со своими завалами постоянно долбаюсь (больше это, правда, касается коллекции книг всяких и статей, а не картинок). А при натыкании на ограничения на количество файлов в директории можно на несколько разбить, не так уж страшно.
>Не знаю, кошерность какая-то :-) Порядок. Думаю многие меня поймут, может даже
>Вы догадываетесь о чём я (да не в обиду будет сказано,
>я это строго в прямом смысле).Понимаю, только не понимаю зачем все в одну директорию?
Меня на ext3 постоянно мучила директория .thumbnails/normal/ скапливались превьюшки и все начинало тормозить. На ext4 стало побыстрее, но и то начинает притормаживать когда слишком много. Сейчас там 58103 на ext4 вроде не заметно тормозов, а на ext3 уже лагало все ну просто безобразно при просмотре картинок.Чем же подход digikam или f-spot принципиально не устраивает? Теги есть поиск по ним есть, расставлять умеют, только не хранят все в одной директории. F-Spot создает при импорте по своему разумению, digikam использует существующую структуру директорий.
А что насчет сортировки файлопомойки, так ежели тегов не было, кто их кроме тебя расставит?
Все равно придется все просмотреть и проставить теги. В чем профит, от того что сначала закидаешь все в одну директорию? И из нескольких маленьких кучек отсортированных худо бедно по директориям, создашь одну большую кучу.Вот если бы digikam научился бы расставлять теги автоматом, различал бы типы фоток, портреты в одну кучу, пейзажи в другую, лица знакомых людей научился бы распознавать, порнуху от эротики отличать :D
Вот это было бы супер.
> Вот если бы digikam научился бы расставлять теги автоматом, различал бы типы фоток,
> портреты в одну кучу, пейзажи в другую, лица знакомых людей научился бы распознавать,
> порнуху от эротики отличать :D
> Вот это было бы супер.-- just4fun mode on --
Вот это зацени: http://www.digikam.org/drupal/node/321Так что рисуй пока скетчи для разных типов картинок: сиськи там, попки, ушастые лица, елочки, и т.п., а фича подоспеет (если еще не реализовали) ;-)
-- just for fun mode off --
я думаю что то вроде nepomuk вам помогло бы
>я думаю что то вроде nepomuk вам помогло быВ принципе очень может быть, в идеале я же хочу не только графику, а вообще всё так организовать через теги и семантичнские связи. Я уже сам собирался это разрабатывать. Но Nepomuk вроде как слишком навороченый и фронтенд только для KDE :-(
А она может искать дубликаты?
>А она может искать дубликаты?В rc6 такая фича есть, но не тестил.