Pull to refresh

Comments 42

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

Спасибо за вопрос. Общая лента - это все фото\видео в хронологическом порядке, вот например, как выглядит у меня. Скрины можно найти отдельно в "Поиск" => "Документы" => "Скриншоты" и в чистилке тоже есть это да.

какие функции для вас важны для хранения\управления личной фото-видео-коллекцией?

1) ЛОКАЛЬНОЕ хранение, которое не зависит от платных провайдеров.
2) Не база данных, а дерево каталогов.
3) Поиск по образцовой картинке («найти большое по превью») при помощи свободного ПО.
4) Поиск по лицу («найти такие же лица») при помощи свободного ПО.

Первые два легко сделать. Третье и четвёртое пока никто не сделал.

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

Я, например, раз пять "терял" базу при переездах между дисками и дистрибутивами :)

@PereslavlFoto В Shotwell 0.29.3+ (вновь) заявляют распознавание и детекцию лиц, но что-то они лет пять уже это "заявляют". Всё не соберусь поставить бету и попробовать, если "взлетит" на Intel - там OpenCV определенной версии надо...

Гранд спасибо! А если резервную копию БД с синхронизацией хранить в облаке?

Это традиционный вопрос хранения бэкапов. Хоть где-то хранить надо обязательно.

Там другой нюанс:

  • сменили диск/ОС/ - слетели привязки по путям. Не все программы могут "подхватить" файловую структуру на новом месте и привязать её к БД

  • сменили версию программы - старая база перестала читаться, а старой версии софте - не предусмотрено :)

  • но есть и плюс у БД - гораздо быстрее искать/фильтровать по параметрам (у меня это как дата, так и до десятка тегов на особо хитрые фото)

Резюмируя - хранить в осмысленном дереве по датам/событиям/пленкам/и т.п. Теги писать в файлы (непосредственно или .xmp рядом). Использовать софт, читающий это дело в БД, позволяющий искать по тегам и записывать их обратно. Делать бэкапы БД/превью хоть куда - облако, другой диск, ...

А если сломались пути, можно ли их актуализировать, если в качестве идентификатора использовать совокупность данных - точный размер в битах, дату и время создания, хэш от картинки?

Ну, упомянутый shotwell это умеет.

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

Что будет, если были изменены тэги "извне" не скажу, но мелькало где-то, что сравнивается только содержимое картинки.

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

Например, BlackBaze или даже напрямую в IPFS через web3.storage

Дерево каталогов намного проще --> быстрее --> удобнее.

Все операции с файлом все базы данных можно сделать БЕЗ помощи СУБД.

А вот с файлом ВНУТРИ базы данных ничего нельзя сделать без помощи СУБД, что заставляет не работать с файлом изображения, а работать с СУБД, тем самым задача становится намного сложнее.

А если в файлы отдельно а БД отдельно и БД хранится путь к файлу и небольшое превью?

Тогда БД получает много недостатков:

1) быстрая, в течение одного дня, рассинхронизация с файлами, потому что запуск БД будет один раз в полгода, а изменения в файлах будут ежедневно,

2) замусоривание жёсткого диска этими превью,

3) распухание БД за счёт ненужных сведений, сохранённых в ней, потому что все сведения в ней ненужные.

А как посчитать примерный вес БД, на 10 000 объектов? Допустим, превью 250*250 пикселей.

Прям опять про shotwell :)

Базу хранит с тегами и тех. инфой, превью хранит отдельными файлами 180х180 и 360х360 (хз, можно ли отключить часть). Остальное "как есть" в файлах. Теги умеет вписывать в файлы, по-умолчанию - отключено.

Из того, что сейчас под рукой:

  • 18050 фото и 46 видео на 186Гб

  • 4 копии БД по 10-12Мб

  • 2.1Гб превьюшек

1) быстрая, в течение одного дня, рассинхронизация с файлами, потому что запуск БД будет один раз в полгода, а изменения в файлах будут ежедневно
Не будет, если эту БД ведет сама программа просмотра картинок, через которую их и редактируем. Так сделано в XnViewMP, например.
Да, конечно остается вариант, что мы покопались в файлах другим файловым менеджером, но часто ли в этом необходимость?
Для просмотра используются самые разные программы. Для редактирования описаний используется редактор exif, который один раз и навсегда добавляет описание внутрь файла. Для редактирования изображения используются самые разные программы.

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

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

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

Вот поэтому и приходится собирать пакет из многих программ.

