Định dạng hình ảnh Ultra HDR phiên bản 1.1

Giới thiệu

Tài liệu này xác định hành vi của một định dạng tệp mới mã hoá hình ảnh bản đồ độ lợi phạm vi logarit trong tệp hình ảnh JPEG. Các trình đọc cũ không hỗ trợ định dạng mới sẽ đọc và hiển thị hình ảnh dải động thấp thông thường từ tệp hình ảnh.Trình đọc hỗ trợ định dạng này sẽ kết hợp hình ảnh chính với bản đồ khuếch đại và kết xuất hình ảnh có dải động cao trên các màn hình tương thích.

Phần còn lại của tài liệu này mô tả các phương thức của các quy trình cần thiết để sử dụng định dạng này. Ở cấp độ tổng quát, vòng đời của một hình ảnh tuân thủ định dạng này là:

1. Mã hoá

   1. Nhận khả năng tạo bản đồ
   2. Nén bản đồ
   3. Tạo vùng chứa bản đồ

2. Giải mã

Hình 1. Ví dụ về bố cục tệp và siêu dữ liệu có liên quan.

Động lực

Mục tiêu của định dạng tệp này là mã hoá thông tin bổ sung trong các tệp hình ảnh SDR có thể được sử dụng kết hợp với kỹ thuật hiển thị để tạo ra các bản trình bày HDR tối ưu trong một tệp duy nhất.

Để có thể áp dụng, định dạng tệp phải:

• Khả năng tương thích ngược để đối với những người xem đơn thuần, hình ảnh SDR thông thường sẽ hiển thị.
• Không chiếm quá nhiều không gian.

Ngoài ra, kỹ thuật hiển thị phải:

• Không yêu cầu xử lý nặng để giải mã.
• Có thể thích ứng với mọi tỷ lệ giữa điểm trắng HDR và SDR của màn hình, tỷ lệ này có thể khác nhau đáng kể giữa các thiết bị hoặc thậm chí là theo thời gian trên một thiết bị.

Cuối cùng, kỹ thuật này phải có thể thực hiện tất cả các hành động trước đó mà không bao giờ:

• Cắt đoạn video khoảnh khắc nổi bật.
• Bóng đổ.
• Thay đổi hoặc nén độ tương phản cục bộ.
• Thay đổi mối quan hệ tương đối về sắc độ (giữa các đối tượng trong cảnh).

Phần phụ thuộc

Sau đây là các tài liệu tham khảo quy phạm cho quy cách này:

• Phần 3 của quy cách Adobe XMP: Lưu trữ trong tệp
• ISO 16684-1:2019 Quy cách XMP Phần 1
• Định dạng tệp nội dung nghe nhìn cơ sở ISO/IEC 14496-12
• T.81 (09/92) Nén kỹ thuật số và mã hoá ảnh tĩnh tông màu liên tục
• Sách trắng về định dạng nhiều ảnh CIPA DC-x 007-2009

Định nghĩa

• Màn hình SDR

  • Màn hình thông thường, không được thiết kế để hiển thị nội dung HDR. Các màn hình này thường tạo ra độ sáng đỉnh danh nghĩa khoảng 400 cd/m² trở xuống.

• Màn hình HDR

  • Màn hình được thiết kế cho nội dung HDR. Các màn hình này thường tạo ra độ sáng cao nhất trên danh nghĩa lớn hơn màn hình SDR, thường là 800 cd/m² trở lên và cũng có tỷ lệ tương phản tốt hơn so với màn hình SDR.

• Ảnh chính

  • Phiên bản đầu tiên của hình ảnh trong tệp GContainer có các tệp nội dung nghe nhìn phụ được thêm vào. Hình ảnh chính chứa siêu dữ liệu GContainer XMP xác định thứ tự và thuộc tính của các tệp mục nội dung đa phương tiện phụ tiếp theo trong vùng chứa tệp.

• Hình ảnh phụ

  • Các tệp mục nội dung đa phương tiện tiếp theo được thêm vào hình ảnh chính trong tệp GContainer.

