Colordepth 24-bit không đủ?

Tôi nhận thấy rằng trong các gradient rất mềm, colordepth 24-bit là không đủ vì bạn có thể thấy sự chuyển đổi của màu sắc. Điều này bật ra nhiều nhất trong những cảnh tối hoặc bầu trời đêm.

Tại sao không ai thay đổi colordepth thành hai byte trên mỗi kênh? Tôi biết rằng đó sẽ là rất nhiều công việc và rất nhiều phần cứng sẽ phải được trang bị lại, nhưng tôi thấy nó hơi khó chịu. Tôi thực sự không nghĩ rằng công nghệ của phần cứng không đủ trưởng thành.

Vậy tại sao không ai làm điều đó?

Đây là hình ảnh của "The War Z" nơi bạn có thể thấy ý tôi là:

Bạn ít nhiều đã tự nói điều đó: 'Tôi biết, đó sẽ là rất nhiều công việc và rất nhiều phần cứng sẽ phải được thay thế.' Mặc dù phần cuối của phần cứng đồ họa thực sự sẽ tương đối đơn giản (nếu đắt tiền - tăng gấp đôi kích thước của tất cả các kết cấu và bộ đệm khung là không quan trọng), 'hệ sinh thái' cho hình ảnh có độ sâu màu cao hơn chỉ đơn giản là không phù hợp với mức độ làm cho điều này trở thành một khoản chi tiêu đáng giá thay cho bất kỳ ai, vì không có nhà sản xuất LCD nào đang tập trung vào việc cố gắng đạt tới 16 bit cho mỗi pixel (mặc dù đã có một số thử nghiệm ở 10BPP, nhưng vẫn phù hợp với tín hiệu RGB thành 32- kênh bit).

Nói tóm lại, nó đơn giản là quá nhiều công việc cho những gì hầu hết mọi người cho là chưa đạt được quá ít. Nó cũng có thể là 'một chút khó chịu', nhưng mức độ khó chịu đó quá mỏng đến nỗi những cải tiến khác về chất lượng hình ảnh đã được ưu tiên.

Đúng, bạn không phải là người đầu tiên nhận thấy điều này . :) Với tỷ lệ tương phản cao ngày nay, 8 bit cho mỗi thành phần là không đủ để tạo độ dốc mịn mà không có dải hiển thị - trừ khi sử dụng phối màu được sử dụng.

Việc sử dụng hơn 8 bit cho mỗi kênh trên màn hình được các nhà sản xuất màn hình gọi là " màu đậm ". Nó không phổ biến lắm vì vấn đề trứng gà. Hiển thị màu sâu là vô ích nếu không có card màn hình có thể tạo ra màu sâu và công cụ trò chơi hỗ trợ kết xuất thành màu sâu. Tương tự như vậy, không có điểm nào trong công cụ trò chơi hoặc thẻ video hỗ trợ màu sâu mà không có màn hình. Vì vậy, không có nhiều động lực cho các nhà sản xuất phần cứng và nhà phát triển trò chơi để thêm hỗ trợ cho công nghệ này, vì từ đầu đến cuối, không có thị trường để biện minh cho chi phí phát triển.

Ngoài ra, có nhiều cách khác để sửa dải do độ chính xác 8 bit bị giới hạn. Như tôi đã đề cập trước đó, các công cụ trò chơi có thể sử dụng phối màu để ẩn dải.

^{(Hình ảnh con mèo với bảng màu 256 màu, không có và phối màu. Được tạo bởi người dùng Wikipedia Wapcaplet , được sử dụng theo giấy phép CC-By-SA 3.0 .)}

Việc thêm một chút hoà sắc là 0,5 0,5 / 255 trước khi ghi giá trị pixel vào bộ đệm khung là cực kỳ hiệu quả trong việc ẩn dải trên các gradient mượt mà và về cơ bản là không thể nhận thấy. Nếu bạn đang ở trong một công cụ HDR, bạn sẽ thực hiện việc này trong giai đoạn tấn công.

Cuối cùng, như những người khác đã lưu ý, nén kết cấu có thể là một nguồn lớn hơn của các tạo tác giống như dải trong hình ảnh so với độ chính xác 8 bit. Đây có thể là những gì đang diễn ra với bầu trời trong bức ảnh đó, mặc dù rất khó để nói - nó có quá nhiều nén JPEG trên đó đến nỗi bất kỳ tạo tác nào do nén DXT đều bị che khuất khá nhiều.

Cũng đáng lưu ý rằng nhiều màn hình LCD thậm chí không có 8 bit trên mỗi kênh. Những cái rẻ hơn có xu hướng sử dụng ít bit hơn và sử dụng các thủ thuật khác nhau để cố gắng che giấu nó. Ví dụ, họ có thể chuyển đổi nhanh chóng giữa hai màu liền kề để thể hiện màu ở giữa. http://www.anandtech.com/show/1557/3

Có một số chi tiết về cách DXGI hỗ trợ 10 bit trên mỗi kênh và sáng hơn màu trắng tại http://msdn.microsoft.com/en-us/l Library / windows / desktop / jj635732% 28v = vs85% 29.aspx

D3D cũng đã hỗ trợ hơn 8 bit cho mỗi kênh trong nhiều năm. Không có gì ngăn cản một nhà phát triển thực hiện một số hoà sắc giảm từ 16 bit trên mỗi kênh xuống 8 bit nếu họ nghĩ rằng đó là một ý tưởng tốt.

