Try   HackMD

camera materials

частина диджиталізації

folder = папка = тека.
library = бібліотека – теж служить контейнером, тому його вжито у темі для простішого сприняття.

🎓 резервне копіювання (backup)

якщо файл в єдиному екземплярі, то вважайте, що його немає взагалі

  • Програмий метод, спеціальним ПЗ, версіонально по мірі змін даних.
    наприклад:

    https://www.duplicati.com/
    https://kopia.io

  • Використання спеціальної файлової системи носіїв. Таке сховище вимагає значних ресурсів, багато носіїв та RAM. Сучасний метод для багатьох клієнтів, а затратний для одного, тому підійде не для кожного дому.
    • ZFS автоматично забезпечує зеркалювання даних, а від адміністратора вимагається лише вчасно заміняти несправні носії
  • Синхронізація як дублікат. Якщо користуватись синхронізованою папкою хмари на іншому носії, тоді дублікація виступає частковою копією. Частковою, тому що програмне забезпечення може інорувати приховані, без розширень, налаштовані вийнятики, несумісними назвами або модифікувати їх, не дублює права. Синхронізація може мати негативний ефект при помилкових діях користувачем та шкідливих ПЗ, із вирішенням допоможе завчасне керування функцією версіювання даних. Але всеодно знадобиться холодна копія на випадок значних змін як атаки віруса-шифровальника. Такий метод не варто вважати "правильним" бекапом, синхронізатори не всі дані дублюють, проте доступний орендою потужностей.
    • Метод: MEGA. Синхронізатор (клієнт) – чудовий, папки налаштовуюються.
    • Метод: Syncthing. Опція синхронізації - одностороння:
      [завдання синхронізації] - [лише відправлення], у іншого пристрою [лише отримання] відповідно по сторонам. Це щоб не синхронізувати небажані зміни, зроблені іншою стороною.
  • Холодний бекап це один з методів резервного копіювання, тривале зберігання даних на випадок втрати даних в результаті зовнішніх факторів, а не очікуваного поламання носіїв. Збрегання носія відключеним від живлення фізично, окремо від основного сховища, віддалено географічно, з метою захисту від стихій, нещасних випадків, збою електроживлення пристрою що спалює всі під'єднані пристрої, а також юридичного захисту (законами іншої країни). Періодично його вмикають для актуалізації даних, поновлення бекапів, звісно можна автомачично, синхронізацією. Користування даними із цього сховища – недопустимо, бо проти суті методу. Сховище повинно мати справний носій.
    • MicroSD - крихітний носій, що легко ховати.
    • HDD протеснований віком відпрацювання 3міс~1роки.
    • Старий (>3роки) носій не варто використовувати для холодних копій, адже навіть він сам не оприділяє чи досі здатний прочитати дані, доки не буде проведено повна діагностика, результат якої швидко стає неактуальним при відпрацьованому носії.

🗃️ зберігання медіа, фото менеджер, сховище

сховище даних, організація, бібліотека, RAW, цифровий матеріал (для фото, відео, анімації та ін.)