• Nén phạm vi

  • Trong nhiếp ảnh, các cảnh trong thực tế thường có dải động lớn hơn so với màn hình SDR có thể thể hiện. Các thao tác như Nén dải động (còn gọi là ánh xạ tông màu cục bộ) là cần thiết để giảm dải động của hình ảnh. Việc giảm thiểu này cần tránh cắt bớt các vùng sáng hoặc đổ bóng, trong khi vẫn duy trì độ tương phản cục bộ nhiều nhất có thể. Bạn cố gắng giảm kích thước của các cạnh độ sáng lớn trong hình ảnh, giúp tăng độ tương phản tổng thể của hình ảnh, đồng thời cố gắng giữ nguyên kích thước của các cạnh độ sáng nhỏ, tức là các chi tiết. Mặc dù có nhiều cách triển khai, nhưng thao tác này là tiêu chuẩn trên hầu hết các máy ảnh kỹ thuật số hiện đại.

• Điểm trắng SDR

  • Độ chói tuyến tính tối đa của nội dung SDR trên màn hình tại một thời điểm nhất định.

• Điểm trắng HDR

  • Độ chói tuyến tính tối đa của nội dung HDR trên màn hình tại một thời điểm nhất định. Giá trị này thường cao hơn điểm trắng SDR.

• Tăng

  • Điểm trắng HDR chia cho điểm trắng SDR.

• Mức tăng tối đa cho nội dung (max_content_boost trong phương trình)

  • Giá trị này cho phép nhà sáng tạo nội dung giới hạn mức độ sáng của một hình ảnh khi hiển thị trên màn hình HDR, so với phần hiển thị SDR.
  • Giá trị này là hằng số của một hình ảnh cụ thể. Ví dụ: nếu giá trị là 4, thì đối với bất kỳ pixel nào, độ chói tuyến tính của bản trình bày HDR hiển thị phải cao nhất là gấp 4 lần độ chói tuyến tính của bản trình bày SDR. Trong thực tế, điều này có nghĩa là các phần sáng hơn của cảnh có thể hiển thị sáng hơn gấp 4 lần.
  • Trong thực tế, giá trị này thường lớn hơn 1.0.
  • Luôn lớn hơn hoặc bằng Mức tăng nội dung tối thiểu.

• Mức tăng nội dung tối thiểu (min_content_boost trong phương trình)

  • Giá trị này cho phép nhà sáng tạo nội dung hạn chế mức độ tối của hình ảnh khi hiển thị trên màn hình HDR so với chế độ kết xuất SDR.Giá trị này là hằng số của một hình ảnh cụ thể.
  • Ví dụ: nếu giá trị là 0,5, thì đối với bất kỳ pixel nào, độ chói tuyến tính của bản trình bày HDR hiển thị phải (ít nhất) bằng 0,5 lần độ chói tuyến tính của bản trình bày SDR.
  • Trong thực tế, giá trị này thường bằng hoặc chỉ nhỏ hơn 1.0.
  • Luôn nhỏ hơn hoặc bằng Tăng cường nội dung tối đa.

• Hiệu suất hiển thị tối đa (max_display_boost trong phương trình)

  • Mức tăng tối đa hiện có mà màn hình hỗ trợ, tại một thời điểm nhất định. Giá trị này có thể thay đổi theo thời gian dựa trên chế độ cài đặt thiết bị và các yếu tố khác, chẳng hạn như điều kiện ánh sáng xung quanh hoặc số lượng pixel sáng trên màn hình.
  • Ví dụ: nếu giá trị này là 4, 0, thì màn hình có thể hiển thị một pixel sáng gấp tối đa 4 lần so với điểm trắng SDR. Giá trị này luôn >= 1.0, vì màn hình luôn có thể hiển thị màu trắng HDR ít nhất cũng sáng bằng màu trắng SDR.

• Tăng cường hiển thị

  • Bằng giá trị nhỏ hơn giữa mức tăng tối đa cho nội dung và mức tăng tối đa cho màn hình. Giá trị này luôn >= 1.0.
  • Ví dụ: nếu mức tăng tối đa cho nội dung là 4.0 và mức tăng tối đa cho quảng cáo hiển thị là 3.0, thì mức tăng cho quảng cáo hiển thị là 3.0. Các pixel hiển thị sáng hơn gấp 3 lần so với SDR, vì khả năng hiển thị là yếu tố hạn chế.
  • Ví dụ khác: nếu mức tăng tối đa cho nội dung là 4.0 và mức tăng tối đa cho quảng cáo hiển thị là 5.0, thì mức tăng cho quảng cáo hiển thị sẽ là 4.0. Các pixel hiển thị sáng hơn gấp 4 lần so với SDR, vì ý định của nội dung là yếu tố giới hạn.

