สำหรับคณิตศาสตร์เชดเดอร์เหตุใด RGB เชิงเส้นจึงควรรักษาขอบเขตของ sRGB ไว้

sRGB มักจะถูกเปรียบเทียบกับ "linear RGB"

• รูปภาพจะถูกเก็บไว้ในดิสก์และส่งผ่านไปยังจอแสดงผลในsRGBซึ่งมีความเข้มสม่ำเสมอโดยประมาณ
• คณิตศาสตร์ Shader ทำในเชิงเส้น RGBซึ่งเป็นรูปแบบทางกายภาพในความเข้ม
• สามารถใช้การแก้ไขแกมมาเพื่อแปลงระหว่างสองแบบได้

ตอนนี้ sRGB มีมาตรฐานที่ระบุช่วงสีของสีโดยบอกว่าสีแดงบริสุทธิ์สีเขียวสีน้ำเงินและสีขาวอยู่ตรงไหน แต่ไม่มีมาตรฐานที่สอดคล้องกันสำหรับ "เชิงเส้น RGB" สามเหลี่ยมใด ๆบนแผนภาพ chromaticity อาจกล่าวได้ว่าเป็นเส้นตรงและแน่นอนมีขอบเขตที่รู้จักกันดีหลายอย่างให้เลือก:

ในทางปฏิบัติเมื่อเราพูดว่า "linear RGB" เราหมายถึง "sRGB โดยไม่มีการแก้ไขแกมม่า" (นี่คือสิ่งที่เรากำลังทำเมื่อเราใช้การแก้ไขแกมม่า sRGB เป็นขั้นตอนหลังการประมวลผลขั้นสุดท้าย แต่ไม่สนใจช่องว่างสีสำหรับส่วนที่เหลือของการเรนเดอร์การแสดงผล)

แต่ทำไมที่ RGB Gamut หนึ่งที่ถูกต้องที่จะใช้สำหรับการแก้ไขและแสงคำนวณ? ดูเหมือนว่าโดยพลการ หากมีสิ่งใดเราจะไม่ต้องการใช้ช่วงเสียงที่ใหญ่ที่สุดเท่าที่จะเป็นไปได้สำหรับการคำนวณภายในและจากนั้นคลิปหรือปรับขนาดสีให้กับช่วงเสียงของอุปกรณ์แสดงผลในตอนท้าย

แสง RGB นั้นจะใกล้เคียงกันหรือไม่ดังนั้นจึงไม่สำคัญว่าเราจะเลือกโทนเสียงใดและเราอาจเลือกแสงที่ใกล้เคียงกับที่หน้าจอรองรับมากที่สุด? มันเป็นเพียงความประมาท? หรือการคำนวณในขอบเขตที่แตกต่างกันเหล่านี้ให้ผลลัพธ์ที่เหมือนกันจริงหรือไม่?

หลีกเลี่ยงการพูดถึงLinear RGBเพราะไม่ได้บอกอะไรคุณเกี่ยวกับ RGB colourspace intrinsics เช่น Primaries Whitepoint และ Color Component Transfer ไม่กี่ปีที่ผ่านมาสมมติว่ามันเป็น sRGB เป็นปริศนา แต่ทุกวันนี้กับ DCI-P3 และ BT.2020 เป็นเรื่องธรรมดามากมันต้องถูกตัดออก

ขอบเขตที่เหมาะสำหรับการเรนเดอร์คือสิ่งที่จะลดข้อผิดพลาดที่เกี่ยวข้องกับการอ้างอิงโลกแห่งความเป็นจริง สิ่งที่ควรหลีกเลี่ยงจากประโยคนี้คือ colourspaces RGB แบบต่างๆนั้นไม่เท่ากันและจะไม่ให้ผลลัพธ์ที่คล้ายกัน