Цифровий “матеріал” як знімок не обмежується фотографією, бо являється ресурсом подальшої творчості для: іншого фото, відео, анімації та ін. Він потребує певної дисципліни зберігання.

  • 🔂 підсумки
    • Дані легше зберігати у єдиному місці, для належного керування (ніяких часткових копій, зроблені вручну на флешки, бо для цього є відповідне ПЗ та кращі сховища).
    • Запускання тимчасової сесії Linux Live режиму забезпечує базовим ПЗ та обслуговування, напр. для діагностики, веб-серфінгу, користування даними. Корисно підготуватись на випадок аварії ОС чи обладнання, проте на сучасних комп'ютерах обмеженням зовнішнього втручання може бути налаштований TPM із шифруванням даних.
    • Windows OS використовує файлову систему NTFS, а EXT4 не підтримує.
    • Linux дистрибутив використовує файлову систему EXT4, а також NTFS підтримка за домогою додаткового пакету, із втратою продуктивності.
    • зйомка в одному сховищі, для сім'ї мережеве сховище і продуктивний роутер. Ніяких флешок!
    • для нового сортування такий порядок: готувати нове мережеве сховище або локальне, бібліотекою добавити старі і нову папку (сховище), бібліотекою сортувати в нову. Провідники лише для перевірки і видалення старих каталогів!
    • збереження по роках, лишні матеріали у внутрішні папки [source]
    • в камерах синхронізувати час, особливо для Timelapse
    • зберігати якомога кращою якістю, з RAW бо з'явиться підтримка кращих форматів
    • при імпорті:
      • перейменування універсальне
      • конвертація RAW CR2 у DNG
      • конвертація JPG у WEBP, або в майбутньому JPG в AVIF
      • вставити Copyright
    • зберігати оригінальність знімків:
      • в налаштуваннях бібліотеки ввімкнути редагування метаданих у зовнішні META (XMP sidecar files)
      • права для медіа - файли у каталозі право читання, без модифікації, а для каталога право запис файлів.
  • бібліотека та програми
    • для перегляду фотографій є програми з базою даних (журнали) які забезпечують зручний пошук з різних сховищ за допомогою метаданих і тегів. Вони зберігаються у базі програми, всередині фото або документах з назвою фото. Аналогічно редактори зберігають службову інформацію правок без змін оригінала а для готової фотографії потрібний експорт. Управління фото включає: видалення зображень (крім папок), перенесення, групування, перейменування, теги, перегляд кешу без наявного доступу носія та ін…
    • специфічні програми для фотографій (як digiKam) показують лише певні дані, пам'ятати що у старих папках можуть залишитись:
      • різні права і власники
      • приховані дані від роботи інших програм.
        Стара програма Picasa при редагуванні переносила зображення у приховану папку [.picasaoriginals]. Щоб з них не втратити файли - краще перейменувати, враховуючи що не всі провідники шукають папки з крапкою.
    • провідник (менеджер файлів) - універсальний засіб і не підходить для управління медіа. З провідника не рекомендовано переміщати і змінювати медіа
  • збереження - якомога якісніших матеріалів
    • бо підтримка переходить на користь нових, кращих форматів
    • для створення нового, майбутного типу творчості. Для прикладу:
      • 3D здохло ледве появившись, потребувало спеціальної камери, спеціального екрану, хорошого зору
      • короткі зациклені відео (ранше "gif") прижились у мессенджерах
      • "оживлені" портрети згенеровані нейромережою з одного зображення
      • ймовірно, нейромережою можна зробити анімацію без ручного монтажу, із декількох схожих зображень
      • зйомка пленоптичними камерами, покищо ненабули поширення, дорогі
    • якість матеріалів залежить від багатьох параметрів
      • більше пікселів (як цифрова площа) - краще, оцінка чисельності пікселів недостатня, бо змінились способи їх використання та переключаються в залежності режиму зйомки.
        • сенсори з технологією об'єднання групи "ловлять" багато відтінків, заміть розподілу RGB кольору.
          Напр. [1 піксель]/[16 відтінків], замість [1 піксель]/[1 колір RGB], відповідно у 16 разів більше "рекламних" пікселів
      • менший рівень зжимання з втратами (lossy) чи без втрат (lossless)
      • кодування, бітність, частота кадрів, [колірна субдискретизація]
      • збереження RAW
  • захист оригінальних матеріалів - легше збереження, бекап, робота, обмін. При частих змінах оригінали дають колосальну економію ресурсів (обчислювальних, енергії, мережевого трафіку, часу). Оригінали заблокувати, а зміни зберігати зовнішніми МЕТА. Кожного разу змінивши теги, відмітки, дати - залишиться синхронізувати лише XMP файли малого розміру, замість терабайтів медіа.
    • легший бекап
    • легший обмін/публікації (Sharing), користь значно зростає децентралізованим інтернетом та p2p обміном по хеш-функції (як IPFS, замість адресації даних), які виступають потенційною веб-копією (у пристроях чи користувачах)
    • для інших баз даних, Nextcloud - стороння зміна фалів приводить до неатуальності бази, втрати функцій: публікації, коментарів, генерованих прев'ю
    • фізичний поворот псує зображення, нормальні програми просто редагують мітку положення в META
    • оригінальні файли до публікації повинні містити як мінімум:
    • після імпорту варто захистити матеріали від перезапису (права файлу - лише читання)
    • ключова дилема щодо підтримки оригінальності файлів - вибір зміни метаданих (META)
  • метадані (Metadata, META).
    • зберігаються у:
      (1) файл зйомки (META матеріалу),
      (2) зовнішні файли (XMP) - sidecar files
      (3) база бібліотеки, у програмі
    • (1) у файл матеріалу програми змінюють МЕТА, тим самим модифікують його. Додатково оновлюють [дату зміни] для візуального інформування внесених змін, в деяких програмах можна відключити, але не рекомендується
    • (2) зовнішні файли META (XMP) - програма використовує зовнішній текстовий файл назвою матеріалу. Програми можуть дублювати чи поновлювати META лише у sidecar при заблокованому матеріалі (права лише читання). XMP файли поширений формат тож частково усуває проблеми збереження оригінальності матеріалів і сумісності програм (записи внесених змін).
      • не плутайте з налаштуваннями [sidecar JPG+RAW]
      • digiKam: налаштування по замовчуванню не читає зовнішні XMP і навіть опис зображення
    • (3) у базу - максимальна швидкість операцій, мінімальна сумісність. Читання/запис метаданих зображення змінює файл і сповільнює роботу. У налаштуваннях бібліотеки бажано включати лише при першому імпорті для максимального доповнення бази, або синхронізувати при потребі. Для користування за межами програми (покиданні бази, публікаціях) перевіряти куди збереглися зміни META чи здійснити операцію запису,
    • META містить чимало технічної інформації для ідентифікації, програми зазвичай відображають лише базову інформацію. В цілях безпеки, для публікацій бажано експортувати нові файли добавляючи перевірені поля META (без: персональних тегів, даних лиць, геопозиції, серійних номерів та ін.)
    • обережно, при видаленні META полей [дата зйомки] та параметрі META [оновлювати дату модифікації у файлі] – дати не відповідатимуть дійсній даті зйомки, що далі псує сортування | digiKam | 220414
      • з модифікацією створюється новий файл (згідно параметру-?) з датами цієї операції, тобто початковою датою стає [дата створення файлу]
  • сховище
    • Пристій зазвичай оперує даними адресно, тобто за його вказаним розміщенням, а не вмістом даних (як IPFS), тому потрібно ознайомимтись з кількома особливостями користування.
    • Важливо використовувати одинакові директорії та адреси, щоб легше було заміняти носії, не втрачаючи дані баз даних. Більшість софту залежні від адресації контенту і не підтримують символічні посилання (Symbolic link) чи вимкнено для безпеки.
    • Збірка лінків від сховища корисна для бібліотеки (імпорту в базу даних).
      При підміні лінка, база залишиться незмінною, незалежно від фізичного розміщення інформації: інший розділ, носій, пристрій чи планета..
    • Для сховища обмежити права користувачів, надати дозвіл ПЗ що оперує базою даних. Це особливо важливо на єдиному пристрої, що працює хостом та клієнтом одночасно, інакше користувач та інше ПЗ скористається доступом свідомо чи ні, зробить небажані зміни даних.
    • Якщо не дотриматись користування базою, після зовнішніх змін даних у сховищі що не відстежуються базою, сторонніми засобами (програмами, провідником) втрачається зв'язок з базою для роботи функцій, метадані бази і XMP. Можна повторно сканувати базу, але для неї це як нові дані.
    • З віддаленим мережевим сховищем користуватись через WebDav або синхронізовану папку. Примонтований WebDav чи Samba (SMB) схожі на звичайну папку, як носій. При цьому важливо дотримуватись сховища навіть на єдиному пристрої, що працює хостом та клієнтом одночасно.
    • Свої медіа зберігати разом.

      Зберігання для користування не плутати із резервними копіями (бекап).

    • див. додатково про сховище у темі [selfhosted] /налаштування
    • сховище бібліотеки digiKam, рекомендація.
      • розміщення бази, напр.:
        /mnt/data/userPhotographer/digikam_database/
      • розміщення збірки посилань для бібліотеки програми, посилання на папки того ж пристрою. Назви посилань (псевдо-папки) робити зрозумілими для перегляду альбомів, згідно подальших рекомендацій. Напр.:
        /mnt/data/userPhotographer/digikam_library/
      • digiKam (Linux) - підтримує лінки
  • перегляд папок. В програмі потрібне зручне ввімкнення перегляду вмісту внутрішніх папок, дерева каталогів включаючи зображення без папок. Це допоможе розділяти перегляд JPG+RAW від внутрішньої папки [source]. Наявність функції важлива для комфорту і вибору способу сортування
    • digiKam: View - Include Album Sub-Tree
    • якась програма не підтримує, не пам'ятаю
  • сортування (каталоги) сховища, розподіл, способи
    • v1. [сортування спільне сховище] - фото із матеріалами (JPG+(RAW всередині каталогу)).
      Особливості: спільний носій, RAW заважає публікації, провідником легка навігація, програмою перегляд по даті або каталозі, але знадобиться управління перегляду внутрішніх папок. Спосіб для малої бібліотеки і кількості глядачів (при публікації обмежує продуктивну спроможность хостингу)

      • моє сортування специфічне, досі не слідує більшості правил, по суті не для публікації: папки разом з RAW, не видалені метадані перед публікацією (що нерекомендовано в плані безпеки), не пройшли обробку і багато залишаються невідібраними, деякі матеріали схожі для різних цілей і залишені не підписаними.

      • нище у темі описані приклади, в більшості на базі першого способу, але можна пристовувати до другого
    • v2. [сортування частини сховища] - на іншому носії матеріали RAW.
      Особливості користування: у програмі дві бібліотеки, перегляд по даті, вибираючи фільтр перегляду (тип файлу або текстом). Спосіб для великих бібліотек і масовому шарінгу, сховище=(SSD lossy)+(HDD lossless)
    • v3. [сортування частини сховища], презентаційний (варіант являється аналогом другого але складний). Матерали (1/2) lossy для публікації. Матеріали (2/2) RAW на іншому носії. Напр.:
      (1/2) Lossy (JPG, AVIF) - приготовлений фінальний результат, експортовані для спеціальної публікації (без лишніх метаданих, необхідного формату і якості, тобто яким повинен бути публічний результат).
      (2/2) RAW окремо, приватні.
      • зверніть увагу, веб-сервер для перегляду може показувати полегшені прев'ю (меншої якості) що спотворює враження перегляду
  • [CAMERA] - назва кореневого каталогу для збереження зйомки, підходить для всіх камер і типів файлів (mp4, jpg, RAW). З таких каталогів (розміщених локально чи мережевих сховищ) робити лінки щоб добавити у бібліотеку. Кореневий каталог завжди робиться для файлів зйомки, на різних носіях, очевидно щоб розуміти суть вмісту, не зберігати в ньому лишнього, недопускати лишні програми виставляючи необхідні права доступу
    • v1 [спільне сховище]
      • /home/USER/CAMERA/ - [USER] користувач Linux, CAMERA каталог по призначенню
      • /home/USER/Pictures/ - погано, стандартний каталог
      • /mnt/data/ - зовнішній носій, примонтований у точку /mnt/data/
      • /mnt/data/USER_or_Photographer/CAMERA/ - добавляти ім'я власника чи користувача, обов'язково при спільному пристрої
        • /mnt/data/USER111/USER222-CAMERA-COPY/ - копія чужих: користувач [1] зберігає копію чужих фоток у своєму каталозі бо зробив копію для себе і звичайно ця копія не призначена для звичайної експлуатації користувачем [2] - власником авторських прав (тема про структуризацію сховища а не правову сторону).
        • D:\\window.human\CAMERA\ - на Windows, [[користувач] чи [власник]], далі CAMERA
    • v2 [частини сховища]
      /mnt/data/USER/CAMERA/ - перше залишається без нумерації приставки [-1]
      /mnt/data/USER/CAMERA-2/ - [CAMERA-2] частина номерується приставкою - лише в наступному основному сховищі чи базі (не інших носіях, незалежних від бази, які не повинні існувати)
  • [CAMERA-FIND] - знайдені чужі матеріали, зберігають окремо від своїх матеріалів, але можна добавити в бібліотеку. Можливо були залишені на сторонніх носіях без належного оформлення резервних копій (що потім змушує повторно лишній раз витрачати час на пошук дублікатів)
    • переноситься після сформованого сховища [CAMERA] (розформування)
    • додавати, видаляти, розформувати
    • не сортувати (це лишнє), не редагувати (модифікація)
    • /mnt/data/USER222-CAMERA-find/ - чужі зберігають окремо
    • /mnt/data/USER/CAMERA/cam-USER222-find/ - альтернативний варіант, якщо дуже хочеться зберігати у своєму сховищі (не рекомендовано)
  • v1 сортування основне – за роком події, назвою папки. Розміщення по роках – основна ціль сортування, завжди.
    Рік пишеться повністю [2020] щоб наступного століття не плутали (від 2100-го).
    Матеріали можуть передатись внукам чи людям - згодом нейромережі без VFX склеюватимуть публічні фотографії для "часової лінії" місцевості.
    • …/CAMERA/yyyy/
    • …/CAMERA/yyyy-yyyy/yyyy/ - об'єднання корисне для загальної публікації від попереднього рівня, але якщо збірка не завершена, наступного року прийдеться перейменовувати.
      …/CAMERA/1950-2000/1999/
    • …/CAMERA/я на морі – поганий варіант починати з події (далі детальніше).
  • v2 сортування додаткове, на права доступу, теж в корені по роках.
    Для шарінгу фізичне розділення папками заважатиме оскільки це сховище для програм, без дублікації получиться лише певним групам чи загально-публічним фотографіям без людей. Зазвичай шарінг потребує налаштувань доступу, без підтримки публікації по тегах прийдеться дублювати папки що неефективно. Є сучасна файлова система ZFS яка при копіюванні насправді не робить фізичні дублікати, але проблему не вирішує і потребує великої кількості носіїв. Використовувати мінімальні імена, а в бібліотеці можна присвоїти інше. Примінимо для публікації колам користувачів Nextcloud (поки не підтримує шарінг по тегах)
    • …/CAMERA/yyyy-public-city.1/ - публічні, переважно без людей)
      …/CAMERA/yyyy-people.1/ - подія, певне коло людей
      …/CAMERA/yyyy-toTheMars/ - подія, поїздка
      …/CAMERA/yyyy-school/ - подія, компанія
      …/CAMERA/yyyy-NEW/ - нові з камер, до перейменування і сортування приватні
      …/CAMERA/yyyy-home/ - домашні, сімейні
    • …/CAMERA/yyyy/home/ - альтернативний формат, для шарінгу прийдеться заходити в папку кожного року.
    • …/CAMERA/yyyy-yyyy-home/yyyy-home/ - об'єднання для спрощеної публікації
  • технічні
    • розподіл за приватністю, без сортування дати
    • [Technical Subject] — це узагальнена назва для технічних об'єктів, речей, документів тощо
    • матеріальна зйомка, техніка
      • 111 technical subject
      • 111-technical_subject
      • 111-TechSubj
    • чутлива до публікації інформація
      • але зазвичай, краще у документи: чеки, документи, фото-замітки
      • 111 technical subject PRIVATE
      • 111-technical_subject-PRIVATE
      • 111-TechSubjPrivate
      • …HomeMaintenance
      • …PropertyDocs
      • …Parcels
  • фото з неправильною датою (напр. оцифровані чи відновлені) у папку manual_date та опис файлів manual date. Дату зйомки розуміти як збереження події, оцифрованим негативам вписувати дату негативів а нові технічні дати неважливі. Після виправлення дат папку розформувати але залишити опис файлу manual date або fake date - "manual" універсальне: фото з датою і без, неправильною і виправленою.
    гірші варіанти: custom.date, wrong date, wrong time, бо після зміни дати прийдеться переробляти.
    …/CAMERA/yyyy-yyyy/1950-1970-manual_date-film_box_579/ - у папку із [приблизним роком]
    …/CAMERA/1950-1970/1950-1970-manual_date-film_box_579/ - до виправлення
    …/CAMERA/1960/ - після виправлення дати знімків внутрішня папка непотрібна
    опис знімків: [manual date] - дата неправильна, вигадана, або виправлена
    опис знімків: [film_box_579] - номер плівки
    опис знімків: [20201231T235959-1] - опціонально, дата оцифровки, напр. взята із параметру перейменування [date]-#
  • збиткові матеріали, оригінали, RAW - окремо, щоб розділити публікацію (при v2) і звичайний перегляд, зменшити навантаження. Деякі програми підтримують управління парами JPEG+RAW, в багатьох випадках краще дозділяти.
    • папка [source]
    • v1 [матеріали спільне сховище] - внутрішня папка [source]. Входять матеріали лише попереднього каталогу а розділені події мають свій [source]
      …/CAMERA/yyyy/source/
      …/CAMERA/2020/20201231T225900-999.jpg
      …/CAMERA/2020/source/20201231T225900-777.cr2 - непарами допустимо різні імена, якщо дивитись по даті
      …/CAMERA/yyyy/source-panorama/ - ресурси створеної панорами, окремо від [source] якщо багато матеріалу
      …/CAMERA/yyyy/source-picasaoriginals/ - перейменовані старі .picasaoriginals, при сортуванні винести лишні матеріали у [source]
    • v2 [матеріали частини сховища]. Ієрархію дублювати, вкінці назви добавляти приставкою.
      …/CAMERA/yyyy/source/ - v1, допустимий при виборі v2, в деякий випадках.
      …/CAMERA-2/yyyy-source/ - v2
  • частини зйомки - належать попередньому рівні і ніколи немають всередині свого [source]. Бажано ділити по 1000 файлів щоб менше зависало при доступі. Тормозять файлові менеджери які на відміну бібліотек невміють працювати з великими об'ємами. Назви послідовна нумерація, порівняно з місяцями значно менше проблем на випадок нового сортування
    • v1 [частини у сховищі] - ніколи не мають всередині свого [source] бо з великою кількістю чи великих проектах велика різниця у кількості і розміру, лишній раз переносити. (напр. RAW у part 5, а готовий JPG у part 2)
      …/CAMERA/yyyy/1 part/ - 1 part, 2 part, 3 part.. .JPG, для звичайного перегляду
      …/CAMERA/yyyy/source/ - матеріали частин у попередньому [source] оскільки частина належить до папки з роком [yyyy]
      …/CAMERA/yyyy-public1/source - аналогічно бо основною виступає папка по доступу
      …/CAMERA/yyyy/1 part/source - поганно, важко змінювати частини
      …/CAMERA/yyyy/01/ - поганно, дописувати [part] бо при публікації подумають що продовження дати - місяць
      …/CAMERA/yyyy/січень/ - поганно, місяці лишні, по частинах легше змінлювати
    • v2 [частини по окремих сховищ] - з часом почнуться розбіжності папок ресурсу і готових зображень (напр. RAW у part 5, а готовий JPG у part 2)
      …/CAMERA-2/yyyy-source/1 part-source/ - а наступними 2 part-source, 3 part-source… Матеріали у [CAMERA-2], відповідно приставка [-source] пишеться у каталозі і частині
  • TimeLapse матеріали і великі зйомки - у групу файлів та свою папку року, окремо від основних каталогів років, [частин] та [source], а для інших подій зазвичай потрібне розділення для різного шарінгу. TL окремо від основних фотографій бо після створення відео рідко пригодяться, щоб зекономити ресурси зменшити рівень бекапу та можливо відмовитись від генерації прев'ю
    …/CAMERA/TimeLapse-public-city1/2020.12.31-TL-street1_sunshine/20201231T225900-12345.jpg - TL згрупований на право доступу для шарінгу
    …/CAMERA/TimeLapse-[public-city1]/[2020.12.31]-TL-[street1].[sunshine]/source/20201231T225900-12345.cr2 - TL має свій [source]
    …/CAMERA/TimeLapse-[кому доступ]/[YYYY.MM.DD]-TL-[місце зйомки].[подія]/source/[date]-#.cr2
    …/CAMERA/TimeLapse/2020.12.31-TL-public-city1-street1.sunshine/source/ - якщо спільний каталог TL тоді прийдеться робити шарінг окремо
    …/CAMERA/2020-public-city1/2020.12.31-TL-street1.sunshine/20201231T225900-12345.jpg - TL основному сортуванні по правах також описувати для шарінгу
  • інші збірки фото в каталозі назвою [MIX]-[подія]
    …/CAMERA/2020-public-city1/MIX-building.street1/
  • назви файлів - дата і нумерація.
    Спочатку дата як основа, нумерація через дефіс, для додаткової рамдомізації.
    Дата до секунди, мілісекунд додатково для швидкісної зйомки.
    Формат YYYYMMDDThhmmsssss, (20241231T132025),
    на основі YYYY-MM-DDThh:mm:ss.sss, (2024-12-31T13:20:25).
    див. [ISO 8601] – https://en.wikipedia.org/wiki/ISO_8601
    Єдиний шаблон дати як універсальний ідентифікатор для сортування по назві у простих засобах, які невміють читати дату знімка. А при різних назвах бувають незручності.
    • не перейменовувати, не переконавшись:
      (1) наявність META-[дата],
      (2) параметр META-[оновлювати дату модифікації у файлі]-?.
      Напр. далі [дата створення файлу] не відповідатиме дійсній даті зйомки, що псуватиме сортування.
    • стандартні камерні назви перейменовувати краще зразу при імпорті
    • лишнього не писати, тимбільше "оригінал" щоб при редагуванні не прийшлось змінювати.
      Для різного опису є відповідне поле в метаданих, теги і функції бібліотеки.
    • розділеним парам JPEG+RAW можна різні назви
    • в камерах синхронізовувати час, особливо для Timelapse
    • digiKam - перейменування:
      • вигляд > сортування > за датою.. Це потрібно для бажаної нумерації при подальшому перейменуванні.
      • перегляд дати, виділити всі (Ctrl+A), перейменувати (F2 або контекстне меню), перейменувати шаблоном.
      • [date]-# - параметр [дата зйомки] і [нумерація]. Дата матиме розділення буквою T, за форматом YYYYMMDDThhmmss.
      • 20201231T225900-12345.jpg - приклад результату перейменування
      • {replace:"oldtext","newtext"} - параметр [заміна]
      • [file]{replace:"oldtext",""} - параметр [заміна], видалить вказаний oldtext