• Bản trình bày HDR mục tiêu

  • Theo nhà sáng tạo nội dung, đây là bản trình bày HDR lý tưởng.

• Bản trình bày HDR được điều chỉnh

  • Bản trình bày HDR cuối cùng xuất hiện trên màn hình, sau khi điều chỉnh bản trình bày HDR mục tiêu cho mức tăng cường màn hình hiện tại.

• Bản đồ độ lợi (recovery(x, y) trong phương trình)

  • Một bản đồ cho biết mức độ làm sáng từng pixel, trong bản trình bày SDR, để tạo bản trình bày HDR mục tiêu. Bản đồ này có thể là một kênh hoặc nhiều kênh. Bản đồ nhiều kênh cho biết mức tăng riêng biệt cho từng kênh màu, chẳng hạn như màu đỏ, xanh lục và xanh lam. Tài liệu này minh hoạ trường hợp của bản đồ một kênh.

• clamp(x, a, b)

  • Cố định giá trị x trong phạm vi [a, b].

• exp2(x)

  • Lũy thừa cơ số 2; 2^x.

• floor(x)

  • Trả về số nguyên gần nhất bằng hoặc nhỏ hơn x.

• log2(x)

  • Lôgarit cơ số 2; log₂(x)

• pow(b, x)

  • Số mũ; b^x.

• XMP

  • Nền tảng siêu dữ liệu có thể mở rộng. Một tiêu chuẩn xác định phương thức mã hoá siêu dữ liệu vào vùng chứa hình ảnh; được xác định trong Thông số kỹ thuật XMP ISO 16684-1:2011(E) Phần 1.

• Định dạng nhiều hình

  • Định dạng nhiều hình ảnh là một kỹ thuật do Hiệp hội Máy ảnh và Sản phẩm hình ảnh (CIPA) phát triển để lưu trữ nhiều hình ảnh được mã hoá JPEG trong một tệp JPEG.
  • Để biết thêm thông tin, hãy xem phần phụ thuộc có liên quan, Bài viết trắng về định dạng nhiều ảnh CIPA DC-x 007-2009.

• GContainer

  • GContainer là phương thức để lưu trữ nhiều hình ảnh trong một vùng chứa hình ảnh, trong đó một hình ảnh được coi là hình ảnh chính. Mọi hình ảnh bổ sung đều được coi là phiên bản thay thế hoặc phụ trợ. Siêu dữ liệu XMP được dùng để thông báo về sự hiện diện và ý nghĩa của mọi hình ảnh bổ sung. Để biết thêm thông tin, hãy xem phần Thông tin chi tiết về GContainer.

Mã hoá

Phần này mô tả cách mã hoá tệp JPEG tuân thủ. Tham khảo T.81 (09/92) Nén và mã hoá kỹ thuật số của hình ảnh tĩnh liên tục trong phần Phần phụ thuộc để biết thêm thông tin về định dạng JPEG.

Tạo bản đồ lợi nhuận

Các quy trình tạo hình ảnh của máy ảnh thường thực hiện thao tác nén phạm vi để nén dữ liệu độ chói dải động cao hơn xuống phạm vi thấp hơn của màn hình SDR thông thường. Bản đồ độ lợi cung cấp một cơ chế để lưu trữ dữ liệu đủ để khôi phục dữ liệu độ sáng ban đầu, có dải động cao hơn.

Các phép tính sau đây trong phần này giả định phép tính dấu phẩy động.

Các hàm sau đây mô tả hình ảnh SDR:

• SDR'(x, y) là hình ảnh chính ba kênh, phi tuyến tính (thường được mã hoá gamma).
• SDR(x, y) là phiên bản tuyến tính của hình ảnh chính ba kênh, được lấy bằng cách chuyển đổi sang phiên bản tuyến tính của không gian màu hình ảnh chính. Ví dụ: từ không gian màu có hàm chuyển đổi sRGB sang không gian màu tuyến tính giúp giữ nguyên màu gốc sRGB.