У меня как-то полетела ФС на диске, и медиатека Aperture совершенно разломалась при восстановлении данных.


Каталоги с фотками, с другой стороны, сохранились. Метаданные в фотках сохранились. В итоге спаслись только оригиналы фото, вся работа, сделанная в Aperture, пропала.


К слову об Aperture… Когда завязываешься на спец. программу и её проприетарные стандарты, становится очень больно, когда программу закрывают.


С веб-сервисами аналогично (и ещё хуже). Та же Google закрыла Panoramio и Picasa Web, им не привыкать

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

Спасибо! Полностью согласен, до сих пор нахожусь в поиске идеальной конфигурации.

Ваша реплика очень чётко содержит в себе условия, при которых она верна.

Да, именно так. ЕСЛИ можно купить оборудование, ЕСЛИ можно заработать деньги, тогда локальное хранение опасно.

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

Если же расходы не нулевые, а платить нечем, тогда решение с ненулевыми расходами — это невозможное решение.
PereslavlFoto, к сожалению, бесплатных хороших вещей не бывает, придется или смириться с рисками или платить.

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

Огромное спасибо, постараюсь с разработчиками разобраться, что из этого можно сделать.

Digikam умеет это все.

По слухам photoprism тоже умеет.

Короче в век обмана и войн не стоит доверять айти гигантам. Надо иметь свой маленький сервер дома (арм одноплатники стоят копейки и не шумяи) + бекап всего этого

Правильно ли я понял, что Digikam умеет поиск по лицу? То есть даёшь ему фотографию размером 350 × 400 точек и получаешь ответ, где ещё встречается это лицо?

Как-то так, да. Насколько я помню, он даже персон, обнаруженных на фото, может тэгами зашить обратно в файлы, так чтобы поиск условных фотографий где есть "Павел Михайлович" и "Елена Степановна" станет возможным по тэгам и вне Digikam, лишь бы это позволял другой просмотрщик.

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

2) бэкап на внешний хард/диск/пленку с возможностью посмотреть в программе где оно лежит. По хорошему - оставлять на девайсах только минимальные превью, а фотки большого качества хранить на внешнем харде, например.

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

4) поиск по лицам, карте, распознавание образов (сложные фильтры не очень нужны, типа первый ребенок на даче но не зимой и с домом на фоне - не критично)

5) поиск похожих - очень часто мы с женой фоткаем одно и потом надо сидеть и сначала сливать фотки в одном месте, а потом выбирать лишние с двух девайсов

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

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

What can I say. You need to buy an ARM single board computer ($50) so it can run silently all the time eating just few Watts of power. Put some big SD into it and/or attach an external HDD/SSD. On your phone(s) you can use an app called SyncFolder, it's free but with ads, which is not shown in Russia anyways. I'm guessing there might be open source alternatives, I was too lazy to search for them. But there're plenty of similar options. Then you configure Tor on your ARM SBC (to bypass the NAT) or use any kind of tunnels, like from Cloudflare to expose your 22 SSH port from Linux to outer world. That's it. Your phones will be always in sync and on that device you'll have a full backup of all your photos. This is how I've done it - https://orange-pi-4-lts.blogspot.com/2022/08/how-to-sync-your-photos-from-android.html

У меня каталоги, на локальном диске, плюс копия на съемный(USB) плюс копия в облако(майл, был получен 1тб давно и неправда), плюс гугл фото(со смартфонов, сейчас это пиксель первый куплен специально для бесплатной безлимитной закачки новых фото, просто закидываю их на него и он отпрвляет куда следует).

плюс копия в сетевом хранилище(редко, иногда).

По поводу лиц и прочего, припоминаю что гугл фото начинался с такой штуки как Picasa. Делал там такое, потом понял что в общем то это не нужно(лично мне).

свежие комменты к Picasa
свежие комменты к Picasa

Еще ACDSee, можно его попробовать.

Еще ACDSee, можно его попробовать.
Бесплатная и кросс платформенная XnViewMP мой выбор уже лет 15, если не больше.
Скажите пожалуйста, она действительно занимает меньше места, чем acdsee 2 версии?
Сколько занимает acdsee 2 не знаю, много лет ей не пользовался.
Портабельная Linux версия (может не последняя, но свежая) XnViewMP занимает 200 Мб, без учета базы превью.

So where are the updates? You promised us to post every week :)

Sign up to leave a comment.

Articles