🎞️ оцифрування старих знімків

сканування і знімання: негативів і паперових фотографій

Перехід на цифрові засоби і камери дав різні способи: знімання, збереження, перенесення, перегляд, модифікацію. Фінальний результат робиться постобробкою – програмним забезпеченням.

  • ff >50mm для менших спотворень
  • камера якомога ближче до об"єкту зйомки (негативу) щоб при кропі (обрізці) зображення менше втрачати розширення
    • об'єктив Canon 18-55mm (Kit) – поганий, фокусування надто делеко до об'єкту, після кропу залишається лише 4MP. Тому можливо потрібні "макро" об'єктиви
  • f5.6-f9
    • ff на початкових різкість гірша, при "зумі" відповідно прикривати діафрагму
    • ff на крайніх "закритих" значеннях появляються спотворення кольору
  • освітлення:
    • CRI високий (>95)
    • без мигання, або довга витримка компенсує недолік (але важко знімати), для LED бажано лінійний драйвер
    • температура кольору: теплий або нейтральний, інакше важко виправити WB
    • яскравість світла для малого значення ISO, з урахуванням сильних втрат розсіювача, та впливу втрати ефективності через нагрівання за часом роботи.
      • ймовірно, >30W (LED) сумарно знадобиться.
      • x3 лампочки LED 11W
    • зручна форма щоб легко установити і розсіяти
      • ліхтар із характеристикою лампи High CRI, великий та потужний (див. тему ліхтарі)
    • не рідкісний вибір на випадок заміни одинакового "кольору"
    • дешеві побутові лампочки – погані, не підійдуть за всіма параметрами
  • розсіювач підсвітки:
    • розміщувати подальше негативу і світла (між ними)
    • траекторію зйомки прикривати чорним щоб навколишні предмети не відбивали світло своїм кольором
    • не рекомендується розміщувати світло позаду розсіювача, інакше на негативі відіб'ється нерівномірно просвічений матеріал через його недоліки фактури (як папір)
    • папір ксероксний. По фотографічним міркам: не цільний, після просвітки далеко не білий, відтінок може відрізнятись а на око неможливо відрізнити. Нормальний хібащо відбивачем
  • конструкція
    • камера зафіксована з об'єктом зйомки чи тримачем негативів
    • тримач-рамка
      • повинна забезпечити зручну та одинкаву перестановку кадрів що значно спростить цифрове кадрування
      • горозинтальна для негативів бо знімається плівка одинаково а вертикальні фото будуть перевернуті цифровим способом разом
  • Remote Live View Function - програмою в реальному часі перегляд картинки, управління камерою, миттєвий імпорт зображень. Зручно для: перевірки фокусу і експозиції, перегляду оригіналу. На камерному екрані нічого не видно бо мало пікселів і показує файли не оригіналом а гіршою якістю
    • Adobe Photoshop Lightroom Classic - [1], [2]
    • Canon EOS Utility
  • зберігати у папці manual_date, при імпорті нові назви [date]-#, опис знімків manual date і вказаний [номер плівки]
  • в редакторі робити загальний пресет для схожих знімків, зазвичай в межах плівки і примінити для всіх RAW. Зміни у пресеті:
    • корекція об'єктиву
    • кроп (обрізка). RAW не перевертати інкше пресет кроп не підійде
    • WB (баланс білого)
    • інверсія кольору (негатив)
    • експозиція
  • перегляд і правка по одному
  • експорт редагованих, напр. у JPG 80% 4:4:4
  • Using free RawTherapee for inverting DSLR-digitized color negatives