หนึ่งอาจคิดว่าการแสดงสองเรนเดอร์ที่มีสีพื้นฐานเหมือนกัน แต่อันที่ซึ่งพวกเขาถูกเข้ารหัสด้วย sRGB / BT.709 และอีกอันที่พวกเขาถูกเข้ารหัสด้วย DCI-P3 แล้วแปลงภาพสองภาพให้เป็นเช่น ACES2065-1 ให้ภาพเดียวกัน แต่ไม่ใช่ในกรณี การดำเนินการทางคณิตศาสตร์บางอย่างเนื่องจากลักษณะของพีชคณิตเชิงเส้นและเมทริกซ์นั้นขึ้นอยู่กับการกำหนด RGB colourspace primaries ที่กำหนดเช่นบนพื้นฐาน colourspaces การทำงานแบบเดียวกันกับที่ทำใน colourspace RGB ที่แตกต่างกันจะให้ค่า tristimulus ที่แตกต่างกันเมื่อแปลงกลับไปเป็นพื้นที่สี CIE XYZ ยกตัวอย่างเช่นการคูณการหารและการใช้พลังงานนั้นขึ้นอยู่กับการเลือกและการลบของ RGB colourspace

ภาพนี้แสดงให้เห็นถึงผลกระทบของการคูณสีต่างๆด้วยตัวเองลงใน colourspaces RGB ที่แตกต่างกัน: สีที่ได้นั้นแตกต่างกัน ตัวอย่างต่าง ๆ ถูกสร้างขึ้นดังนี้: 3 ค่าสุ่ม colourspace sRGB จะถูกเลือกและถูกแปลงเป็น colourspaces RGB ที่ศึกษาทั้งสามค่าจะถูกแทนค่าโดยแปลงกลับเป็น colourspace sRGB ซึ่งถูกวางลงใน CIE 1931 Chromaticity Diagram ทางซ้ายและแสดงเป็น swatches บน ขวา.

การทดสอบและการวิจัยที่ดำเนินการโดยWard และ Eydelberg-Vileshin (2002) , Langlands and Mansencal (2014)และMansencal (2014)แสดงให้เห็นว่าขอบเขตที่มีพรรคใกล้เคียงกับสเป็กตรัมเช่นต้นที่คมชัดของสเปกตรัมมีแนวโน้มที่จะลดข้อผิดพลาด แสดงความจริง

นี่คือรูปภาพที่ฉันเพิ่งแสดงกับ Mitsuba เพื่อตรวจสอบความถูกต้องของการค้นพบของเราอีกครั้งกับ Anders:

สิ่งเหล่านี้คือการแสดงฉากเดียวกันโดยใช้ BT.709 พรรค (แถวแรก) 47 ถังขยะสเปกตรัม (แถวที่สอง), BT2020 พรรค (แถวที่สาม), สเปกตรัมลบ BT.709 พรรคดั้งเดิมแสดงผลเศษที่เหลือ (แถวที่สี่), BT ลบผี .2020 พรรคจัดแสดงผลที่เหลือ (แถวที่ห้า) แถวสุดท้ายนำเสนอภาพคอมโพสิตที่ประกอบไปด้วยแถบแนวตั้งสามแถบตามลำดับซึ่งเป็นแบบดั้งเดิม BT.709, สเปกตรัมและการแสดงผลแบบ BT.2020 การส่องสว่างโดยตรงมีแนวโน้มที่จะจับคู่ระหว่างการแสดงผล พื้นที่ที่แสดงผลของการสะท้อนแสงหลายครั้งเช่นเพดานใน BT.709 และ BT.2020 มีแนวโน้มที่จะแสดงความอิ่มตัวที่เพิ่มขึ้นโดยเฉพาะอย่างยิ่งใน BT.709 ซึ่งจะทำให้สูญเสียพลังงานเล็กน้อยโดยเฉพาะใน BT .2020 เรนเดอร์ หากไม่รวมค่าผิดปกติเช่นแหล่งกำเนิดแสงที่มองเห็นได้ RMSE พร้อมการเรนเดอร์สเปกตรัมนั้นมีค่าเท่ากับ 0.0083และ0.0116สำหรับลำดับBT.2020ตามลำดับและ BT.709 primaries ทำให้ตามลำดับ