Hàm Ysdr(x, y) được xác định trong khoảng từ 0,0 đến 1,0 và là độ chói tuyến tính của hình ảnh chính trong dải động tiêu chuẩn:

Ysdr(x, y) = primary_color_profile_to_luminance(SDR(x, y))

Có các định nghĩa tương tự cho hình ảnh HDR.

• HDR'(x, y) là ba kênh không tuyến tính, tức là hình ảnh được mã hoá PQ hoặc HLG.
• HDR(x, y) là hình ảnh HDR tuyến tính 3 kênh.

Yhdr(x, y) là độ chói tại một điểm nhất định của hình ảnh HDR:

Yhdr(x, y) = primary_color_profile_to_luminance(HDR(x, y))

Yhdr(x, y) được xác định trong phạm vi từ 0 đến mức tăng nội dung tối đa.

Hình ảnh SDR và HDR phải có cùng độ phân giải. Hồ sơ màu của hình ảnh SDR xác định không gian màu của hình ảnh HDR.

Ví dụ: nếu hình ảnh chính SDR có hồ sơ màu Display-P3, thì hình ảnh HDR được xác định tương ứng với màu chính của hồ sơ đó. Điều này có nghĩa là hình ảnh HDR cũng có màu chính Display-P3.

Bản đồ độ lợi được tính toán từ hai hình ảnh tuyến tính chứa độ chói hình ảnh HDR mong muốn, Yhdr(x, y) và hình ảnh độ chói phạm vi chuẩn, Ysdr(x, y).

Hàm pixel_gain(x, y) được định nghĩa là tỷ lệ giữa hàm Yhdr(x, y) và hàm Ysdr(x, y):

pixel_gain(x, y) = (Yhdr(x, y) + offset_hdr) / (Ysdr(x, y) + offset_sdr)

Hành vi của hàm pixel_gain(x, y) trong đó Ysdr(x, y) và offset_sdr đều bằng 0 được xác định bằng cách triển khai.

Ví dụ: các phương thức triển khai có thể xử lý trường hợp Ysdr(x, y) và offset_sdr đều bằng 0 bằng cách xác định pixel_gain(x, y) là 1.0. Ngoài ra, các phương thức triển khai cũng tránh được trường hợp này bằng cách sử dụng offset_sdr khác 0.

Quá trình triển khai có thể chọn các giá trị của offset_sdr và offset_hdr.

Bản đồ tăng cường là một hàm vô hướng mã hoá pixel_gain(x, y) trong một không gian logarit, tương ứng với mức tăng cường nội dung tối đa và mức tăng cường nội dung tối thiểu:

map_min_log2 = log2(min_content_boost)
map_max_log2 = log2(max_content_boost)

log_recovery(x, y) = (log2(pixel_gain(x, y)) - map_min_log2)
                   / (map_max_log2 - map_min_log2)
clamped_recovery(x, y) = clamp(log_recovery(x, y), 0.0, 1.0)
recovery(x, y) = pow(clamped_recovery(x, y), map_gamma)

Hành vi hàm recovery(x, y) mà pixel_gain(x, y) bằng 0 là quá trình triển khai được xác định, vì log2(0) không xác định.

map_gamma là một số có dấu phẩy động phải lớn hơn 0,0 và được quá trình triển khai chọn.

Giá trị của mức tăng nội dung tối đa và mức tăng nội dung tối thiểu được xác định bằng cách triển khai và có thể do nhà sáng tạo nội dung quyết định tuỳ ý. Mức tăng nội dung tối đa phải lớn hơn hoặc bằng 1. Mức tăng nội dung tối thiểu phải nằm trong khoảng (0,0, 1,0).

Các giá trị trong recovery(x, y) được giới hạn ở phạm vi [0,0, 1,0].

Bản đồ độ lợi được lưu trữ trong một JPEG hình ảnh phụ và do đó phải được mã hoá bằng các giá trị số nguyên 8 bit chưa ký, do đó nằm trong phạm vi [0, 255]. Mỗi giá trị đại diện cho một giá trị recovery(x, y) và được lưu trữ trong một pixel của hình ảnh phụ.

Đối với bộ nhớ số nguyên 8 bit chưa ký, giá trị được mã hoá được xác định như sau:

encoded_recovery(x, y) = floor(recovery(x, y) * 255.0 + 0.5)

Việc tính toán hàm mã hoá được thực hiện ở dấu phẩy động và chuyển đổi ở cuối thành kết quả số nguyên 8 bit chưa ký bằng cách làm tròn như đã chỉ định.

Phương thức mã hoá này dẫn đến kết quả biểu diễn số nguyên 8 bit chưa ký của các giá trị recovery(x, y), từ 0,0 đến 1,0. Bản đồ độ lợi được mã hoá phải được lưu trữ trong một mục hình ảnh phụ dưới dạng JPEG. Quá trình triển khai sẽ chọn mức độ nén để sử dụng trong quá trình mã hoá JPEG.

Sau khi bản đồ độ lợi được lưu trữ trong một hình ảnh phụ, bản đồ này sẽ được thêm vào hình ảnh chính bằng siêu dữ liệu XMP MPF và GContainer. Thư mục GContainer hình ảnh chính phải chứa một mục cho hình ảnh bản đồ độ lợi.

Độ phân giải của bản đồ khuếch đại đã lưu trữ được triển khai xác định và có thể khác với độ phân giải của hình ảnh chính. Trong trường hợp Bản đồ khuếch đại được điều chỉnh theo tỷ lệ ở độ phân giải khác với hình ảnh chính để lưu trữ, thì phương pháp lấy mẫu phải là song tuyến tính hoặc tốt hơn và được xác định cách triển khai.

Hướng của bản đồ độ lợi phải khớp với hướng của hình ảnh chính. Nếu có, mọi siêu dữ liệu hướng trong hình ảnh bản đồ độ lợi được lưu trữ, chẳng hạn như trong EXIF, sẽ không được sử dụng.

Nếu có, cấu hình màu của bản đồ khuếch đại sẽ không được sử dụng.

Lấy vùng chứa bản đồ

Hồ sơ màu

Cấu hình màu của hình ảnh phải được chỉ định thông qua Cấu hình ICC cho hình ảnh chính.

Thuộc tính XMP

Hình ảnh chính chứa siêu dữ liệu XMP để xác định ít nhất hai hình ảnh có thêm thông tin ngữ nghĩa cho định dạng bản đồ độ lợi HDR.

Các tiểu mục sau đây chứa thông tin chi tiết dành riêng cho định dạng này. Bạn có thể xem thêm thông tin về trạng thái tuân thủ chung đối với GContainer trong mục thông tin chi tiết về GContainer.

Các giá trị thuộc tính được mô tả trong các bảng sau được lưu trữ dưới dạng giá trị XMP đơn giản của các loại giá trị cơ bản XMP đã chỉ định.

Giá trị ngữ nghĩa của mặt hàng

Thuộc tính Item:Semantic xác định ý nghĩa dành riêng cho ứng dụng của từng mục nội dung nghe nhìn trong thư mục vùng chứa.

Siêu dữ liệu bản đồ Gain HDR

Việc tăng siêu dữ liệu của bản đồ sẽ mã hoá thông tin về cách diễn giải và áp dụng bản đồ khuếch đại để tạo ra bản trình bày HDR của hình ảnh chính.

URI không gian tên XMP cho phần mở rộng XMP của siêu dữ liệu bản đồ lấy được là http://ns.adobe.com/hdr-gain-map/1.0/. Tiền tố không gian tên mặc định là hdrgm.

Siêu dữ liệu này được lưu trữ trong gói XMP của hình ảnh bản đồ độ lợi và các thuộc tính sau đây phải xuất hiện trong rdf:Description của XMP hình ảnh bản đồ độ lợi:

Ví dụ về tệp XMP bản đồ độ lợi

Ví dụ sau đây về gói XMP bản đồ độ lợi hợp lệ chứa siêu dữ liệu lấy từ tệp mẫu được minh hoạ trong phần Giới thiệu.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 5.5.0">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about=""
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0"
     hdrgm:GainMapMin="-0.57609993"
     hdrgm:GainMapMax="4.7090998"
     hdrgm:Gamma="1"
     hdrgm:OffsetSDR="0.015625"
     hdrgm:OffsetHDR="0.015625"
     hdrgm:HDRCapacityMin="0"
     hdrgm:HDRCapacityMax="4.7090998"
     hdrgm:BaseRenditionIsHDR="False"/>
  </rdf:RDF>