📦 jpeg устарів, нові формати медіа файлів

матеріали потрібно зберігати якомога кращої якості (бажано оригінали) для подальшого експорту в ефективніший формат, згодом, коли підтримає софт і девайси на апаратоному рівні

відновлення знімків, сортування

це шаблон виконання, перелік дій, не містить рекомендації інструментів відновлення. На основі свого звіту.

#заголовок: відновлення CAMERA із [HDD ADBCD] 1-Петабайт | archive

стан, загальна інформація

  • TODO | не завершено | 3051
  • звернення: люди, поділіться файлами, знятими до 3050 року, щоб замінив не відновленими – кращою версією.
  • походження:
    фото та відео, датою до 3050 року, втрачені після збою розмітки розділів, носія [HDD ADBCD] 1-Петабайт
  • застереження приватності (для тих хто скористається даними):
    відновлене може містити приватні дані, які не відображаються повною мірою звичайним переглядом. Буває невідповідне прев'ю (інтегроване), взяте від іншого файлу чи зображення, через неправильне відновлення. Програма перегляду може відображати зі всього зображення, пропускаючи інтегроване превю, таким чином на практиці можна помилково опублікувати начебто перевірені файли з конфіденціним вмістом.

початок

  • замітка версій відновлення. Перелік: метод, розміщення, нюанси результату (в межах методу без додаткових дій)
  • налаштування (використання) зовнішнього XMP, щоб відновлені знімки не розійшлись з оригіналом, інакше важче порівняти з бекапом | бібліотека, digiKam | #read-only-mode
    • альтернативний метод: обмеження прав файлів у файловій системі - невірний, проте легший початківцям, доступний лише напряму з пристрою, а не доспний при віддаленому доступі сховища.
  • сховище відновлених
    • окремо від основного сховища CAMERA.
    • Папки з назвою методу відновлення.
    • Добавити у бібліотеку кореневу папку, при імпорті можна назвати скорочено.
      Сортування буде пізніше.
      ./RECOVERY_device/ - імпортувати, назначити назву можна лише раз при імпорті [RECOV]
      ./RECOVERY_device/found - підкаталог методу відновлення
      ./RECOVERY_device/tool_1