ตอนนี้ไม่ได้หมายความว่าพวกเขาจะทำงานได้ดีขึ้นเสมอและอาจมีตัวอย่างหนึ่งที่แสดงอคติต่อ BT.709 / sRGB ประเด็นหลักคือการแสดงผล RGB ไม่สามารถจับคู่การแสดงสเปกตรัมและช่วงที่คมชัดมีแนวโน้มที่จะทำงานได้ดีขึ้น สำหรับการเลือก colourspace การเรนเดอร์ฉันจะเลือกหนึ่งที่มีขอบเขตกว้างที่ครอบคลุม Gamut และ DCI-P3, BT.2020หรือACEScg ของ Pointer ซึ่งเป็นตัวเลือกที่ยอดเยี่ยม

ในทางปฏิบัติเมื่อเราพูดว่า "linear RGB" เราหมายถึง "sRGB โดยไม่มีการแก้ไขแกมม่า"

มันจะถูกต้องมากขึ้นที่จะบอกว่ามี "sRGB colorspace" และ "linearized sRGB colourspace" ด้วยข้อกำหนด sRGB การแปลงจากที่หนึ่งไปยังอีก

ใช่มีช่องว่างสี "linear RGB" มากมาย แต่สิ่งที่สิ่งเหล่านี้ "เชิงเส้น RGB" Colorspaces มีเหมือนกันคือว่าพวกเขาเป็นเชิงเส้น ซึ่งหมายความว่าหากคุณเพิ่มค่าขององค์ประกอบเป็นสองเท่าคุณจะเพิ่มความเข้มของแสงที่ส่วนประกอบนั้นเป็นสองเท่า นั่นคือความหมายของการเป็น "เส้นตรง": มีการแมปเชิงเส้นระหว่างค่าสีกับความเข้มที่เกิดขึ้นของสีแสงนั้น

สิ่งนี้สำคัญเนื่องจากสมการแสงไม่ทำงานหากค่าสีไม่ตรงกับความเข้มของแสงเป็นเส้นตรง แต่สมการไม่สนใจว่าคุณใช้สีเส้นสีใด คุณเพียงแค่ต้องเลือกอย่างใดอย่างหนึ่ง

ดังนั้นสี sRGB เชิงเส้นจึงไม่ถูกต้องมากไปกว่าสี Adobe RGB ที่เป็นเส้นตรงหรือเป็นสี SWOP CMYK เชิงเส้น สิ่งที่สำคัญคือสองสิ่ง:

1. Colorspace แสดงการแมปเชิงเส้นของค่ากับความเข้มของแสง
2. Colorpace ที่เลือกถูกนำมาใช้อย่างสม่ำเสมอในสมการแสง นั่นคือทุกสีที่ใช้ในสมการของแสงนั้นมาจากพื้นที่สีเดียวกัน (เป็นเส้นตรง)

แสง RGB นั้นจะใกล้เคียงกันหรือไม่ดังนั้นจึงไม่สำคัญว่าเราจะเลือกโทนเสียงใดและเราอาจเลือกแสงที่ใกล้เคียงกับที่หน้าจอรองรับมากที่สุด?

นั่นและความจริงที่ว่าการแปลง sRGB ถูกสร้างไว้ในฮาร์ดแวร์ในปัจจุบันในขณะที่การแปลงสีอื่น ๆ ไม่บ่อยนัก ดังนั้นถ้าคุณต้องการใช้ linearized Adobe RGB colorspace คุณต้องทำงานเป็นจำนวนมากใน shaders ของคุณเพื่อกำหนดค่า texel ให้เป็นเส้นตรงและดำเนินการแก้ไข bilinear / trilinear ให้ถูกต้อง (ซึ่งต้องทำหลังจาก linearization) ก่อนที่คุณจะสามารถใช้ ไปยังสมการแสงสว่าง จากนั้นคุณต้องทำการแปลงจาก Linearized Adobe RGB เป็น Linearized sRGB เพื่อให้คุณสามารถเขียนลงใน sRGB framebuffer image เพื่อแสดงผลได้

หรือคุณสามารถใช้ sRGB เชิงเส้นได้ทุกที่และมีประสิทธิภาพ หลังมีแนวโน้มที่จะชนะ

