ทำภาพข้อมูลหนังสือทั้งหมดในโลกบน ISBN-Space
(phiresky.github.io)- เพื่อให้สำรวจข้อมูลหนังสือมากกว่า 100 ล้านเล่ม ที่ Anna’s Archive ดูแลอยู่ได้บนหน้าจอเดียว จึงต้องเปลี่ยนพื้นที่ตัวระบุที่มีขอบเขตจำกัดอย่าง ISBN ให้กลายเป็นแผนที่
- ISBN13 เมื่อตัดคำนำหน้า
978-/979-และเลขตรวจสอบตัวสุดท้ายออก จะเป็นพื้นที่หนึ่งมิติที่มีประมาณ 2 พันล้านช่อง และมีการจัดสรรตามช่วงของประเทศและสำนักพิมพ์ในระดับคำนำหน้า - การวางแบบเรียงตามแถวหรือใช้ Hilbert curve อาจทำให้มองโครงสร้างของ ISBN ได้ยาก จึงใช้ Bookshelf-Curve ที่ย้ายหลักเลขฐานสิบไปเป็นพิกัด 2D
- ไทล์แผนที่ถูกให้บริการเป็นไฟล์สแตติก PNG และ JSON โดยมี WebGL/GLSL shader จัดการ การเรนเดอร์และการกรอง เช่น ปีที่พิมพ์ สัดส่วนการมีอยู่ การเปรียบเทียบชุดข้อมูล และการเน้นสำนักพิมพ์ ได้ทันที
- ถูกสร้างเป็นฟรอนต์เอนด์แบบสแตติกบนพื้นฐานของ ThreeJS, React, MobX และ react-threejs-fiber โดยประสิทธิภาพของการเรนเดอร์ข้อความจำนวนมากและการซูม/เลื่อน เป็นตัวชี้ขาดการใช้งานจริง
เหตุผลที่เลือกพื้นที่ ISBN มาเป็นเป้าหมายของการทำภาพข้อมูล
- ห้องสมุดได้รวบรวมความรู้ของมนุษยชาติมาเป็นเวลานาน และในยุคดิจิทัลก็อาจเป็นไปได้ที่จะเก็บรวบรวมงานเขียนที่ตรงตามเกณฑ์บางอย่างอย่างครอบคลุม
- Anna’s Archive ซึ่งเป็นหนึ่งใน shadow library ต้องการการแสดงภาพที่ทำให้สำรวจหนังสือมากกว่า 100 ล้านเล่ม ได้ในครั้งเดียว
- ข้อมูลที่นำมาใช้มีทั้งชื่อเรื่อง ผู้เขียน ประเทศ สำนักพิมพ์ ช่วงเวลาที่ตีพิมพ์ จำนวนห้องสมุดที่ถือครอง และการเข้าถึงแบบดิจิทัล
- ภาพข้อมูลแบบอินเทอร์แอกทีฟ รองรับการเลือกชุดข้อมูล การค้นหาหนังสือรายเล่ม การกรองตามปีที่พิมพ์ และการสร้างภาพผสมด้วย custom shader
- เมื่อซูมเข้าไปมากที่สุด การแสดงผลจะเปลี่ยนให้ดูเหมือนหนังสือที่วางอยู่บนชั้นหนังสือ
โครงสร้างของ ISBN
- ISBN13 คือ หมายเลข 13 หลัก ที่กำหนดให้กับหนังสือที่ตีพิมพ์เกือบทั้งหมด
- ปัจจุบันเลขสามหลักแรกของ ISBN13 ถูกตรึงไว้ที่
978-หรือ979-และหลักสุดท้ายคือ checksum - ดังนั้นพื้นที่ ISBN13 จริงจึงมองได้ว่าเป็นประมาณ 2 พันล้านช่อง
- คำนำหน้า
978-และ979-มีโครงสร้างแบบนี้เพราะ ISBN13 เป็นส่วนย่อยของ European Article Number และคำนำหน้าคงที่นี้ถูกเรียกว่า Bookland - บล็อก ISBN ขนาดใหญ่ถูกจัดสรรโดย International ISBN Agency ให้แก่องค์กรระดับนานาชาติ และแต่ละประเทศก็แบ่งบล็อกของตนต่อในระดับสำนักพิมพ์
- บล็อก ISBN จะถูกจัดสรรเป็นหน่วยของ คำนำหน้า (prefix) เสมอ
978-4ถูกจัดสรรให้ญี่ปุ่น- ญี่ปุ่นจัดสรร
978-4-312ให้สำนักพิมพ์แห่งหนึ่ง - สำนักพิมพ์นั้นสามารถจัดสรรรายการในช่วง
000000-99999เพื่อสร้าง ISBN อย่าง978-4-312-99999-Xได้
- ยิ่งคำนำหน้าประเทศยาว จำนวนหนังสือที่จัดสรรได้ภายในก็ยิ่งน้อยลง
- ญี่ปุ่นมีพื้นที่ ISBN 100 ล้านรายการ
- สิงคโปร์เริ่มด้วยคำนำหน้า
978-9971-จึงมีได้เพียง 100,000 ISBN
วิธีคลี่ ISBN แบบหนึ่งมิติให้ออกมาเป็นสองมิติ
- เมื่อตัดคำนำหน้า
978-/979-และ checksum ออก ISBN จะกลายเป็นค่าแบบหนึ่งมิติในระบบเลขฐานสิบระหว่าง 0 ถึง 2 พันล้าน - วิธีที่ง่ายที่สุดคือเติมพิกเซลจากด้านบนลงมาเป็นแถว ๆ แต่จะทำให้พื้นที่เล็ก ๆ ถูกยืดออกตามแนวนอนมากเกินไปจนมองโครงสร้างของ ISBN ได้ยาก
- Hilbert curve ทำให้พื้นที่เล็ก ๆ มีลักษณะใกล้สี่เหลี่ยมจัตุรัสมากขึ้น แต่ก็อาจสร้าง spatial structure artifact ที่ไม่มีอยู่จริงในข้อมูล
- เพื่อหลีกเลี่ยงโครงสร้างที่ไม่ได้อยู่ในข้อมูลจริง การทำภาพข้อมูลนี้จึงใช้ Bookshelf-Curve ที่อาศัยธรรมชาติของตัวเลขฐานสิบใน ISBN
Bookshelf-Curve
- Bookshelf-Curve วาง
0-9ของหลักฐานสิบตัวแรกในแนวนอน แล้ววาง0-9ของหลักถัดไปในแนวขึ้นลง และทำซ้ำแบบเวียนเกิดเช่นนี้ - เพื่อรักษาสัดส่วนของสี่เหลี่ยมผืนผ้าทั้งสองชั้น อัตราส่วนกว้างยาวของแต่ละบล็อกจึงเป็น
√10หรือประมาณ 3.16:1 - โครงสร้างนี้คล้ายแนวคิดเรื่องอัตราส่วนแบบเวียนเกิดของกระดาษ A4 แต่แทนที่จะแบ่งเป็นสองส่วน ก็แบ่งเป็น 10 ช่วง
- การแปลงพิกัดทำได้ง่าย เพราะใช้เลขแต่ละหลักของ ISBN สลับกันไปเป็นพิกัด
- โค้ดฝั่งติดตั้งจริงกลายเป็น 50 บรรทัด เพราะมีความพยายามทำให้ทั่วไปมากขึ้น แต่หลักการเข้าใจได้ง่ายพอที่จะไล่หาตำแหน่งของ ISBN แบบทำมือได้
ไทล์แผนที่และการเข้ารหัสข้อมูล
- มีการสร้าง ภาพไทล์ สำหรับแต่ละคำนำหน้า ISBN
- ขนาดเป้าหมายของไทล์อยู่ที่ประมาณ
100kBและผลลัพธ์คือไทล์ขนาด2000 × 633พิกเซล - ข้อมูลที่เก็บในพิกเซลจะแตกต่างกันไปตามแต่ละชุดข้อมูล
- ชุดข้อมูลปีที่พิมพ์จะเก็บค่าโดยนำ
1800ออกก่อนเพื่อให้อยู่ในช่วง 8 บิต - ช่องสีแดงเก็บค่าเฉลี่ยปีที่พิมพ์ของหนังสือภายในพิกเซลนั้น
- ช่องสีน้ำเงินเก็บสัดส่วนของหนังสือที่มีอยู่จริง
- ตัวอย่างเช่น ถ้ามีหนังสืออยู่ 50% ค่าช่องสีน้ำเงินจะเป็น
127/255
- ชุดข้อมูลปีที่พิมพ์จะเก็บค่าโดยนำ
- ที่ระดับการซูมสูงสุด จะจับคู่ หนังสือ 1 เล่มต่อ 1 พิกเซล เพื่อความแม่นยำ
การเรนเดอร์ด้วย GLSL shader
- ในตอนแรกมีการเก็บข้อมูล RGB ลงในไทล์โดยตรง แต่เพื่อเพิ่มความยืดหยุ่น จึงเปลี่ยนไปเก็บข้อมูลในรูปแบบที่เป็นนามธรรมมากขึ้น และให้การเรนเดอร์จริงทำใน GLSL fragment shader บน GPU
- วิธีนี้ทำให้เลือก color scale ภายหลังได้ ใช้การแปลงและตัวกรองแบบกำหนดเองได้ทันที และผสมหลายชุดข้อมูลเข้าด้วยกันแบบสด ๆ ได้
- ข้อมูลปีที่พิมพ์เก็บช่วง
1800-2055แต่ 95% ของข้อมูลอยู่ในช่วง1985-2024จึงสามารถย่อมาช่วงนี้ใน shader เพื่อแสดงผลได้ - ฟังก์ชัน
heatmapColor(float)ใช้แปลงค่า0-1ไปเป็น color scale ที่ผู้ใช้เลือก - ไวยากรณ์
$dataset_xไม่ใช่ไวยากรณ์ของ GLSL เอง แต่เป็นไวยากรณ์เทมเพลตอย่างง่ายที่อิง regex เพื่อโหลดเฉพาะภาพที่ shader จะอ่านจริง - ในตัวเลือก ⚙️ Advanced ของภาพข้อมูล ผู้ใช้สามารถแก้ไข shader ได้โดยตรง และผลลัพธ์จะสะท้อนแบบเรียลไทม์
- ความหมายของแต่ละพิกเซลในแต่ละชุดข้อมูลถูกรวบรวมไว้ใน README
การทำให้ดูเหมือนชั้นหนังสือเมื่อซูมเข้า
- ในมุมมองที่ซูมสุด แต่ละพิกเซลจะถูกตกแต่งให้ดูเหมือนหนังสือ
- หนังสือแต่ละเล่มจะมีความกว้าง ความสูง และลวดลายแบบสุ่ม
- แม้จะไม่เหมือนรูปร่างหนังสือจริงทุกอย่าง แต่ช่วยให้หน้าจอที่ซูมสุดดูมีชีวิตชีวามากขึ้น
- การตกแต่งนี้ทั้งหมดทำใน shader
- เพราะต้องการผลการสุ่มที่เหมือนกันทั้งใน GLSL และ JavaScript ส่วนที่คำนวณความสูงหนังสือเพื่อให้ขอบเขตข้อความพอดีกันจึงค่อนข้างยาก
- ถ้าส่งค่าการซูมปัจจุบันเป็น uniform และค่อย ๆ fade-in ระหว่างสองระดับการซูม ก็จะทำให้สไตล์ชั้นหนังสือปรากฏอย่างนุ่มนวลได้
ข้อความ โครงสร้างต้นไม้ และประสิทธิภาพ
- เช่นเดียวกับภาพไทล์ ข้อความก็ถูกเรนเดอร์แบบ ลำดับชั้น ตามระดับการซูมและการคัดออกตาม view frustum
- การติดตั้งใช้ react-threejs-fiber
- React จะเพิ่มองค์ประกอบของฉากแบบเวียนเกิดเมื่อเลื่อนมุมมอง โดยสำหรับแต่ละคำนำหน้าจะมี Plane, ข้อความ HTML และโหนดคำนำหน้าลูก
- ในช่วงแรกมีปัญหาด้านประสิทธิภาพอย่างมากเมื่อเรนเดอร์ข้อความจำนวนมาก
- แนวทางที่ดีที่สุดคือใส่ HTML ลงใน
<foreignObject />ของ SVG จากนั้นเรนเดอร์ลงบน canvas ด้วยdrawImageแล้วโหลดเป็น texture - วิธีนี้ใช้งานได้ แต่ในกระบวนการเรนเดอร์จะเกิด ความหน่วง 20ms แบบ synchronous ทุกครั้ง
- เนื่องจากไม่สามารถวาด SVG ใน WebWorker ได้ จึงย้ายส่วนนี้ไป WebWorker ได้ยาก
- ปัญหาด้านประสิทธิภาพจริง ๆ ส่วนใหญ่แก้ได้ด้วยการลดจำนวนองค์ประกอบ HTML จำกัด DOM content ที่ถูกเพิ่มต่อเฟรม และโดยเฉพาะการเอา CSS filter stack ของ
text-shadowออก
บาร์โค้ดและช่วงของสำนักพิมพ์
- เมื่อซูมสูงสุด หนังสือแต่ละเล่มจะแสดง บาร์โค้ด
- บาร์โค้ดถูกเพิ่มเข้ามาเพื่อเน้นแนวคิดว่าหนังสือถูกจัดเรียงตามลำดับ ISBN
- แทนที่จะใช้ไลบรารีเรนเดอร์บาร์โค้ด มีการใช้ฟอนต์ TTF Libre Barcode ที่สามารถเรนเดอร์ตัวเลข 13 หลักเป็นบาร์โค้ดและคำนวณ check digit ได้ด้วย
- ด้วยการปรับแต่งประสิทธิภาพการเรนเดอร์ข้อความของระบบปฏิบัติการ วิธีนี้จึงสะดวกและมีประสิทธิภาพดี
- แต่ละกลุ่มมักเป็นช่วงขนาดใหญ่ในระดับประเทศ และสำนักพิมพ์คือช่วงที่เล็กกว่าภายในนั้น
- ทั้งกลุ่มและสำนักพิมพ์จะได้รับสีสุ่มเฉพาะของตนเอง
- แม้สำนักพิมพ์หนึ่งจะมีหลายช่วง ก็ยังใช้สีเดียวกัน
- เพื่อเน้นทุกช่วงพร้อมกัน จึงกำหนด ID เฉพาะให้แต่ละสำนักพิมพ์และเก็บไว้ในรูปแบบคอมโพเนนต์ RGB
- สีของสำนักพิมพ์ยังมีจุดที่ยังไม่น่าพอใจอยู่
- สีของสำนักพิมพ์ชนกับ color scale ของ heatmap
- ช่วงระดับประเทศมองเห็นได้ยาก
การย้ายตำแหน่งจากการค้นหาและเส้นทางการบิน
- เมื่อค้นหาหนังสือหรือคลิก minimap ระบบจะ บินเลื่อนไป ยังตำแหน่งนั้น
- การคำนวณเส้นทางการบินให้ดูดีนั้นยากกว่าที่คิด
- การฟิตเส้นพาราโบลาให้ผลลัพธ์ธรรมดา ๆ จึงมีการลองแนวทางที่ใช้ปริภูมิแปลงอีกแบบหนึ่ง
- ผลลัพธ์สุดท้ายยังไม่สมบูรณ์ และใช้โค้ดถึงประมาณ 500 บรรทัด จนดูเหมือนออกแบบเกินความจำเป็นอยู่บ้าง แต่ก็ทำงานได้ดีกว่าวิธีเดิม
สถาปัตยกรรมและ pipeline การประมวลผล
- ไม่จำเป็นต้องมีแบ็กเอนด์
- ภาพไทล์ถูกเก็บเป็น PNG
- ต้นไม้ข้อมูลถูกเก็บเป็น JSON
- เพียงอัปโหลด HTML, JS, CSS, PNG, JSON ไปยังโฮสต์ไฟล์สแตติกอย่าง GitHub Pages ก็เพียงพอ
- ฟรอนต์เอนด์ใช้ ThreeJS, React และ MobX
- ชุดเทคโนโลยีนี้สะดวกสำหรับการสร้างฉาก 2D/3D แบบ reactive เชิงประกาศที่เร่งด้วย GPU ด้วยคอมโพเนนต์ที่นำกลับมาใช้ได้
- สคริปต์ประมวลผลส่วนใหญ่เขียนด้วย JS และส่งออก JSON กับ PNG โดยตรง
- บางสคริปต์ต้องอ่าน ไฟล์ต้นทาง 250GB และส่งออกเป็น SQLite จึงเขียนด้วย Rust
ผลลัพธ์และโค้ด
- ผลลัพธ์ที่ได้คือวิธีทำภาพข้อมูลหนังสือที่ตีพิมพ์ซึ่งมี ISBN อย่างยืดหยุ่น
- โปรเจกต์นี้เป็นไปได้เพราะ ISBN ถูกออกแบบให้มีขนาดเล็กพอแบบเฉียด ๆ สำหรับพื้นที่ตัวระบุ
- หากทำแบบเดียวกันกับ UUID พื้นที่ส่วนใหญ่คงกลายเป็นความว่างเปล่าขนาดมหาศาล
- ซอร์สโค้ดเปิดเผยไว้ที่ isbn-visualization
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ตอนเริ่มทำ Amazon ผมอยากทำอะไรแบบนี้เป๊ะเลย แต่แทนที่จะใช้ ISBN ตั้งใจจะใช้ การจัดหมวดหมู่ 3 ชั้นของ Library of Congress
ท้ายที่สุด ผู้ให้ข้อมูลอย่าง Baker & Taylor และ Books In Print ดันรวมการจัดหมวดหมู่ 3 ชั้นให้เป็นสตริงเดียวจนไม่สามารถหาขอบเขตได้อย่างเสถียร และต้องล้มเลิกไปก่อนจะเริ่มได้จริง ๆ
การทำการสำรวจแบบ “บินผ่าน” แบบนี้บน เว็บ รุ่นปี 1994~1995 ก็คงไม่ง่ายแน่ ๆ เป็นงานที่เจ๋งมาก
ผมเคยดู LoC Classification กับ LoC Subject Headings อยู่พอสมควร แต่น่าเสียดายที่ทั้งสองอย่างไม่ได้เปิดให้ใช้อย่างเสรีในรูปแบบที่เครื่องอ่านได้และเป็นประโยชน์ ส่วน PDF ยังพอใช้วิธีลัดบางอย่างได้
โดยเฉพาะส่วนกฎหมายของรัฐ (state law) ใน Classification นั้น ความหนาแน่นของการจัดหมวดหมู่แต่ละรัฐไม่สม่ำเสมอมาก เท่าที่จำได้ NY กับ CA ซับซ้อนโดดเด่นมาก และ PA เป็นอันดับสามที่ลดลงมาหน่อย ส่วนรัฐ “flyover” หลายรัฐนั้นเรียบง่ายจนแทบขำและคล้ายกันมาก เรื่องนี้ดูเหมือนสะท้อนความซับซ้อนของกฎหมายลายลักษณ์อักษร ระเบียบข้อบังคับ และกฎหมายจากคำพิพากษาของแต่ละรัฐ
อีกข้อเท็จจริงทางประวัติศาสตร์ที่น่าสนใจคือ ระบบการจัดหมวดหมู่และการแบ่งระดับบนสุดตามตัวอักษรดูเหมือนจะมาจากห้องสมุดส่วนตัวของ Thomas Jefferson ซึ่งเป็นต้นกำเนิดของ LoC โดยตรง
ถ้าสนใจ ในรายงานประจำปีที่ Librarian of Congress ยื่นต่อรัฐสภาซึ่งอยู่ใน Hathi Trust มีข้อมูลมากมายเกี่ยวกับประวัติการพัฒนาและการขยายของ Classification
Classification: <https://www.loc.gov/catdir/cpso/lcco/>
Subject headings: <https://id.loc.gov/authorities/subjects.html>
Annual reports — Recent: <https://www.loc.gov/about/reports-and-budgets/annual-reports...> / คลังประวัติศาสตร์ถึงราวปี 1866: <https://catalog.hathitrust.org/Record/000072049>
เป็นหนึ่งในบริษัทที่ล้าหลังทางเทคนิคที่สุดเท่าที่เคยทำธุรกิจด้วย และจนถึงตอนปิดบัญชีช่วงต้นปี 2020 ก็ยังจัดการใบสั่งซื้อและการชำระบัญชีด้วยกระดาษ, PDF และอีเมลอยู่เลย ครั้งหนึ่งเหมือนจะเคยให้ส่งเอกสารทางแฟกซ์ด้วยซ้ำ
กรณีที่ ISBN ถูก กำหนดซ้ำ ให้กับหนังสือต่างเล่มนั้นไม่ใช่เรื่องหายาก [0] ดังนั้นคำว่า “หนังสือทั้งหมดในพื้นที่ ISBN” อาจเป็นการพูดเกินจริง
อีกทั้งยังมีหนังสือที่มี ISBN ผิด ซึ่งตัวเลขตรวจสอบไม่ตรงกับ ISBN ส่วนที่เหลือด้วย หากแก้ตัวเลขตรวจสอบแล้วดันไปตรงกับหนังสืออีกเล่ม ก็จะไปอยู่ข้างนอกพื้นที่ ISBN ตามที่บทความบล็อกสมมติไว้
[0] https://scis.edublogs.org/2017/09/28/the-dreaded-case-of-dup...
ตอนดู ISBN ที่ต่ำที่สุดเท่าที่รู้ของสำนักพิมพ์เช็ก มีสีอื่นโผล่มา และ https://books.google.cz/books?vid=ISBN9788000000015&redir_es... ดูเหมือนไม่ใช่ ISBN ที่ถูกต้อง :-) แต่ก็ไม่รู้ว่าหนังสือเล่มนั้นมี ISBN ปลอมแบบโจ่งแจ้งอยู่จริง ๆ หรือเป็นข้อผิดพลาดของข้อมูล Google Books
เป็นการนำเสนอที่น่าประทับใจ
แต่หน้าจอนี้ไม่ได้สะท้อนแค็ตตาล็อก ISBN ทั้งหมด แสดงเฉพาะ สิ่งที่ Anna's Archive มีอยู่ เท่านั้น ด้วยอคติในการรวบรวมของ Anna จึงเห็นความเอนเอียงไปยังช่วงภาษาบางกลุ่ม และบริเวณที่แสดงเป็นสีดำคือรายการที่ไม่มีในคลัง
ฐานข้อมูลเมทาดาทามาจากหลายแหล่ง และเท่าที่รู้ก็ค่อนข้างสมบูรณ์ สีดำส่วนใหญ่น่าจะเป็นบริเวณที่ไม่มีหนังสือถูกกำหนดไว้
เจ๋งมากจริง ๆ เป็นโปรเจกต์จากความหลงใหลที่น่าทึ่งและเป็นทรัพยากรที่ยอดเยี่ยม
พอซูมเข้าไปจะเห็นชื่อเรื่องและบาร์โค้ด และเมื่อเอาเมาส์ไปวางก็เห็นปกกับรายละเอียดด้วย แทบมีครบทุกอย่างที่อยากได้
ไอเดียปรับปรุงคืออยากให้มีเช็กบ็อกซ์สำหรับซ่อนแผงสีขาวลอยอยู่มุมซ้ายบนและองค์ประกอบมุมขวาบน ผมชอบ “ดื่มด่ำ” กับการแสดงภาพแบบนี้ แต่องค์ประกอบลอย ๆ เหล่านั้นดึงออกจากประสบการณ์นั้นนิดหน่อย ทำให้ความสนุกและการใช้งานลดลงเล็กน้อย
นี่เป็นกรณีที่เหมาะมากกับ Microsoft Silverlight PivotViewer เว็บอินเทอร์เฟซยอดเยี่ยมที่เคยใช้ในวงการ neuroimaging ก่อนที่ Microsoft จะยุติไป
มี TED talk ที่น่าประทับใจของ Gary W. Flake ซึ่งสาธิตวิธีใช้งาน
https://m.youtube.com/watch?v=LT_x9s67yWA
ยังมีบทความ IEEE ที่เขียนในปี 2011 ด้วย น่าเสียดายจริง ๆ ที่สิ่งนี้ไม่ได้เป็นมาตรฐานเว็บ
https://www.dropbox.com/scl/fi/bl8zkjs3y47q3377hh3ya/Yan_Wil...
เป็น การแสดงภาพข้อมูล ที่เจ๋งมาก
มีผลงานส่งเข้ามาที่เจ๋งกว่านี้อีกที่นี่: https://software.annas-archive.li/AnnaArchivist/annas-archiv...
งานของผมอยู่ที่ https://isbnviz.pages.dev
เมื่อซูมเข้าไปจะดูเหมือน ชั้นหนังสือ เท่มากจริง ๆ
ยอดเยี่ยม เหมือน Library of Babel เวอร์ชันโลกจริง: https://libraryofbabel.info/
ในบรรดาเรื่องเพ้อเจ้อเกี่ยวกับ VR ทั้งหลาย ถ้าเป็นห้องสมุดอนันต์หรือพิพิธภัณฑ์อนันต์ในโลกจริง ก็อาจยอมจ่ายเงินได้
ถ้าเป็นโปรเจกต์ที่เปิดให้เข้าถึงข้อความทั้งหมดที่ดาวน์โหลดได้และถูกให้บริการอย่างถูกกฎหมาย คงน่าสนใจกว่านี้มาก เช่น อินเทอร์เฟซของที่แบบนี้:
https://onlinebooks.library.upenn.edu/
การนำเสนอในรูปแบบปัจจุบันให้ความรู้สึกค่อนข้างล้นหลาม
ใช้เวลาสักพักกว่าจะเข้าใจว่าส่วนพรีเซ็ตมุมซ้ายบนจริง ๆ แล้วเชื่อมไปยัง แกนการแสดงผลข้อมูลเชิงภาพ เพิ่มเติม เช่น รวม AA หรือไม่, ระดับความหายาก, รวม Google Books หรือไม่ แต่ถึงอย่างนั้นการแสดงผลและความลึกของข้อมูลก็อุดมสมบูรณ์มาก
ลิงก์ที่แสดงหน้าตาของคลัสเตอร์ตามภูมิภาคอย่าง https://archive.anarchy.cool/blog/all-isbns.html#visualizing ก็ดีเช่นกัน
พรีเซ็ตตามปีก็น่าสนใจในตัวเองสำหรับดูความคึกคักของการพิมพ์ตามภูมิภาค Poland ดูคึกคักมากในช่วงหลัง ส่วน Norway ดูค่อนข้างเงียบ China ดูเหมือนเริ่มเพิ่มขึ้นตั้งแต่ราวปี 2005 และโตขึ้นอย่างมหาศาลในช่วง 10 ปีที่ผ่านมา
United States ก็มีจุดแปลก ๆ ด้วย แม้จะไม่เคยได้ยินชื่อ แต่ Blackstone Audio, Blurb Inc., Draft2Digital ออก ISBN จำนวนมหาศาล
มุมมองที่มินิมอลกว่านิดหน่อย (ลดสีลง และแสดงข้อความทีละระดับเดียว) อยู่ที่นี่:
https://phiresky.github.io/isbn-visualization/?dataset=all&g...
น่าจะปรับได้อีก เช่น ซ่อนข้อความบางส่วน อย่างส่วน N publishers หรือทำให้ข้อมูลตอนเมาส์โอเวอร์น้อยลง
เส้นทางการบินอาจคิดได้ค่อนข้างสมเหตุสมผลถ้าโมเดลเป็นการเคลื่อนที่บน ระนาบครึ่งบนไฮเพอร์โบลิก โดยให้ x เป็นตำแหน่งบนเส้นทางเชิงเส้นระหว่างจุดปลาย และ y เป็นความยาวด้านหนึ่งของวิวพอร์ต
ผมนึกถึงเมตริกสองแบบที่จะออกมาเท่ากัน แบบแรกคือสมมติแผนที่ไทล์แบบลำดับชั้น แล้วทำให้จำนวนไทล์ที่ต้องโหลดน้อยที่สุด ถ้าใช้ y เป็นความยาวด้านหนึ่งของวิวพอร์ต ต้นทุนของการเลื่อนแนวนอนระยะ x คือ x/y ไทล์ และถ้าซูมเข้าหรือออกจาก y_0 ไป y_1 จะโหลดไทล์ abs(log_2(y_1/y_0)) จึงตรงกับ ds = dy/y เมื่อนำมารวมกันได้ ds^2 = (dx^2 + dy^2)/y^2 ซึ่งเป็นเมตริกของระนาบครึ่งบนพอดี
อีกวิธีหนึ่งคือมองว่าเป็นการลด “optical flow” ของวิวพอร์ตให้น้อยที่สุดในความหมายบางอย่าง แบบนี้ก็ได้เมตริกเดียวกัน ต่างกันเพียงสเกลเท่านั้น ถ้าแพนเป็นระยะ x โดยไม่ซูม ทุกอย่างจะเลื่อนไป x/y หรือก็คือสัดส่วนเทียบกับวิวพอร์ต ถ้าซูม k เท่า พิกเซลที่ (u,v) จะไปอยู่ที่ (ku,kv) ทำให้ displacement เป็น (u,v)(k-1) ถ้าความยาวด้านหนึ่งเปลี่ยนจาก y เป็น y+dy ก็จะได้ (u,v)dy/y ดังนั้นขึ้นอยู่กับว่าจะเฉลี่ย displacement อย่างไร ก็จะกลายเป็นค่าคงที่บางตัวคูณ dy/y
ดังนั้น geodesic ที่ต้องการคือ horocycle ซึ่งเป็นวงกลมที่มีศูนย์กลางอยู่บน y=0 แต่การคำนวณการเคลื่อนที่ตามเส้นโค้งต้องลงแรงอีกนิด ถ้าจับส่วนโค้งจาก θ_0 ถึง θ_1 เวลารวมจะได้จากการอินทิเกรต dtheta/y = dθ/sin(θ) ดังนั้นถ้าจะให้ถูกต้องต้องกลับค่า t = ln(csc(θ)-cot(θ)) คิดว่าน่าจะใช้การประมาณดีกว่า แต่ Mathematica บอกว่าได้เป็น θ = atan2(1-2e^(2t), 2e^t) ซึ่งก็ไม่ได้แย่นัก
เมื่อเทียบกับลอจิก “blub space” เมตริกที่มีผลของที่นั่นน่าจะเป็น ds^2 = dz^2 + (z+1)^2 dx^2 โดยเป็นพิกัดเชิงขั้วที่ให้ z=1/y เป็นระดับซูม และใช้ dz=dy/y^2 ก็จะได้ ds^2 = dy^2/y^4 + dx^2*(1/y^2 + ...) กล่าวคือ implementation เดิมดูเหมือนจะใช้เวลามากกว่ามากกับการแพนที่ระดับซูมสูง เมื่อเทียบกับโมเดลไฮเพอร์โบลิก เพราะต้นทุนของการลดจาก 4 เท่าเป็น 2 เท่า เป็นสองเท่าของการลดจาก 2 เท่าเป็น 1 เท่า ทั้งที่ในเชิงภาพดูเหมือนกัน
zoom ของพวกเขาไม่ใช่ scale factor แต่ตรงกับ “y” ของผม ดังนั้นเมตริกคือ ds^2 = dy^2 + (C-y)^2 dx^2 โดย C ใหญ่กว่าระดับซูมสูงสุดเล็กน้อย และยังมีการจัดการพิเศษสำหรับเวลาที่เส้นโค้งพยายามซูมออกไปไกลกว่านั้นด้วย
ถ้าทำ normalization ให้ต้นทุนของการแพนไปจนสุดในสภาพซูมออกเต็มที่ (zoom=1) เท่ากัน ในสภาพที่ซูมเข้าลึกมาก ต้นทุนการแพนจะแทบจะแบนราบ ส่วนในสภาพที่ซูมเข้าไม่ลึกเท่า ต้นทุนจะสูงกว่าโมเดลไฮเพอร์โบลิก จึงน่าจะมีส่วนทำให้ระยะสั้น ๆ รู้สึกเหมือนวิวพอร์ตเคลื่อนที่เร็วมาก ส่วนระยะยาวดูเหมือนซูมออกไปเกือบสุด เพราะระดับซูมกลาง ๆ เสียเปรียบ จึงดีกว่าที่จะไปเกือบสุด