опис та тимчасові імена

  • замітка скорочень і описів. У текстовому файлі Markdown (.md) біля відновлених. Якщо примінялись різні шаблони, історія старих для заміни. Напр.:
    • recov - файл відновлений
    • manual_date - дата неправильна, вигадана, або виправлена
    • FOU - винесені з папки found.000
    • chk або FIX - перейменовано суфікс (.chk), але мабуть, потрібна модифікація спецальною програмою
    • program - відновлено програмою program
    • # - digiKam, параметр [нумерація]
  • відновленим написати в описі про відновлення.
    • Перед зовнішнім переміщенням зміни записати у метадані файлу.
      recovery
  • метод відновлення, якщо відновлювали різними способами. Допоможе швидше вибрати кращі якщо один з методів виясниться кращим.
    recovery, found, chk
    recovery, tool
  • manual date - дата неправильна, вигадана, або виправлена
  • перейменування. При сортуванні відновлених виразні імена допоможуть якщо є бекапи - відсіяти лишні не відкриваючи файл. Потім прийдеться знову перейменовувати тому дописувати хібащо слово recovery.
    • ім'я матиме послідовність:
      (1)дата-(2)нумерація = [date]-# – нормальне імя
      (1)дата-(2)нумерація-(3)recovery = [date]-#-recovery
      (1)дата-(2)нумерація-(3)recovery_(4)метод відновлення = [date]-#-recovery_found
      1. дата знімка завжди зліва
      2. нумерація після дати
      3. мітка про відновлення
      4. метод відновлення
    • не іменувати файли з неправильною датою, збирати в окрему папку, manual date.
      Якщо немає метаданих тоді опціонально час створення файлу. Деякі програми читають тільки дату зміни яка спочатку відповідає даті створення при відновленні. З наступною модифікацією (напр. теги) дати знову зміняться тому перейменовувати зручніше через digiKam який читає дату створення. Для негайної публікації пошкоджених можна вписати в назву дату відновлення щоб через роки хочаби приблизно розуміти з якого десятиліття фото. Фото з втраченими датами потім переглядати по даті відновлення оскільки деякі файли відновляться послідовно як були дефрагментовані на диску.