มีสองด้านว่าทำไม sRGB โดยเฉพาะ สำหรับภาพที่ไม่ใช่ HDR จะมีการอ้างว่าควรถูกบีบอัดให้เป็น sRGB (ไม่ว่าการอ้างสิทธิ์นี้ถูกต้องจะเป็นเรื่องอื่น) ดังนั้นก่อนที่คุณจะสามารถดำเนินการทางคณิตศาสตร์เชิงเส้นใด ๆ กับพวกเขาคุณจะต้องขยายพวกเขาจาก sRGB อาจเป็นไปได้ว่ารูปภาพถูกจับและบีบอัดไปยังการแสดงอื่นที่ไม่ใช่ sRGB ซึ่งในกรณีนี้คุณต้องขยายการแสดงที่เฉพาะเจาะจง ไม่ว่าในกรณีใดการเข้ารหัสหมายถึงขอบเขตบางอย่างที่ภาพอินพุตจะไม่รอด (เพราะภาพที่จัดเก็บ sRGB มักจะถูกตัดเหลือ 8 บิตต่อช่อง) แต่คณิตศาสตร์ shader ของคุณไม่ต้องอยู่ในช่วงดังกล่าวหลังจากอินพุต ภาพถูกแตก แต่ในที่สุดคุณต้องพิจารณาการแสดงผล

หากคุณมีภาพและถึงเวลาที่จะแสดงมันคุณเข้ารหัสในการแสดงที่ต้องการอุปกรณ์แสดงผล CRTs เลือก sRGB จากนั้น LCD จึงจำลองว่าดังนั้นการบีบอัด sRGB สำหรับจอแสดงผลจึงเป็นตัวเลือกที่ใช้กันทั่วไปในทศวรรษที่ผ่านมาและ จำกัด การส่งออกที่จะติดอยู่ภายในช่วง sRGB มิฉะนั้นการตัดจะเกิดขึ้น จอแสดงผลที่กว้างขึ้นไม่จำเป็นต้องปรับโทนเสียงที่แน่นอน

(ฉันคิดว่าพื้นฐานสำหรับการอ้างว่าภาพที่มนุษย์สร้างขึ้นนั้นมีการเข้ารหัส sRGB เป็นเพราะภาพเหล่านั้นถูกสมมติว่าได้รับการแต่งขึ้นบนหน้าจอ sRGB)

ดังนั้นตอนนี้คุณอาจเห็นได้ดีกว่าว่าทำไม sRGB โดยเฉพาะได้รับการสนับสนุนในฮาร์ดแวร์สำหรับการป้อนข้อมูลทางคณิตศาสตร์และการแสดงภาพ มันเป็นกรณีทั่วไป นอกจากนี้ยังมีข้อดีที่ดีสำหรับการลดการรับรู้สีแถบแถบดังนั้นจึงเป็นวิธีที่ดีในการบีบอัดสีใน 8 บิตและทำให้พวกเขาดูน่าเชื่อถือสำหรับมนุษย์

หากคุณอนุญาตค่าที่อยู่นอกช่วง 0..1 ดังนั้นแม้จะมีค่าพื้นฐานที่ค่อนข้าง จำกัด ของ sRGB คุณยังสามารถจัดการกับขอบเขตของภาพมนุษย์ทั้งหมดได้ ดังนั้นสำหรับการจัดเก็บค่าสีของแสงไฟแบบลอยตัวไม่ควรมีค่ามากเกินไปสำหรับค่าที่คุณใช้ อย่างไรก็ตามการทำคณิตศาสตร์แบบคูณใด ๆ ก็ค่อนข้างจะขี้ขลาดเพราะพิกัดโดยพลการของพรรคจะทำหน้าที่เป็น 'เดือย' การปรับขนาด โดยทั่วไปแล้วจะใช้ primaries sRGB เนื่องจากข้อมูลอินพุตของคุณถูกเข้ารหัส sRGB และการแสดงผลเอาต์พุตเป็น sRGB หรือ rec709 ... ด้วย rec2020 ครึ่งหนึ่งของข้อมูลนั้นเปลี่ยนไป แต่ตอนนี้ข้อมูลอินพุตของคุณส่วนใหญ่ยังคงถูกเข้ารหัส sRGB ดังนั้นการใช้ พรรคเดียวกับที่เก็บข้อมูลของคุณเป็นเพียงตัวเลือกที่ง่ายที่สุด