</x:xmpmeta>

Bộ nhớ MPF của bản đồ độ lợi

Hình ảnh bản đồ độ lợi phải được lưu trữ dưới dạng hình ảnh bổ sung như được xác định trong Định dạng nhiều ảnh CIPA DC-x 007-2009, như được tham chiếu trong phần Phần phụ thuộc.

Giải mã

Phần này mô tả cách giải mã bản đồ khuếch đại từ tệp JPEG tuân thủ.

Tín hiệu của định dạng

Bạn có thể xác định tệp JPEG tuân thủ định dạng này bằng cách kiểm tra sự hiện diện của hdrgm:Version="1.0" trong gói XMP của hình ảnh chính, trong đó hdrgm là URI không gian tên http://ns.adobe.com/hdr-gain-map/1.0/.

Định vị hình ảnh bản đồ khuếch đại

Để biết thông tin chi tiết về cách phân tích cú pháp và giải mã hình ảnh, hãy xem mục Thông tin chi tiết về GContainer sau đây. Mục ngữ nghĩa "GainMap" trong rdf:Directory XMP được dùng để báo hiệu vị trí của hình ảnh bản đồ độ lợi. Ngoài ra, IFD chỉ mục MPF và XMP của hình ảnh quét được dùng để xác định vị trí của bản đồ độ lợi.

Xử lý siêu dữ liệu không hợp lệ

Siêu dữ liệu được coi là không hợp lệ nếu thiếu một trường bắt buộc hoặc nếu có bất kỳ trường nào có giá trị không hợp lệ. Một giá trị có thể không hợp lệ vì không phân tích cú pháp được theo loại đã chỉ định hoặc vì giá trị đó nằm ngoài phạm vi dự kiến.

Nếu gặp siêu dữ liệu không hợp lệ, bạn nên bỏ qua bản đồ độ lợi và hiển thị hình ảnh SDR.

Màn hình

Các tệp được mã hoá ở định dạng bản đồ tăng HDR có thể hiển thị trên màn hình SDR thông thường hoặc trên màn hình HDR có đầu ra độ chói cao hơn.

Sử dụng bản đồ độ lợi để tạo bản trình bày HDR được điều chỉnh 

Các phép tính sau đây trong phần này giả định số học dấu phẩy động.

encoded_recovery(x, y) là giá trị số nguyên không dấu, 8 bit, một kênh từ hình ảnh bản đồ độ lợi.

Nếu bản đồ độ lợi có độ phân giải khác với hình ảnh chính, thì encoded_recovery(x, y) được xác định bằng cách lấy mẫu đã lọc của hình ảnh bản đồ độ lợi cho x và y trong phạm vi chiều rộng và chiều cao của hình ảnh chính tương ứng. Phương thức lọc phải là song tuyến tính trở lên và được xác định phương thức triển khai.

map_gamma được xác định bởi trường siêu dữ liệu hdrgm:Gamma.

log_recovery(x, y) là độ lợi pixel dấu phẩy động đã chuẩn hoá trong một không gian logarit:

recovery(x, y) = encoded_recovery(x, y) / 255.0
log_recovery(x, y) = pow(recovery(x, y), 1.0 / map_gamma)

Độ tăng tối đa của màn hình là một giá trị dấu phẩy động vô hướng được xác định là tỷ lệ giữa điểm trắng HDR hiện tại và chia cho điểm trắng SDR hiện tại. Giá trị này do hệ thống hiển thị cung cấp và có thể thay đổi theo thời gian.

hdr_capacity_max được xác định bởi trường siêu dữ liệu hdrgm:HDRCapacityMax. hdr_capacity_min được xác định bởi trường siêu dữ liệu hdrgm:HDRCapacityMin.

weight_factor được xác định như sau khi hdrgm:BaseRenditionIsHDR là "False":

unclamped_weight_factor = (log2(max_display_boost) - hdr_capacity_min)
                        / (hdr_capacity_max - hdr_capacity_min)
weight_factor = clamp(unclamped_weight_factor, 0.0, 1.0)

Khi hdrgm:BaseRenditionIsHDR là "True", phương trình thứ hai sẽ là:

weight_factor = 1.0 - clamp(unclamped_weight_factor, 0.0, 1.0)

gain_map_max được xác định bởi trường siêu dữ liệu hdrgm:GainMapMax. gain_map_min được xác định bởi trường siêu dữ liệu hdrgm:GainMapMin. offset_sdr được xác định bởi trường siêu dữ liệu hdrgm:OffsetSDR. offset_hdr được xác định bằng trường siêu dữ liệu hdrgm:OffsetHDR.

Bạn có thể tính toán giao diện HDR được điều chỉnh tuyến tính như sau:

log_boost(x, y) = gain_map_min * (1.0f - log_recovery(x, y))
                + gain_map_max * log_recovery(x, y)
HDR(x, y) = (SDR(x, y) + offset_sdr) * exp2(log_boost(x, y) * weight_factor)
          - offset_hdr

Nếu cần, quá trình triển khai có thể áp dụng một phép biến đổi cho HDR(x, y) để đặt dữ liệu vào không gian mà màn hình dự kiến. Mọi phép biến đổi như vậy phải đúng màu sắc.

Thông tin chi tiết về GContainer

Phần này chỉ định các yêu cầu bổ sung để định dạng này tuân thủ siêu dữ liệu XML của GContainer. Siêu dữ liệu được chuyển đổi tuần tự theo Quy cách XMP Phần 1 theo ISO 166841:2011(E) và nhúng vào bên trong tệp hình ảnh chính như mô tả trong phần Quy cách của Adobe XMP Phần 3 Lưu trữ trong tệp. Tệp ảnh chính chứa các mục sau, có định dạng là RDF/XML.

Yêu cầu về gói XMP

Gói XMP phải bao gồm tiện ích XMP siêu dữ liệu bản đồ độ lợi thông qua URI không gian tên http://ns.adobe.com/hdr-gain-map/1.0/. Tiền tố không gian tên mặc định là hdrgm.

Gói XMP sẽ xác định hdrgm:Version="1.0".

Phần tử vùng chứa

Không gian tên XMP cho tiện ích GContainer XMP là http://ns.google.com/photos/1.0/container/. Tiền tố không gian tên mặc định là Container.

Hình ảnh chính chứa phần tử Container:Directory trong siêu dữ liệu XMP xác định thứ tự và thuộc tính của tệp phương tiện tiếp theo trong vùng chứa tệp. Mỗi tệp trong vùng chứa có một mục nội dung nghe nhìn tương ứng trong Container:Directory. Mục nội dung nghe nhìn mô tả vị trí trong vùng chứa tệp và các thuộc tính cơ bản của từng tệp được nối.

Phần tử vùng chứa được mã hoá thành siêu dữ liệu XMP của hình ảnh chính và xác định thư mục các mục nội dung đa phương tiện trong vùng chứa. Các mục nội dung đa phương tiện phải nằm trong tệp vùng chứa theo cùng thứ tự với các phần tử mục nội dung đa phương tiện trong thư mục, đồng thời phải được đóng gói chặt chẽ.

Thư mục này chỉ có thể chứa một mục hình ảnh "Chính" và đó phải là mục đầu tiên trong thư mục.

Phần tử mặt hàng

Phần tử mục mô tả cách ứng dụng sử dụng từng mục nội dung nghe nhìn.

URI không gian tên XMP cho tiện ích XMP của mục GContainer là http://ns.google.com/photos/1.0/container/item/. Tiền tố không gian tên mặc định là Item.

Mục nội dung nghe nhìn đầu tiên phải là hình ảnh chính.  Thuộc tính này phải chỉ định Item:Semantic = "Primary" và Item:Mime được liệt kê trong Giá trị loại MIME của mặt hàng.

Độ dài của mục hình ảnh chính được xác định bằng cách phân tích cú pháp hình ảnh chính dựa trên loại MIME của hình ảnh đó, bắt đầu từ đầu vùng chứa tệp.

Các mục nội dung nghe nhìn có thể chứa thuộc tính Item:Padding chỉ định khoảng đệm bổ sung giữa cuối mục nội dung nghe nhìn và đầu mục nội dung nghe nhìn tiếp theo. Khi xuất hiện trên mục nội dung nghe nhìn cuối cùng trong Container:Directory, Item:Padding cho biết khoảng đệm giữa cuối mục và cuối tệp.

