กูปรีคืออะไร? และทำไมต้องเปรียบกับ CoPre2
กูปรี (Kouprey) คือวัวป่าขนาดใหญ่ที่เคยอาศัยอยู่ในบริเวณชายแดนไทย-กัมพูชา ปัจจุบันเชื่อว่าสูญพันธุ์ไปแล้ว ครั้งหนึ่งมันเคยเป็นสัตว์ที่แข็งแกร่งและน่าเกรงขาม ผมเลือกชื่อ “กูปรี” มาเปรียบกับ CoPre2 เพราะเสียงมีความพ้องคล้ายๆ โปรแกรมนี้มีความ “ใหญ่และแข็งแกร่ง” ในแง่ความสามารถ แต่ก็มีความไม่แน่นอนในอนาคต ว่าจะอยู่รอดในตลาดซอฟต์แวร์ที่มีการแข่งขันสูงได้นานแค่ไหน หรือจะสูญพันธุ์ตามกูปรีไปด้วยกัน (ฮา)
ภูมิหลัง: โครงการสำรวจสนามบิน 3 ครั้ง
ผมใช้ CoPre2 ในบริบทของโครงการก่อสร้างสนามบินขนาดใหญ่ที่ต้องการข้อมูล LiDAR ความแม่นยำสูงต่อเนื่องกัน 3 ครั้ง ดังนี้
- ครั้งที่ 1 (Pre-construction Survey): สำรวจด้วย CHCNav AA10 ทีมงาน CHC Navtech (Thailand) เป็นผู้ประมวลผลข้อมูลเอง ทีมงานผมช่วยงานด้านหมุดตรวจสอบ (Check Points) ในสนาม
- ครั้งที่ 2 (After Clearing Survey): สำรวจด้วย CHCNav AA9 เดือนกุมภาพันธ์ 2569 ล่าช้าเนื่องจากข้อจำกัดการบินโดรนในช่วงวิกฤตชายแดนไทย-กัมพูชา บินทั้งหมด 20 เที่ยวบิน ข้อมูลดิบขนาด 141 GB
- ครั้งที่ 3 (Progress Survey): สำรวจด้วย CHCNav AA9 เดือนมีนาคม 2569 จำกัดพื้นที่เฉพาะเขตก่อสร้าง บินทั้งหมด 8 เที่ยวบิน ข้อมูลดิบทั้งหมด 73 GB
CoPre2 คืออะไร?
CoPre2 (CoProcess2) คือซอฟต์แวร์ประมวลผลข้อมูล LiDAR และการถ่ายภาพทางอากาศที่พัฒนาโดย CHCNav บริษัทจีนที่ผลิตอุปกรณ์สำรวจและ LiDAR ระดับมืออาชีพ ออกแบบมาเพื่อทำงานคู่กับระบบ LiDAR ของ CHCNav โดยเฉพาะ เช่น AA9 และ AA10 ครอบคลุมกระบวนการตั้งแต่การประมวลผลเส้นทางการบิน (Trajectory/POS) ไปจนถึงการสร้าง Point Cloud, Strip Adjustment และ Orthomosaic (DOM)
ขั้นตอนการทำงาน (Workflow)
กระบวนการทำงานของ CoPre2 เป็นลำดับขั้นที่ชัดเจน ถ้าดูตามแถบเมนูจะเห็นไอคอนเรียงจากซ้ายไปขวาตามลำดับ ถ้าเริ่มด้วย Wizard โปรแกรมจะพาสร้างโปรเจคไปจนจบ ตั้งแต่สร้าง ตั้งค่าระบบพิกัด เลือกรูปแบบการคำนวณ, คำนวณ Trajectory, แสดงผล และตั้งค่าผลลัพธ์
ส่วนผมเองจะเลือกสร้างเอง (Create) ซึ่งโปรแกรมจะมาที่แถบ “Processing” ผมเองไม่ได้ใช้สถานีฐานจากคลาวด์ (Cloud Base) จึงข้ามมาที่ POS หรือ POS Solve แล้ว Data Solve ส่วนที่ผมไม่ได้ใช้ได้แก่ Link List, GCP Check และ GCP Adjust เนื่องจากผมไม่ได้ใช้ GCP ในการปรับแก้รูปออร์โธ
- POS Solve: ประมวลผล trajectory จากข้อมูล IMU และ GNSS ดิบ รองรับ Base Station แบบ HCN และ RINEX 3.02 มีทั้ง Loosely-coupled (เหมาะกับ Airborne) และ Tightly-coupled (เหมาะกับ Vehicle) โดยซอฟต์แวร์เลือกให้อัตโนมัติตามประเภทข้อมูล
- Data Solve: รวม POS เข้ากับข้อมูล LiDAR scan สร้าง Point Cloud พร้อม Colorization และ Orthomosaic ผลลัพธ์บันทึกในรูปแบบ .codata (รูปแบบเดียวที่รองรับ ไม่สามารถเปลี่ยนได้)
- Strip Adjust (Standalone): ปรับแก้ POS และ Point Cloud ระหว่าง Strip เพื่อลด layering phenomena สร้างผลลัพธ์ใหม่ใน ADJUST folder พร้อม Accuracy Report
- GCP Adjust: ปรับ Absolute accuracy ด้วย Ground Control Points มี 3 โหมด ได้แก่ Refine Position, Refine Point Cloud (interpolation), และ Refine Point Cloud (overall offset)
- Export Results: Export ออกเป็น LAS, LAZ, E57 หรือ PTS ตามต้องการ
Strip Adjust: ทำไมถึงมีสองแบบ?
นี่คือจุดที่ทำให้ผมสับสนในตอนแรก และเป็นเรื่องที่คู่มือ CoPre2 อธิบายไว้ไม่ชัดเจนเท่าที่ควร
Strip Adjust (ภายใน Data Solve)
เป็นตัวเลือกเล็กๆ ที่ฝังอยู่ภายใน Data Solve Settings คู่มืออธิบายสั้นมากว่า “primarily used to improve the accuracy of point cloud data and data layering phenomena” และระบุว่าใช้ได้กับ “specific equipment data” เท่านั้น ทำงานเป็นส่วนหนึ่งของ Pipeline Data Solve
Strip Adjust (Standalone — หลัง Data Solve)
นี่คือกระบวนการที่แตกต่างกันอย่างสิ้นเชิง มีความสามารถเต็มรูปแบบ ได้แก่
- แก้ไข POS โดยตรง — เลือกได้ว่าจะ Change Attitude อย่างเดียว หรือ Change Position AND Attitude
- ใช้ระบบ Link List เพื่อวัดและแก้ไขความคลาดเคลื่อนระหว่าง Strip อัตโนมัติ (Automatic) หรือกึ่งอัตโนมัติ (Semi-automatic)
- รองรับการปรับหลายโปรเจกต์พร้อมกัน (Multi-project Strip Adjust)
- สร้าง Accuracy Report แสดง Error ก่อนและหลังการปรับแก้
- บันทึกผลลัพธ์ใน ADJUST folder แยกต่างหาก
สำหรับงานโครงสร้างพื้นฐานระดับสนามบิน การทำ Strip Adjust แบบ Standalone นั้น จำเป็นอย่างยิ่ง ผมทำทั้งสองขั้นตอนและได้ผลลัพธ์ที่ดี
UI/UX: ใช้งานง่าย แต่มีจุดสะดุด
โดยรวมแล้ว Interface ของ CoPre2 ออกแบบมาได้ดี เมนูและขั้นตอนการทำงานเป็นระเบียบ ไม่ซับซ้อนเกินไปสำหรับผู้ใช้ที่มีพื้นฐานด้านการสำรวจหรือ GIS อย่างไรก็ตาม มีจุดบกพร่องที่ทำให้สะดุดในตอนแรก
⚠️ ปัญหา Write EXIF: CoPre2 ไม่ได้ติ๊กตัวเลือก “Write EXIF” ไว้ให้โดยอัตโนมัติ ผู้ใช้ต้องเข้าไปที่ Pictures Processing → Advanced Settings แล้วติ๊กเองด้วยตนเอง หากลืมติ๊ก ภาพถ่ายที่ได้จะไม่มีข้อมูลพิกัด GPS ซึ่งส่งผลโดยตรงต่อการนำภาพไปใช้ใน Agisoft Metashape หรือซอฟต์แวร์ Photogrammetry อื่นๆ
คู่มือ CoPre2 (มิถุนายน 2568) ระบุชัดเจนว่า “Write EXIF: Not checked by default” — นี่คือการออกแบบโดยตั้งใจ ไม่ใช่ Bug แต่เป็นการออกแบบที่ไม่ค่อยเหมาะสม เพราะผู้ใช้แทบทุกคนต้องการ EXIF พิกัดในไฟล์ภาพ ตัวเลือกนี้ควรถูกเปิดเป็น Default
ความแม่นยำ: เกินความคาดหมาย
นี่คือจุดแข็งที่ชัดเจนที่สุดของ CoPre2 ในโปรเจกต์สนามบิน ค่าความผิดพลาดที่หมุดตรวจสอบ (Check Points) ได้ผลดังนี้
- ความแม่นยำแนวดิ่ง (Vertical): 1–2 เซนติเมตร
ผลลัพธ์ระดับนี้ถือว่าเกินความคาดหมายและผ่านเกณฑ์ได้อย่างสบาย ผมประหลาดใจเพราะว่า check point จุดเดิม เมื่อมาตรวจสอบค่า Error กลับได้ค่า Error เท่ากันจากสองงานบินสำรวจที่ต่างกันหนึ่งเดือน
การทำ Strip Adjust แบบ Standalone หลัง Data Solve มีส่วนสำคัญในการได้ผลลัพธ์ที่ดีเยี่ยมนี้ ผมแนะนำให้ทำเสมอสำหรับงานที่ต้องการความแม่นยำสูง
ประสิทธิภาพและความเร็ว
ด้านความเร็วในการประมวลผล CoPre2 ให้ผลที่น่าประทับใจ โดยเฉพาะการสร้าง DOM/Orthomosaic ที่เร็วกว่า Agisoft Metashape อย่างเห็นได้ชัด สำหรับผู้ที่เคยรอ Metashape ประมวลผลภาพจำนวนมากจะเข้าใจว่านี่คือข้อได้เปรียบที่สำคัญในการทำงานภาคสนามที่มีเวลาจำกัด
CoPre2 ยังมีตัวเลือก Sampling Rate 4 ระดับ ได้แก่ 100%, 75%, 50% และ 25% (ค่า Default คือ 100%) ซึ่งส่งผลโดยตรงต่อเวลาประมวลผลและพื้นที่จัดเก็บ
ปัญหาพื้นที่จัดเก็บ: ความท้าทายที่ไม่มีใครบอก
ตัวคูณพื้นที่จาก Pipeline
ไฟล์ระหว่างการประมวลผลของ CoPre2 บันทึกในรูปแบบ .codata ซึ่งคู่มือระบุว่าเป็น “currently, there is only one option, codata, which cannot be changed” — ไม่มีทางเลือก ไม่สามารถเปลี่ยนได้ และรูปแบบนี้มีขนาดใหญ่มากเมื่อเทียบกับ LAS/LAZ มาตรฐาน ข้อมูลจริงจากโปรเจกต์ของผม
| การสำรวจ | Sampling | Raw Data | หลัง Process | ตัวคูณ | หมายเหตุ |
| ครั้งที่ 2 (After Clearing) | 100% | 141 GB | SSD เต็ม ❌ | — | ต้องลบและคำนวณใหม่ |
| ครั้งที่ 2 (ทำใหม่) | 50% | 141 GB | 738 GB | 5.2× | แก้ปัญหา SSD เต็ม |
| ครั้งที่ 3 (เขตก่อสร้าง) | 100% | 73 GB | 334 GB | 4.6× | จำกัดพื้นที่เฉพาะเขตก่อสร้าง |
ยิ่งไปกว่านั้น ทุกครั้งที่ทำ Strip Adjust หรือ GCP Adjust CoPre2 จะสร้าง ADJUST folder ใหม่ทั้งชุด ไม่ได้เก็บเฉพาะค่าที่แก้ไข แต่คัดลอกข้อมูลทั้งหมดออกมา ทำให้ Pipeline เต็มรูปแบบ (Raw + Results + Adjust + GCP Adjust) อาจต้องการพื้นที่ถึง 8–10 เท่าของ Raw data
บทเรียนราคาแพง: SSD เต็มกลางโปรเจกต์
ในการสำรวจครั้งที่สอง (20 เที่ยวบิน, Raw 141 GB) ผมพยายาม Process ที่ Sampling 100% แต่ SSD เต็มกลางคัน ต้องลบไฟล์ทั้งหมดแล้วเริ่มใหม่ด้วย Sampling 50% — เสียเวลาไปมาก การวางแผนพื้นที่จัดเก็บก่อน Process จึงสำคัญมาก
กฎง่ายๆ สำหรับการวางแผน SSD
- คำนวณพื้นที่ขั้นต่ำ: Raw × 5 สำหรับ Data Solve เพียงขั้นเดียว
- คำนวณพื้นที่เต็ม Pipeline: Raw × 8–10 หากต้องทำ Strip Adjust และ GCP Adjust
- สำหรับ Raw 73 GB → เตรียม SSD ว่างอย่างน้อย 400–500 GB
- สำหรับ Raw 141 GB → เตรียม SSD ว่างอย่างน้อย 800 GB – 1.4 TB
- การจำกัดพื้นที่สำรวจ (เช่น เฉพาะ Construction Zone) ช่วยลดขนาดได้มาก
กลยุทธ์การจัดการข้อมูล: Tiered Archiving
เมื่อ Process เสร็จแล้ว ผมย้ายข้อมูลไปยัง NAS ที่ออฟฟิศ และเตรียม SSD ใหม่สำหรับโปรเจกต์ถัดไป เนื่องจาก NAS มีพื้นที่จำกัด (เหลือประมาณ 5 TB) ผมจึงวางแผนการ Archive แบบ 2 ระดับ
| ระดับ | ที่เก็บ | ข้อมูล | กลยุทธ์ |
| Tier 1 | SSD (งาน) | Raw + Pipeline ทั้งหมด | ใช้ขณะ Processing เท่านั้น ลบหลังส่งงาน |
| Tier 2A | NAS (Archive ทั่วไป) | DOM, Point Cloud, Ground Points, DEM | เก็บเฉพาะผลลัพธ์สุดท้าย ประหยัดพื้นที่ |
| Tier 2B | NAS (Archive สำคัญ) | Raw + ผลลัพธ์ทั้งหมด | สำรวจที่มีนัยสำคัญทางกฎหมาย/สัญญา flag ว่า “important” |
ข้อควรระวัง: หากเก็บเฉพาะผลลัพธ์สุดท้ายโดยไม่เก็บ Raw data และ .codata ไว้ จะไม่สามารถ Re-process ได้ในภายหลัง หากพบข้อผิดพลาดด้าน Coordinate System หรือมีข้อพิพาทด้านความแม่นยำจากลูกค้า การตัดสินใจ flag ว่า “important” ต่อแต่ละการสำรวจจึงต้องพิจารณาให้รอบคอบ
สรุปข้อดีและข้อเสีย
| ✅ ข้อดี | ❌ ข้อเสีย / ข้อควรระวัง |
| ความแม่นยำ Check Point ระดับ 1–2 ซม. ทั้ง H และ V | Write EXIF ไม่ได้ถูกเปิดเป็น Default ต้องติ๊กเองทุกครั้ง |
| DOM/Orthomosaic เร็วกว่า Agisoft Metashape อย่างเห็นได้ชัด | Format ระหว่าง Process ล็อคเป็น .codata เท่านั้น ไม่สามารถเปลี่ยนได้ |
| UI/UX เข้าใจง่าย Workflow เป็นระเบียบ | ตัวคูณพื้นที่ประมาณ 4.5–5× จาก Raw data (ก่อน Strip Adjust) |
| Strip Adjust แบบ Standalone ทรงพลัง แก้ layering ได้ดี | แต่ละ Strip Adjust/GCP Adjust สร้าง ADJUST folder ใหม่ทั้งชุด |
| รองรับหลายรูปแบบ Export: LAS, LAZ, E57, PTS | Pipeline เต็ม (Raw+Results+Adjust) อาจต้องการพื้นที่ 8–10× ของ Raw |
| มี Accuracy Report หลัง Strip Adjust ทุกครั้ง | Strip Adjust ใน Data Solve (8.3.3.4) กับ Standalone (8.4) อธิบายในคู่มือไม่ชัดเจน |
บทสรุป: กูปรีที่แข็งแกร่ง แต่อนาคตยังไม่แน่นอน
CoPre2 เป็นซอฟต์แวร์ที่น่าประทับใจสำหรับผู้ใช้ระบบ LiDAR ของ CHCNav ความแม่นยำระดับ 1–2 ซม. ทั้ง H/V และความเร็วในการสร้าง DOM คือจุดเด่นที่ทำให้ต้องพูดถึง
แต่ปัญหาพื้นที่จัดเก็บ รูปแบบ .codata ที่ล็อคไว้ และการสร้าง ADJUST folder ซ้ำทุกขั้นตอน ทำให้ต้นทุน Infrastructure ด้าน Storage สูงกว่าที่หลายคนคาดไว้มาก ผู้ที่จะนำ CoPre2 ไปใช้งานควรวางแผน SSD และระบบ Archive ให้ดีก่อนเริ่มโปรเจกต์
สิ่งที่น่าจับตามองคือการแข่งขันจากตลาด เพราะปัจจุบัน DJI Zenmuse L3 มีราคาประมาณ 1 ล้านบาท เทียบกับ DJI M350 RTK + AA9 ที่ประมาณ 1.6 ล้านบาท ความแตกต่างของราคา 6 แสนบาทพร้อม Ecosystem ที่แข็งแกร่งของ DJI จะเป็นแรงกดดันต่อ CHCNav และ CoPre2 ในระยะยาว
กูปรีนั้นแข็งแกร่งมากในยุคของมัน แต่สุดท้ายก็สูญพันธุ์ไป CoPre2 จะเอาชีวิตรอดได้หรือไม่ในตลาดที่มีการแข่งขันสูงในสายน้ำที่แรงและเชี่ยวกรากเช่นนี้ ขึ้นอยู่กับว่า CHCNav จะพัฒนาและดูแลซอฟต์แวร์นี้ต่อไปอีกนานแค่ไหน เอาใจช่วยครับ
นอกจาก CoPre2 แล้วจะมี CoProcess2 มาคู่กัน ส่วน CoProcess2 ที่ผมยังไม่กล่าวถึงในที่นี้เป็นซอฟท์แวร์ที่นำ point cloud จาก CoPre2 มาประมวลผลต่อเช่นการ Filtering, การ Classify และอื่นๆอีกหลายอย่าง โปรดติดตามตอนต่อไปครับ