сортування, методи пошуку, фільтри, digiKam

В основному розділяю на 3 етапи:

  • етап-1 | пошук дублікатів - видалення візуально пошкоджених, залишення кращих версій з оригінальним іменем чи метаданими.
    Легше почати з видалення дублікатів, серед сортованих подій.
    • вигляд - розділення - без розділення по каталогах
    • перегляд дати. Відображення всіх баз, щоб оглянути з каталогами бекапу
    • справа вкладка показує дублікати, якщо є з нормальним іменем від бекапу тоді виділений видаляєм
    • опціонально приміняти фільтри пошуку: дата, імена-події, розширення, камера, мітки, обличчя…
    • допоміжний варіант - відсіяти великі, але відновлені різної степені якості мають різний розмір.
      Вигляд - сортування - за розміром
    • допустиме виправлення дат - лише якщо зразу виправляти імена файлу, інакше - в іншому етапі
  • етап-2 | сортування - переміщення у новий каталог. Відновлені що залишились перенести у минулий бекап
    • перегляд каталогу, вибрати відновлені. Виділені переносити мишкою в каталоги
    • вигляд - розділення - розділення по каталогах.
      У розділенні додатковий спосіб переносу, більше підходить при перегляді за датою всіх каталогів (якщо по імені впізнавати звідки файл)
  • етап-3 | кінцеве сортування нової колекції (каталогу) - нові імена, розставити теги, розділити якщо багато файлів. Напр. у папці нормальні і відновлені, тоді фільтрувати текстом "recov", виділяти, перейменувати
    • нові теги, мабуть, краще лише для розділення прав. Зібрані папки по правах - виділити і примінити тег

додаткові засоби

  • функція пошук дублікатів, пошук обличь, - помагає відсіяти лишні дублікати з втраченими датами. Не використовувати в автоматичному режимі бо інколи з оригіналами менші файли позначає кращими.
  • функція мітка якості (beta)
Last changed by 
 
testok
0
263

Read more

software

🧰 cписок програм/протоколів/сервісів за категоріями користування. Більшість FOSS та певний відбір, а не альтернативи.

Jun 18, 2025
selfhosted

само хостинг як потреба цифрового життя.

Jun 5, 2025
power

#power #shutdown

Jun 2, 2025
smartphones

смартфони і Android

Jun 1, 2025
Read more from testok
Published on HackMD