Mỗi mục nội dung nghe nhìn phải chứa thuộc tính loại Item:Mime và Item:Semantic. Các mục nội dung nghe nhìn của hình ảnh phụ phải chứa thuộc tính Item:Length.

Các mục nội dung nghe nhìn tuần tự có thể chia sẻ dữ liệu tài nguyên trong vùng chứa tệp. Mục nội dung nghe nhìn đầu tiên xác định vị trí của tài nguyên trong vùng chứa tệp và các mục nội dung nghe nhìn chia sẻ tiếp theo có Item:Length được đặt thành 0. Trong trường hợp dữ liệu tài nguyên chính là một vùng chứa, bạn có thể sử dụng Item:URI để xác định vị trí của dữ liệu mục nội dung nghe nhìn trong tài nguyên.

Vị trí của tài nguyên mục nội dung đa phương tiện trong vùng chứa được xác định bằng cách cộng tổng chiều dài của quá trình mã hoá hình ảnh chính, các giá trị Item:Length của tài nguyên mục nội dung đa phương tiện phụ trước đó và tất cả các giá trị Item:Padding trước đó. Item:Padding được coi là 0 trên các tài nguyên mục nội dung đa phương tiện không chỉ định giá trị của tài nguyên đó.

Giá trị loại MIME của mục

Thuộc tính Item:Mime xác định loại MIME của từng dữ liệu mục nội dung đa phương tiện.

Ví dụ về GContainer XMP

Ví dụ sau đây về gói XMP GContainer hợp lệ có siêu dữ liệu được lấy từ tệp mẫu minh hoạ trong phần Giới thiệu.

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.1.2">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
     xmlns:Container="http://ns.google.com/photos/1.0/container/"
     xmlns:Item="http://ns.google.com/photos/1.0/container/item/"
     xmlns:hdrgm="http://ns.adobe.com/hdr-gain-map/1.0/"
     hdrgm:Version="1.0">
      <Container:Directory>
        <rdf:Seq>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="Primary"
             Item:Mime="image/jpeg"/>
          </rdf:li>
          <rdf:li rdf:parseType="Resource">
            <Container:Item
             Item:Semantic="GainMap"
             Item:Mime="image/jpeg"
             Item:Length="66171"/>
          </rdf:li>
        </rdf:Seq>
      </Container:Directory>
    </rdf:Description>
  </rdf:RDF>
</x:xmpmeta>

Khả năng tương thích với ISO 21496-1

ISO 21496-1 cung cấp một cơ chế đóng gói thay thế để mã hoá siêu dữ liệu bản đồ độ lợi trong tệp hình ảnh. Bạn có thể mã hoá cả siêu dữ liệu Ultra HDR và siêu dữ liệu ISO 21496-1 trong một tệp JPEG bằng cách sử dụng một hình ảnh bản đồ độ lợi duy nhất trong tệp.

Hình 2. Ví dụ về bố cục tệp có siêu dữ liệu Ultra HDR và ISO 21496-1.

Để có khả năng tương thích tối đa trên nhiều nền tảng, các ứng dụng và cách triển khai Android triển khai tính năng mã hoá hoặc giải mã tệp JPEG bằng bản đồ độ lợi riêng phải hỗ trợ tính năng mã hoá và giải mã cho cả siêu dữ liệu Ultra HDR v1 và ISO 21496-1. Trong quá trình mã hoá, hoạt động triển khai hoặc ứng dụng phải mã hoá cả hai định dạng siêu dữ liệu. Nếu cả hai loại siêu dữ liệu đều có trong quá trình giải mã, thì quá trình triển khai hoặc ứng dụng nên sử dụng siêu dữ liệu ISO 21496-1.

Nhật ký thay đổi

Phần này chứa thông tin về các thay đổi giữa các phiên bản của quy cách này.

v1.1

Tất cả thay đổi trong phiên bản thông số kỹ thuật Ultra HDR này đều mang tính chất thông tin và liên quan đến khả năng tương thích với ISO 21496-1. Định dạng tệp thực tế không có gì thay đổi.

• Thêm mục Khả năng tương thích với ISO 21496-1.

v1.0

Ấn bản đầu tiên về thông số kỹ thuật Ultra HDR.