Immich 3.0
(github.com/immich-app)- Immich v3.0.0 เป็นเมเจอร์รีลีสถัดไปหลังจากทำงานมาหลายเดือน โดยมีการแก้ไขแบบไม่ทำลายต้นฉบับบนมือถือ, พรีวิว workflow, การปรับปรุงการแบ็กอัปเบื้องหลัง, การตรวจสอบความสมบูรณ์, พรีวิวการทรานส์โค้ดวิดีโอแบบเรียลไทม์ และอื่น ๆ
- รีลีสนี้มี Breaking changes แต่จำนวนมากเป็นการเปลี่ยนแปลง endpoint ของ Immich API จึงส่งผลหลักต่อเครื่องมือ third-party ที่ผสานกับ Immich API และผู้ใช้ส่วนใหญ่สามารถอัปเดตได้ตามวิธีเดิม
- การอัปเกรดทำได้โดยเปลี่ยน IMMICH_VERSION ใน
.envจากv2เป็นv3แล้วรันdocker compose pull && docker compose up -dโดย v3.0.0 ยุติการรองรับ pgvecto.rs ดังนั้นสภาพแวดล้อมก่อน v1.133.0 ต้องทำ migration ไป VectorChord - แอปมือถือได้นำโมเดลการแก้ไขแบบไม่ทำลายต้นฉบับเช่นเดียวกับเว็บมาใช้ และปรับปรุงการแบ็กอัปเบื้องหลังบน Android ด้วยตัวจัดตารางงานแบบ periodic ส่วน iOS จะรันการซิงก์และอัปโหลดแบบขนานภายในเวลารันเบื้องหลังอันสั้น
- การทรานส์โค้ดวิดีโอแบบเรียลไทม์ยังเป็น ฟีเจอร์ทดลอง และปัจจุบันมีในเว็บแอปเท่านั้น ส่วนแอปมือถือกำลังพัฒนาอยู่ จึงไม่แนะนำให้ลบไฟล์ทรานส์โค้ดออฟไลน์เดิมด้วยตนเอง
การอัปเดตและการเปลี่ยนแปลงด้านความเข้ากันได้
- Immich v3.0.0 ถูกประกาศเป็นเมเจอร์เวอร์ชันถัดไป และมี Breaking changes หลายรายการ
- Breaking changes จำนวนมากเป็นการอัปเดต API endpoint จึงส่งผลหลักต่อเครื่องมือ third-party ที่ผสานกับ Immich API
- ผู้ใช้ส่วนใหญ่สามารถอัปเดตได้ด้วยวิธีเดียวกับเดิม
- คู่มือ migration ฉบับเต็มมีลิงก์แยกให้ในประกาศรีลีส
- v3.0.0 ยุติการรองรับ pgvecto.rs
- หากกำลังรัน Immich ก่อน v1.133.0 และยังไม่ได้ migration ควรตรวจสอบการ migration ไป VectorChord ก่อน
- ลิงก์คำแนะนำ: https://docs.immich.app/install/upgrading/#migrating-to-vectorchord
- ขั้นตอนการอัปเดต:
- เปลี่ยน
IMMICH_VERSION=v2เป็นIMMICH_VERSION=v3ในไฟล์.env - รัน
docker compose pull && docker compose up -d
- เปลี่ยน
Release candidate และช่องทางแจ้งเตือน
- v3.0.0 เป็นรีลีสแรกที่ Immich ใช้ release candidate
- Release candidate คือพรีรีลีสที่ผ่านการทดสอบแล้วแต่ยังไม่ใช่รีลีสทางการ ใช้เพื่อค้นหาและแก้บั๊กที่เหลือก่อนรีลีสสุดท้าย
- หากต้องการรับการแจ้งเตือน release candidate ใน Immich สามารถเปลี่ยน release channel จาก
Stableเป็นRelease candidateได้ที่Admin settings > Version check
การแก้ไขและการแบ็กอัปบนมือถือที่ดีขึ้น
- การแก้ไขแบบไม่ทำลายต้นฉบับบนมือถือ เป็นงานต่อเนื่องจากฟีเจอร์แก้ไขภาพที่เพิ่มบนเว็บก่อนใน v2.5.0
- ตัวแก้ไขบนมือถือเดิมใช้ระบบแยกต่างหากที่สร้าง asset ใหม่โดยไม่แก้ไขรูปภาพที่เดิม
- ตัวแก้ไขบนมือถือใน v3.0.0 มีความสามารถเดียวกับเวอร์ชันเว็บ และสามารถครอบตัด หมุน และปรับภาพได้โดยไม่แตะต้องไฟล์ต้นฉบับ
- การแก้ไขเป็นแบบไม่ทำลายต้นฉบับ จึงสามารถกลับมาแก้ไขต่อหรือย้อนกลับได้ภายหลัง และสามารถแก้บนมือถือแล้วไปปรับต่อบนเว็บได้
- ฟีเจอร์บางส่วนที่เคยมีใน implementation การแก้ไขบนมือถือก่อนหน้าถูกนำออก
- การเปลี่ยนสีรูปภาพ
- การแก้ไข Live Photo
- การแก้ไข asset แบบโลคัล
- มีแผนจะนำฟีเจอร์บางส่วนกลับมาในรีลีสอนาคต
- การแบ็กอัปเบื้องหลังบน Android ทำงานได้เสถียรมากขึ้นด้วย ตัวจัดตารางงานแบบ periodic
- ก่อนหน้านี้จำกัดเฉพาะรูปภาพที่ถ่ายใหม่
- ตอนนี้สามารถอัปโหลดทั้งไลบรารีในเบื้องหลังได้
- เข้ากับข้อจำกัดการรันเบื้องหลังของ Android ได้ดีขึ้น และจัดการการจัดระเบียบงาน รวมถึงคำเตือนเกี่ยวกับการปรับแต่งแบตเตอรี่และการตั้งค่าการแจ้งเตือน
- งาน background refresh บน iOS เปลี่ยนให้รันการซิงก์และอัปโหลดแบบขนาน เพื่อให้อัปโหลดเริ่มได้ภายในเวลาสั้น ๆ ที่ iOS อนุญาต
พรีวิว workflow
- Workflows เป็นฟีเจอร์พรีวิวแรกสำหรับทำให้งานในไลบรารีเป็นอัตโนมัติ
- สามารถสร้าง automation ได้ด้วยตัวสร้างแบบ drag-and-drop โดยเชื่อม trigger, filter และ action เข้าด้วยกัน
- เข้าถึงได้จาก
Utilities > Workflowsบนเว็บ - สามารถสร้าง workflow ว่างใหม่ หรือดูเทมเพลตที่เตรียมไว้ล่วงหน้าได้
- ตัวแก้ไขมีทั้ง Visual editor และ JSON editor
- Visual editor เหมาะกับการประกอบ workflow
- JSON editor เหมาะกับการแชร์หรือรับเนื้อหา workflow กับผู้อื่น
- แต่ละ workflow ประกอบด้วย
triggerและชุดsteps- Trigger คือจุดเริ่มต้นของ workflow และเมื่อเกิด trigger แล้วขั้นตอนต่าง ๆ จะถูกประเมิน
- Steps ประกอบด้วย Filters ที่เป็นเงื่อนไข และ Actions ที่เป็นผลลัพธ์
- วิธีแชร์มีสองแบบคือข้อความและ JSON
- ข้อความเหมาะกับการแชร์ในฟอรัมหรือการสาธิต
- JSON เหมาะกับการคัดลอกการตั้งค่า workflow อย่างแม่นยำ
- ไอเดีย trigger และ action ใหม่ ๆ รับ feedback ใน discussion thread แยกต่างหาก
การสำรวจไลบรารีและการตรวจสอบความสมบูรณ์
- เพิ่มหน้า Recently Added บนเว็บและมือถือ
- สามารถดูไลบรารีตามเวลาที่ถูกเพิ่มเข้า Immich ไม่ใช่เวลาที่ asset ถูกถ่าย
- ช่วยให้หาสิ่งที่เพิ่งเข้ามาใหม่ได้ง่ายเมื่อสำรวจชุดที่นำเข้าใหม่
- บนเว็บหาได้ในแท็บ
Exploreและบนมือถือในแท็บSearch
- เพิ่ม integrity reports ในหน้าบำรุงรักษา
- Immich จะสแกนไดเรกทอรีในระบบไฟล์และเปรียบเทียบกับข้อมูลที่เก็บในฐานข้อมูล
- หากมีไฟล์ในไดเรกทอรีที่ Immich ไม่รู้จัก จะแสดงเป็น
untracked - หากมี reference ในฐานข้อมูลแต่ไม่มีไฟล์ในตำแหน่งนั้น จะแสดงเป็น
missing - หาก checksum ของไฟล์บนดิสก์ต่างจาก checksum ที่ Immich เก็บไว้ จะแสดงเป็น
checksum mismatch
- checksum mismatch มักเกิดจากไฟล์เสียหาย และอาจเป็นผลจากการเปลี่ยนชื่อที่ไม่ถูกต้องได้ด้วย
- งานตรวจสอบความสมบูรณ์สามารถตั้งค่าได้ว่าจะรันทุกคืนเมื่อใด และนานเท่าใด
วิดีโอและการเล่นสื่อ
- เพิ่มฟีเจอร์ Slideshow ในแอปมือถือ ทำให้เล่นรูปภาพและวิดีโออัตโนมัติบนหน้าจอได้เหมือนบนเว็บ
- เพิ่ม HLS และการทรานส์โค้ดวิดีโอแบบเรียลไทม์ เป็นฟีเจอร์พรีวิว
- สามารถแปลงวิดีโอระหว่างเล่นได้โดยไม่ต้องสร้าง transcode ออฟไลน์ไว้ล่วงหน้า
- รองรับการสลับคุณภาพแบบ manual และ automatic
- สามารถทรานส์โค้ดเป็น codec ที่เหมาะสมที่สุดที่ client รองรับ
- หากปิดการทรานส์โค้ดออฟไลน์ จะช่วยลดภาระพื้นที่จัดเก็บได้
- มีการระบุรายการที่ยังไม่ได้ implement ด้วย
- HDR สำหรับ client ที่เข้ากันได้
- remuxing ต้นฉบับโดยไม่ทรานส์โค้ดเมื่อ bandwidth เพียงพอ
- การทรานส์โค้ดแบบเรียลไทม์เป็น ฟีเจอร์ทดลอง และพฤติกรรมอาจเปลี่ยนไปในแต่ละเวอร์ชัน
- ปัจจุบัน implement เฉพาะเว็บแอป และ implementation บนแอปมือถือกำลังดำเนินการ
- สามารถเปิดใช้งานได้ใน video transcoding settings
- แม้เปิดการทรานส์โค้ดแบบเรียลไทม์แล้ว การทรานส์โค้ดออฟไลน์จะไม่ถูกกระทบโดยตรง ดังนั้นหากต้องการปิดการทรานส์โค้ดออฟไลน์ ต้องปรับ transcode policy ด้วย
- asset ที่นำเข้าก่อน v3 ต้องรัน Metadata Extraction ใหม่จากแผงงานเพื่อให้ถูกประมวลผลซ้ำ
- เซิร์ฟเวอร์ต้องแรงพอที่จะจัดการการทรานส์โค้ดแบบเรียลไทม์ และแนะนำให้ใช้ hardware acceleration แม้จะไม่บังคับ
- เว็บแอปเพิ่มวิดีโอเพลเยอร์แบบ custom ใหม่ที่เข้ากับดีไซน์ของ Immich
- ให้ control และ layout เดียวกันในทุกอุปกรณ์
- มีฟีเจอร์พื้นฐาน เช่น การเปลี่ยนความเร็วการเล่น
- ยังช่วยแก้ปัญหาที่ control ของ OS บน iOS ถูกซ่อนอยู่หลัง navigation bar ของ Immich ได้ด้วย
Android, OCR, การแชร์ และ flow ของอัลบั้ม
- บน Android สามารถใช้ Immich เหมือน แอปแกลเลอรี/ตัวดูภาพ ได้
- เมื่อแตะรูปภาพหรือวิดีโอจากแอปอื่นแล้วเลือก Immich จะเปิดโดยตรงใน asset viewer
- มีตัวเลือกแชร์ไฟล์หรืออัปโหลดเข้าไลบรารี
- วิธีตรวจจับไฟล์ที่มีอยู่แล้วในไลบรารีจะปรับปรุงในอนาคต
- asset viewer บนมือถือเพิ่ม toggle OCR สำหรับไฮไลต์ข้อความที่รู้จำได้ในรูปภาพ
- สามารถเลือกและคัดลอกข้อความจากภาพได้
- ในแอปมือถือสามารถอัปโหลดรูปภาพโลคัลเข้าอัลบั้มโดยตรงได้
- สามารถเพิ่มเข้าอัลบั้มได้โดยตรงจาก asset bottom sheet เช่นกัน
- ลดความติดขัดของ flow ที่ต้องอัปโหลดก่อนแล้วค่อยจัดระเบียบภายหลัง
- เมื่อแชร์บนมือถือ สามารถเลือกขนาดภาพก่อนส่งได้
- ช่วยให้ไฟล์เล็กสำหรับแอปส่งข้อความ
- หรือแชร์แบบคุณภาพเต็มได้หากต้องการ
- เปลี่ยนพฤติกรรมเริ่มต้นได้ที่
App Settings > Preferences - กดปุ่มแชร์ค้างไว้เพื่อเลือกตัวเลือกได้ทันที
- ปรับปรุงประสิทธิภาพการสำรวจ timeline ในกรณีที่มี asset จำนวนมากภายในหนึ่งเดือน ลดสถานการณ์ที่แท็บเบราว์เซอร์ค้าง
กลุ่มการเปลี่ยนแปลงหลัก
- Breaking changes รวมถึง migration จาก
class-validatorไปเป็น zod, การนำ replace asset ออก, การนำ endpoint timeline sync เก่าออก, การยุติรองรับpgvecto.rs, การเปลี่ยนโครงสร้าง error response และอื่น ๆ - Deprecated changes รวมถึงการ deprecate ไปในทิศทางแทนที่ route แบบ PUT ด้วย PATCH
- รายการด้านความปลอดภัยมีการแก้ไขให้รูปโปรไฟล์ผ่าน thumbnail pipeline
- ฟีเจอร์ที่เพิ่มมีทั้งการแก้ไขบนมือถือ, Android periodic work manager task, วิดีโอเพลเยอร์เว็บแบบ custom, หน้า recently added assets, workflows & plugins, การทรานส์โค้ดแบบเรียลไทม์ HLS, OCR บนมือถือ, งานตรวจสอบความสมบูรณ์ และอื่น ๆ
- การแก้บั๊กมีทั้งการ normalize อีเมล OAuth, การจัดระเบียบชื่อไฟล์ก่อนเพิ่มเข้า zip, การป้องกันไม่ให้ partner เห็น asset ที่ถูกล็อก, การแก้ไขการสร้าง face โดยไม่ได้รับอนุญาต, การป้องกันหน่วยความจำไม่พอระหว่างอัปโหลดผ่าน CLI และอื่น ๆ
ข้อจำกัดและคำตอบที่ยืนยันจากการสนทนา
- สำหรับการอัปเกรดจาก v2.0.1 เป็น v3.0.0 มีคำตอบว่าไม่มีคำแนะนำพิเศษเพิ่มเติม ให้ทำตามขั้นตอนอัปเดตใน release notes
- กรณีที่มองไม่เห็นอัลบั้มหลังอัปเดตมือถือดูเหมือนเป็นบั๊ก migration ฝั่งมือถือ และอาจแก้ได้ด้วยการ logout แล้ว login ใหม่ หรืออัปเดตเซิร์ฟเวอร์เป็น v3
- สำหรับ flow ที่หลัง restore backup ของ iPhone แล้วรับรูปที่อยู่บนเซิร์ฟเวอร์กลับลงโลคัลในแอปมือถือ แอปมือถือยังไม่มีตัวเลือก bulk download และดาวน์โหลดได้เฉพาะทีละรูป
- สำหรับคำถามเรื่องการลบวิดีโอที่ทรานส์โค้ดเดิมหลังเปิดการทรานส์โค้ดแบบเรียลไทม์ มีคำตอบว่าแอปมือถือยังไม่รองรับการทรานส์โค้ดแบบเรียลไทม์ จึงยังต้องใช้วิดีโอที่ทรานส์โค้ดเดิม และไม่แนะนำให้ลบเอง
- มีคำตอบว่าไม่มีแผนฟีเจอร์แปลงรูป HEIC เป็น JPG ทันที และ thumbnail ที่สร้างอยู่ตอนนี้เป็น JPEG/WEBP จึงเข้ากันได้กับทุกเบราว์เซอร์และ client
- การปรับปรุงการแบ็กอัปเบื้องหลังบน Android ไม่ใช่การเปลี่ยนแปลงเพื่อแก้ปัญหารูปภาพขนาดใหญ่กว่า 100MB กับข้อจำกัด Cloudflare แต่เป็นการปรับปรุงให้ background task รันเป็นรอบ ๆ ได้บ่อยขึ้น
- ในการทรานส์โค้ดแบบเรียลไทม์ codec ถูกเลือกโดย client ไม่ใช่เซิร์ฟเวอร์ และหากเซิร์ฟเวอร์โฆษณา AV1 variant client ที่ถอดรหัส AV1 ได้อาจเลือกทางนั้น
- มีแผนเพิ่มการตั้งค่าสำหรับเลือก codec และ resolution ที่เซิร์ฟเวอร์จะโฆษณา
- การปรับปรุง casting อยู่ในรายการสิ่งที่ต้องทำ และมีคำตอบว่าต้องเขียน cast ใหม่ทั้งหมดและเพิ่มการทรานส์โค้ดแบบเรียลไทม์ด้วย
- ผู้ใช้ที่โพสต์ข้อผิดพลาด
No vector extension found. Available extensions: vchord, vectorหลังอัปเกรด ภายหลังระบุว่าแก้ได้แล้ว - เกี่ยวกับการตรวจ checksum mismatch ใหม่ มีความเห็นว่าผู้ใช้ที่เคยแก้ไขรูปที่อัปโหลดจากภายนอก Immich ในอดีตอาจมี checksum mismatch หลายร้อยรายการ และฟีเจอร์คำนวณ checksum ใหม่จะมีประโยชน์
- เกี่ยวกับการ migration ไป VectorChord มีความเห็นว่าผู้ใช้ก่อน v1.102 อาจพลาดการเปลี่ยนแปลง opt-in ของ
DB_DATA_LOCATIONจึงควรมีคำเตือนหากพบปัญหา
การสนับสนุนและสินค้า
- พร้อมกับรีลีส v3.0.0 มีการประกาศสินค้า Immich ใหม่ด้วย
- เสื้อผ้าเด็ก
- เสื้อผ้าปักโลโก้ Immich แบบสีเต็ม
- หน้าสินค้า: https://immich.store
- สามารถสนับสนุนโครงการได้ด้วยการซื้อ product key หรือซื้อสินค้า
- product key: https://buy.immich.app
- merchandise: https://immich.store
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ผมสอน คลาสพัฒนาซอฟต์แวร์ฟรี ให้กับนักศึกษาปริญญาตรี และตื่นเต้นมากที่งานที่ทำเป็นการบ้านในคลาสถูกพบอยู่ในโปรเจกต์จริง
บั๊กฟิกซ์ที่ถูกระบุเป็นรายการแรกคือพูลรีเควสต์สุดท้ายจากทั้งหมดสามรายการที่นักศึกษาคนนั้น merge เข้า Immich ระหว่างเรียน เลยรู้สึกภูมิใจมาก
เห็นในคอมเมนต์พูดเรื่องการเข้ารหัสกันเยอะ เลยขอแชร์การตั้งค่าของผม ผมรัน Immich สำหรับครอบครัวและเพื่อน ๆ บน เซิร์ฟเวอร์ประมูลของ Hetzner มาประมาณปีครึ่งแล้ว
ในชุมชน Hetzner มีเอกสารทางการสำหรับการเข้ารหัสดิสก์ทั้งลูก: https://community.hetzner.com/tutorials/install-debian-with-...
ใช้ SSL ฟรีจาก Letsencrypt และสามารถซ่อน Immich ไว้หลัง Nginx proxy ที่จัดการ SSL ได้อย่างง่ายดาย
ถ้าใช้การสำรองข้อมูลอัตโนมัติผ่าน cron เพื่อเก็บข้อมูลทั้งหมดของ Immich ไว้ใน NAS ภายในที่เข้ารหัส ก็จะได้ระบบที่เชื่อถือได้ พร้อมการเข้ารหัสทั้งระหว่างส่งและตอนจัดเก็บ จนถึงตอนนี้งานบำรุงรักษาเท่ากับ 0 ครั้งพอดี
ผมทิ้งทราฟฟิกที่ไม่ได้มาจาก 3 ภูมิภาคในระดับ IP จึงปลอดภัยขึ้น และยังสามารถเพิ่ม WAF ให้กับ Nginx proxy ได้ด้วย
เหตุผลที่ผมมองว่าปลอดภัยกว่า Google/iCloud ด้วยซ้ำคือเวกเตอร์โจมตีจาก “พนักงานบริษัท” เล็กกว่ามาก มีกรณีที่บันทึกไว้ด้วยว่า Google ตรวจดูรูปภาพและถึงขั้นยินดีแจ้งตำรวจผิด ๆ: https://www.eff.org/deeplinks/2022/08/googles-scans-private-...
แน่นอนว่าในทางทฤษฎีพนักงาน Hetzner อาจเข้าถึงเซิร์ฟเวอร์ทางกายภาพแล้วดึงคีย์เข้ารหัสจาก RAM หรือขโมยคีย์ด้วย SSH server ปลอมได้ แต่เป็นการโจมตีที่ซับซ้อนกว่ามาก ยังไม่เคยมีการบันทึกไว้ และมีความเสี่ยงที่จะถูกตรวจพบด้วย
การตั้งค่านี้คือการเข้ารหัสระหว่างส่งและการเข้ารหัสขณะจัดเก็บ สำหรับผู้ให้บริการคลาวด์รายใหญ่ การเข้ารหัสขณะจัดเก็บอาจสำคัญน้อยกว่า เพราะพวกเขาน่าจะจัดการวงจรชีวิตดิสก์ได้ดีกว่าบริษัทหรือบุคคลส่วนใหญ่
โอกาสที่ใครสักคนจะบุกดาต้าเซ็นเตอร์ทางกายภาพ หรือได้ไดรฟ์ refurbished ที่ไม่ได้จัดการ/ลบอย่างถูกต้องนั้นต่ำ
จะบอกว่าปลอดภัยกว่าผู้ให้บริการแบบ managed เสมอไปก็คงยาก เพราะคุณอาจไม่ใช่วิศวกรความปลอดภัย และมีทรัพยากรในการปกป้องเซิร์ฟเวอร์น้อยกว่ามาก
มันช่วยกันไม่ให้ Google/iCloud scrape ข้อมูล แต่ไม่ได้หมายความว่า Hetzner จะเข้าถึงข้อมูลไม่ได้ Hetzner ควบคุม hypervisor ชั้นบนและ control plane ที่จัดการเซิร์ฟเวอร์/VM ดังนั้นเราไม่รู้ว่ามีฟีเจอร์อะไรถูก implement ไว้บ้าง
สิ่งที่หน่วยข่าวกรองทำได้ส่วนใหญ่ไม่เคยรั่วไหลหรือถูกเปิดเผยเป็นเอกสารสาธารณะ
ถ้าเป็นการเข้ารหัสแบบ end-to-end จริง ข้อมูลทั้งหมดบนดิสก์ต้องถูกเข้ารหัสจากไคลเอนต์ที่ครอบครัวใช้ และแม้จะไล่ดู volume ของดิสก์ก็ต้องเห็นแต่ ciphertext เท่านั้น
เป็นซอฟต์แวร์ที่ยอดเยี่ยมจริง ๆ และอยู่ระดับเดียวกับ Google Photos เลย หลังจากเริ่มทำ homelab ผมก็ใช้มันไว้หลัง Tailscale มาหลายเดือนโดยไม่มีปัญหาเลย
จริง ๆ แล้ว หลังจากติดขีดจำกัดพื้นที่ 100GB ของ Google Photos ผมก็ย้ายมา Immich และนั่นเป็นจุดเริ่มต้นที่ทำให้ผมเริ่ม self-host ซึ่งกระบวนการนั้นสนุกมากจริง ๆ
ไม่น่าเชื่อว่าผลิตภัณฑ์ self-host ที่สมบูรณ์ระดับนี้จะฟรี ด้วยเหตุผลเดียวกันนี้ ขอปรบมือดัง ๆ ให้ HomeAssistant, PiHole, paperless-ngx, Dawarich และโปรเจกต์อีกมากมาย
ขอแสดงความยินดีและขอบคุณทีมที่ช่วยให้ผมจัดระเบียบความทรงจำส่วนตัวได้
มีคอมเมนต์จำนวนมากบอกว่าตรงนี้ไม่มีการเข้ารหัสแบบต้นทางถึงปลายทาง แต่เอาจริง ๆ ผมไม่รู้ว่าทำไมถึงจำเป็น
สมมติว่ามีขโมยบุกเข้ามาแล้วขโมยโฮมแล็บไป เพราะไม่มีการเข้ารหัสแบบต้นทางถึงปลายทาง เลยสามารถดูรูปคุณยายที่เสียไปแล้วได้ แย่แล้วสิ!
สถานการณ์ที่เป็นไปได้มากกว่าคือมือถือมีปัญหา ถ้าไม่มีการเข้ารหัสแบบต้นทางถึงปลายทาง ต่อให้ทำคีย์หาย ก็ไม่ได้หมายความว่าจะเสียความทรงจำสุดท้ายของคุณยายไปด้วย แค่คัดลอกไฟล์
.jpgไปยังเครื่องใหม่ก็พอแต่ก็ยังต้องคิดให้รอบคอบเรื่องการแลกเปลี่ยนด้านการเข้าถึงที่การเข้ารหัสแบบต้นทางถึงปลายทางนำมาสู่ผู้ใช้ทั่วไป ในกรณีนี้ ถ้าทำคีย์หรือรหัสผ่านหายหรือลืม ก็อาจเสียรูปถ่ายสำคัญทั้งหมดไป ซึ่งค่อนข้างร้ายแรง
Google Photos หรือ iPhotos ทำให้ผู้คนรู้สึกว่ารูปถ่ายของพวกเขาปลอดภัย
อีกทั้งยังทำให้โฮสต์อินสแตนซ์บนคลาวด์สำหรับ Immich ได้ง่ายขึ้น โดยไม่ต้องเข้ารหัสระบบไฟล์ของเซิร์ฟเวอร์ระยะไกล/VPS โดยเฉพาะเมื่อเช่าเซิร์ฟเวอร์จากผู้ขายรายเล็ก ก็ต้องระวังเสมอว่าจะเชื่อถือการควบคุมการเข้าถึงของพนักงานได้แค่ไหน
ผมรู้ว่าหากมีการเข้าถึงทางกายภาพ ก็หลีกเลี่ยงความเชื่อใจระดับหนึ่งไม่ได้ แต่การจัดการดิสก์ระหว่างการบำรุงรักษาก็สำคัญเช่นกัน
ถ้าเป็นแบบนั้น ฟีเจอร์อย่างการค้นหาเชิงความหมาย การจดจำใบหน้า การทรานส์โค้ดวิดีโอ และการสร้างภาพย่อ ก็ต้องย้ายไปทำที่ไคลเอนต์
Immich ตั้งอยู่บนสมมติฐานว่าเซิร์ฟเวอร์สามารถเข้าถึงรูปภาพได้และเราเชื่อถือมัน ในการโฮสต์เองก็เป็นโครงสร้างแบบนั้นเสมอ
ผู้ใช้ส่วนใหญ่ก็ให้ความเชื่อใจแบบเดียวกันกับ Google และ Apple อยู่แล้ว ดังนั้นผมว่าก็สมเหตุสมผล
ถ้าเป็น สถาปัตยกรรมเข้ารหัสแบบต้นทางถึงปลายทาง จริง ๆ ก็น่าจะใช้ที่เก็บข้อมูลคลาวด์ โฮสติ้งแบบมีผู้ดูแล และแบ็กอัปนอกสถานที่ได้ยืดหยุ่นขึ้น
ถ้าเป็น การโฮสต์เอง ก็ไม่จำเป็นต้องกันไม่ให้ผู้ดูแลระบบเข้าถึงไฟล์
ตอนนี้เราเก็บแบบดิจิทัลและสำรองไว้ภายนอกได้ การเปลี่ยนแปลงที่ Immich ต้องมีก็แค่นั้นก็เพียงพอแล้ว
ถ้าเข้ารหัสทุกอย่างแบบสมบูรณ์ กลับจะเป็นการเชิญปัญหามากขึ้น
ตอนย้ายจาก iOS ไปใช้ GrapheneOS ผมตัดสินใจโฮสต์รูปถ่ายเอง และก็พิจารณา Immich ด้วย แต่สุดท้ายเลือก Ente เพราะเรื่องการเข้ารหัส
Ente Photos ขัดเกลามาดีมาก และคุณภาพเทียบได้กับ Apple Photos
ผมชอบที่ไม่ได้เปิดแค่ไคลเอนต์เหมือนโปรเจกต์เข้ารหัสแบบต้นทางถึงปลายทางจำนวนมาก แต่ยังเปิดเซิร์ฟเวอร์และคงความสามารถในการโฮสต์เองไว้ด้วย
ยังสามารถแชร์ให้ใครก็ได้ร่วมเพิ่มรูปในอัลบั้มโดยไม่ต้องมีบัญชี และผมก็ชอบฟีเจอร์ที่ล็อกให้เห็นเฉพาะรูปที่เลือกไว้ตอนยื่นมือถือให้คนอื่น
ในแง่การโฮสต์เอง แม้แต่การอัปโหลดรูปก็ยังทำได้ไม่เสถียร เคยมีช่วงที่อัปโหลดอะไรไม่ได้เลยหลายวัน และไม่มีข้อมูลวินิจฉัย ต้องบิลด์และดีบักเอง
ผมเปิดแอปไว้ด้านหน้า เสียบชาร์จค้างไว้ทีละหลายชั่วโมง และปิดทั้งการอัปโหลดวิดีโอกับฟีเจอร์แมชชีนเลิร์นนิงเพื่อให้โฟกัสแค่รูปถ่ายแล้ว ก็ยังเป็นแบบนั้น
ฝั่งเซิร์ฟเวอร์โอเค และอัปโหลดผ่านเว็บได้ไม่มีปัญหา แต่มีแอปเท่านั้นที่ไม่ได้ ยังหาสาเหตุไม่เจอ
กล่าวคือเป็นไปได้ทั้งสองรูปแบบ
https://github.com/ente/ente
บางทีมันอาจลดทอนจุดประสงค์ของการยืนยันตัวตนสองขั้นตอน แต่บางครั้งผมก็ไม่ได้ใส่ใจมากนัก
ไม่ต้องใช้แอป ง่ายมาก และราคาถูกมาก หลังจากนั้นก็เลยเริ่มใช้บริการสำรอง/เก็บถาวรรูปถ่ายด้วย
เป็นบริการที่เป็นอย่างที่เห็นภายนอกจริง ๆ เลยกลายเป็นแฟนไปแล้ว
Immich เป็นตัวเลือกที่เป็นธรรมชาติมากสำหรับแทนที่ Apple Photos หรือ Google Photos ถ้าใช้ร่วมกับ VPN อย่าง Tailscale ก็แทบจะเปลี่ยนแทนได้ตรง ๆ
https://github.com/immich-app/immich/discussions/14365
แค่อัปเดตเป็นประจำ ทำตามกฎง่าย ๆ และตั้งค่าอะไรอย่าง CrowdSec ก็พอ
ผมรู้ว่าการใช้เครื่องมืออย่าง Tailscale นั้นง่ายกว่า แต่ช่วงนี้เห็นแนวโน้มที่ไม่ค่อยพิจารณาตัวเลือกอื่นเลย
รูปของผมจัดไว้ประมาณ
events -> year/month - holiday -> (album_1, ...),home town -> year -> (album_1, ...)รูปสามารถอยู่ได้หลายอัลบั้ม มีเวอร์ชันที่แก้ไขแล้ว และต้องติดตามกับกรองสถานะเลือก/ปฏิเสธด้วย
เหตุผลเดียวที่ผมยังย้ายไป Immich ไม่ได้ คือยังลำบากกับการแมปวิธีจัดระเบียบรูปของผมเข้ากับวิธีของ Immich ให้ดูดี ความพยายามที่ผ่านมาใช้งานไม่สะดวกเลย
มีจุดที่ไม่พอใจมากกว่าการไม่มีการเข้ารหัสแบบ end-to-end อีก คือยังไม่ได้ทำให้การนำเข้าจากบริการอื่นอย่าง Google Photos หรือ iCloud เป็นเรื่องง่าย ซึ่งมองว่านี่ควรเป็นลำดับความสำคัญ
Immich พึ่งพาโปรเจกต์ immich-go แต่มีบั๊กเยอะและแทบจะถูกปล่อยทิ้งไว้
แอป iOS ของตัวเองก็ใช้ซิงก์แกลเลอรี iCloud ได้ แต่เพราะบั๊กที่ยังไม่แก้มาเกือบ 2 ปี ทำให้อัปโหลดภาพ Live Motion ไม่สำเร็จ
รูปที่ส่งออกไป Immich ราว 9,000 รูปเป็น Live Photos ที่เสียหรือถูกนำเข้าแค่ครึ่งเดียว และไม่มีเวลามาแก้
ไม่เข้าใจเลยว่าทำไมเรื่องนี้ถึงไม่ใช่ลำดับความสำคัญ ทั้งที่เป็นฟีเจอร์ที่ควรถูก A/B test อย่างละเอียดที่สุด
ถ้าเชื่อไม่ได้ว่าความทรงจำที่นำเข้ามาจะไม่ถูกทำพัง แล้ว OCR จะมีความหมายอะไร
การรับมือกับ export ที่พังครึ่ง ๆ กลาง ๆ ของ Google Photos คงไม่น่าสนุกสำหรับใคร และความเจ็บปวดจากการนำเข้าก็เกิดแค่ครั้งเดียว พอผ่านไปแล้วก็ไม่มีอาการคันที่ต้องเกาอีก
ตั้งค่า Immich โดยใช้ Ceph เป็นแบ็กเอนด์ แล้วใช้ immich-go ย้ายทั้งเมทาดาทาและอัลบั้มทั้งหมด
ต้องปรับตัวเลือกการทำงานแบบขนานนิดหน่อย แต่นอกนั้นง่ายมาก
มีหลายอย่างที่ใช้เวลาตั้งค่านานมาก ใช้ครั้งเดียวแล้วไม่ใช้ซ้ำ และก็มีหลายอย่างที่ตั้งค่าง่ายแต่ให้ประโยชน์เล็ก ๆ ทุกวัน
Immich ใช้เวลาตั้งค่านาน และได้ใช้ไม่บ่อยมาก แต่เป็นซอฟต์แวร์ที่ทุกครั้งที่ได้ใช้ปีละครั้ง จะรู้สึกจริง ๆ ว่าดีแล้วที่ติดตั้งไว้
ใช้ทุกสัปดาห์ และมันก็ทำงานได้ดีมาก เลยยอดเยี่ยม
เท่าที่จำได้อาจเกี่ยวกับการย้ายเวอร์ชันใหญ่ หลังจากนั้นก็หมดใจกับสแต็กนี้
การอัปเกรดไม่ได้ง่ายอย่างที่อยากให้เป็น และตอนนี้ก็คงไม่ได้ต่างมากนัก
แค่อยากจัดโฟลเดอร์นอกระบบไลบรารีงี่เง่า แต่ตอนนั้น Immich ก็ไม่เข้ากับวิธีนั้นเท่าไร
อยากรู้ว่า การซิงก์รูปบน iOS ดีขึ้นหรือยัง ในมือถือมีรูป 20,000 รูป ครั้งล่าสุดที่ลอง พื้นที่มือถือเต็มเพราะไฟล์ต้นฉบับ และแม้จะเปิดมือถือ ปลดล็อกไว้ เปิดแอป Immich ไว้ด้านหน้า บนเครือข่าย local เดียวกันหลายวัน ก็ยังไม่จบ
รู้ว่ากำลังทำเรื่องนี้อยู่ แต่ไม่ได้ตามต่อ อยากรู้ว่าตอนนี้ทำงานดีขึ้นจนคุ้มจะลองอีกครั้งหรือยัง
“บน iOS งาน background refresh ตอนนี้รันการซิงก์และอัปโหลดแบบขนานกันแล้ว ทำให้การอัปโหลดเริ่มขึ้นจริงภายในช่วงเวลาสั้น ๆ ที่ iOS อนุญาต”
แต่ไม่รู้ว่านี่แก้ปัญหานั้นหรือเปล่า
จำไม่ได้ว่าไฟล์ต้นฉบับถูกดาวน์โหลดมาหรือถูกลบอัตโนมัติหลังจากนั้นไหม แต่ทั้งกระบวนการรู้สึกลื่นไหล
iOS ไม่ได้ทำให้เรื่องนี้ง่ายผ่านการอัปโหลดเบื้องหลัง ผมเปิดแอปทิ้งไว้ทั้งคืนจนทุกอย่างอัปโหลดเสร็จ
สงสัยว่า “อัปโหลด asset ไปยังอัลบั้มโดยตรงจากแอปมือถือ” จะแก้ปัญหานี้หรือเปล่า: https://github.com/immich-app/immich/discussions/12748
สำหรับผมเป็นปัญหาใหญ่พอสมควร เพราะอยากให้หลายอุปกรณ์และหลายคนรวบรวมรูปแมวไว้ในอัลบั้มเดียว
ตอนนี้ต้องจัดโครงสร้างแบบนี้ ใช้ Syncthing ซิงก์รูปไปยัง
/mnt/Syncthing/a1/cats/,/mnt/Syncthing/a2/cats/,/mnt/Syncthing/b/cats/บนเซิร์ฟเวอร์ homelab ที่โฮสต์ Immichใช้ cron job คัดลอกแบบ hard link ไปยังโฟลเดอร์
/mnt/immich/ext-lib/cats/ซึ่งถูกเมานต์เป็นโวลุ่มไลบรารีภายนอกแบบอ่านอย่างเดียวแล้วใช้ cron job อีกตัวรันสคริปต์ https://github.com/Salvoxia/immich-folder-album-creator ที่สร้างอัลบั้มอัตโนมัติจากโครงสร้างโฟลเดอร์ของไลบรารีภายนอก
สุดท้ายรัน cron job เพื่อล้างรูปที่เก่ากว่า 1 ปีออกจากโฟลเดอร์ Syncthing เพื่อเพิ่มพื้นที่ในมือถือ ทั้งหมดมีประมาณ 1TB เลยมีปัญหาอยู่บ้าง
อย่างไรก็ยินดีกับรีลิส 3.0 ด้วย เพียงแต่เสียดายนิดหน่อย เพราะเพิ่งพบโปรแกรมนี้เมื่อเดือนก่อน และเพิ่งทำให้การตั้งค่า self-hosting เสถียรเมื่อสัปดาห์ที่แล้ว