Tất nhiên điều đó sẽ không giúp ích nhiều nếu dữ liệu nguồn (kết cấu, v.v.) chỉ là 8 bit (hoặc nhiều khả năng là DXT1, có hiệu quả 5-6-5 bit trên mỗi kênh). Tôi tin rằng đó là những gì với bầu trời trong ảnh chụp màn hình đó (một vệt mờ Gauss 8 bpp làm cho nó mượt mà hơn nhiều đối với tôi) nhưng thật khó để chắc chắn.

Câu trả lời của Steven Stadnick là chính xác - các trò chơi hiếm khi sử dụng kết cấu có độ chính xác cao hơn vì nó đòi hỏi quá nhiều bộ nhớ kết cấu và do đó có quá nhiều băng thông bộ nhớ khi lấy mẫu kết cấu trong một pixel shader. Tuy nhiên, có những giải pháp không yêu cầu kết cấu lớn. (Tôi sẽ đăng bài này dưới dạng một bình luận, nhưng nó quá dài.)

Homewworld giải quyết vấn đề này bằng cách mã hóa hình ảnh bầu trời dưới dạng độ dốc đỉnh . Kỹ thuật này hoạt động tuyệt vời cho các hình ảnh lớn, tần số thấp (nghĩa là độ dốc mịn) - giống như bầu trời - nơi kết cấu bao phủ một số lượng lớn pixel trong trò chơi.

Một giải pháp khả thi khác là áp dụng chuẩn hóa biểu đồ cho hình ảnh bầu trời của bạn. Nếu dữ liệu kết cấu nằm trong phạm vi giá trị hẹp, như bầu trời đêm tối, hầu hết các bit trong mỗi kênh màu không mang dữ liệu hữu ích. Thay vào đó, hãy làm điều này:

• Tác giả kết cấu ban đầu ở định dạng 16 bit, như TIFF 16 bit.
• Khi bạn chuẩn bị họa tiết cho công cụ trò chơi, hãy tìm pixel tối nhất có trong hình ảnh và theo dõi điều này như một phần bù. Giả sử giá trị pixel này là 0,1 trong phạm vi có thể là 0-1.
• Tiếp theo, tìm pixel sáng nhất và trừ pixel tối nhất để có phạm vi giá trị trong ảnh. Vì vậy, nếu pixel sáng nhất vẫn còn khá tối - giả sử 0,35 - phạm vi chỉ là 0,35 - 0,1 = 0,25. Chỉ 25% phạm vi giá trị hiện diện trong hình ảnh.
• Tạo kết cấu trong trò chơi được nén DXT / BC của bạn . Trừ giá trị tối nhất từ ​​mọi pixel và nhân lên để sử dụng toàn bộ dải màu. Trong tính toán ví dụ, chúng tôi trừ đi giá trị tối của chúng tôi là 0,1 và vì chỉ có 25% phạm vi giá trị khả dụng, chúng tôi nhân mọi giá trị pixel với 4x để tạo kết cấu trong trò chơi. Đảm bảo thực hiện tất cả điều này trước khi bạn định lượng hình ảnh nguồn 16 bit của mình xuống đầu vào 8bpp cho máy nén DXT. Bây giờ hình ảnh đầu ra sẽ sử dụng toàn bộ phạm vi giá trị được hỗ trợ bởi định dạng trong trò chơi. Chúng tôi đang phân bổ tất cả các bit của chúng tôi để thể hiện các giá trị thực sự có trong hình ảnh.
• Lưu trữ giá trị bù tối (0,1) và phạm vi (0,25) trong siêu dữ liệu ở đâu đó. Truyền những cái này làm đầu vào cho pixel shader của bạn.
• Trong mã shader pixel, lấy mẫu đã thay đổi, kết cấu mở rộng của bạn, chuyển đổi nó thành giá trị float và sau đó thực hiện nhân / thêm để khôi phục giá trị màu ban đầu. Nói cách khác, nhân 0,25 và thêm 0,1 để khôi phục giá trị được lưu trong ảnh nguồn.

Hãy chắc chắn rằng mã shader là gamma chính xác . Nếu bạn làm toán (chiếu sáng & xử lý hậu kỳ) trên các mẫu kết cấu không được chuyển đổi từ không gian màu sRGB sang không gian tuyến tính, bạn sẽ thấy các tạo tác tạo dải giống như mô tả bạn mô tả. Hiệu chỉnh gamma được tạo ra để giúp giảm bớt loại vấn đề này bằng cách phân bổ nhiều bit hơn cho các giá trị tối trong đó mắt bạn nhạy cảm hơn với các thay đổi giá trị. Nhưng bạn có thể dễ dàng phá vỡ mọi thứ nếu bạn không tính đến hiệu chỉnh gamma khi tính toán, ví dụ, chiếu sáng, phơi sáng hoặc xử lý hậu kỳ FX. Câu hỏi thường gặp về Gamma rất hữu ích.

24 bit là không đủ, nhưng nó phổ biến hơn nhiều đối với các sự cố như thế này do các thuật toán nén hình ảnh, răng cưa hoặc các tạo phẩm kỹ thuật số khác gây ra. Ngoài ra, đừng bỏ qua vai trò của công nghệ màn hình - bất kể đầu vào kỹ thuật số là gì, màn hình có thể không tạo ra các bước thích hợp trong độ sáng thực tế.