TIÊU CHUẨN QUỐC GIA TCVN 11777-9:2017 (WITH AMENDMENT 5:2014) VỀ CÔNG NGHỆ THÔNG TIN – HỆ THỐNG MÃ HÓA HÌNH ẢNH JPEG 2000 – CÁC CÔNG CỤ TƯƠNG TÁC, GIAO THỨC VÀ API

Hiệu lực: Còn hiệu lực

TIÊU CHUẨN VIỆT NAM

TCVN 11777-9:2017

WITH AMENDMENT 5:2014

CÔNG NGHỆ THÔNG TIN – HỆ THỐNG MÃ HÓA HÌNH ẢNH JPEG 2000 – CÁC CÔNG CỤ TƯƠNG TÁC, GIAO THỨC VÀ API

Information technology – JPEG 2000 image coding system – Interactivity tools, APIs and protocols

Lời nói đầu

TCVN 11777-9:2017 hoàn toàn tương đương với các tiêu chuẩn ISO/IEC 15444-9:2005, ISO/IEC 15444-9:2005/Amd 1:2006, ISO/IEC 15444-9:2005/Amd 2:2008, ISO/IEC 15444-9:2005/Amd 3:2008, ISO/IEC 15444-9:2005/Amd 4:2010 và ISO/IEC 15444-9:2005/Amd 5:2014.

TCVN 11777-9:2017 do Học viện Công nghệ Bưu chính Viễn thông biên soạn, Bộ Thông tin và Truyền thông đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

CÔNG NGHỆ THÔNG TIN – HỆ THỐNG MÃ HÓA HÌNH ẢNH JPEG 2000 – CÁC CÔNG CỤ TƯƠNG TÁC, CÁC GIAO THỨC VÀ API

Information technology – JPEG 2000 image coding system – Interactivity tools, APIs and protocols

1 Phạm vi áp dụng

Tiêu chuẩn này quy định các cú pháp và các phương pháp để truy vấn từ xa và tùy chọn thay đổi các dòng mã JPEG 2000.

Trong tiêu chuẩn này, các cú pháp và các phương pháp xác định được gọi là Giao thức tương tác JPEG 2000 ”JPIP”, và các ứng dụng tương tác sử dụng JPIP được gọi là “hệ thống JPIP”.

JPIP chỉ ra một giao thức bao gồm một loạt các tương tác có cấu trúc giữa máy khách và máy chủ, nhờ đó dữ liệu đặc tả tập tin ảnh, cấu trúc và một phần hoặc toàn bộ dòng mã ảnh có thể được trao đổi hiệu quả trong mạng truyền thông. Tiêu chuẩn này bao gồm khái niệm về ngữ nghĩa và các giá trị được trao đổi, gợi ý cách truyền chúng sử dụng các phương thức truyền tải mạng hiện có.

Với JPIP, các nhiệm vụ sau đây có thể được đáp ứng theo các cách thích hợp khác nhau:

– Khả năng trao đổi;

– Khả năng truy vấn sử dụng trong một phiên;

– Yêu cầu và truyền các yếu tố sau đây bằng các vùng chứa thông tin, chẳng hạn như các tập tin họ tiêu chuẩn JPEG 2000, các dòng mã JPEG 2000 và các tập tin chứa thông tin khác:

• Các phân đoạn dữ liệu được chọn;

• Các cấu trúc được chọn và xác định;

• Các phần của một hình ảnh hoặc dữ liệu đặc tả có liên quan.

2 Tài liệu viện dẫn

Tài liệu viện dẫn sau rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả sửa đổi, bổ sung (nếu có).

ISO/IEC 15444-1:2004, Information technology – JPEG 2000 Image Coding System: Core coding system (Công nghệ thông tin – Hệ thống mã hóa hình ảnh: Hệ thống mã hóa lỗi).

ISO/IEC 15444-2:2004, Information technology – JPEG 2000 image coding system: Extensions (Công nghệ thông tin – Hệ thống mã hóa hình ảnh: Các mở rộng).

ISO/IEC 15444-3:2005, Information technology – JPEG 2000 image coding system: Motion JPEG 2000 (Công nghệ thông tin – Hệ thống mã hóa hình ảnh: Motion JPEG 2000).

ISO/IEC 15444-6:2003, Information technology – JPEG 2000 image coding system – Part 6: Compound image file format (Công nghệ thông tin – Hệ thống mã hóa hình ảnh: Định dạng hình ảnh hợp thành).

IETF RFC 768 (1980), User Datagram Protocol (Giao thức gói dữ liệu người dùng (UDP)).

IETF RFC 793 (1981), Transmission Control Protocol (Giao thức điều khiển lớp truyền tải (TCP)).

IETF RFC 2046 (1996), Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (Mở rộng thư điện tử đa mục đích (MIME) Phần hai: Các loại Media).

IETF RFC 2234 (1997), Augmented BNF for Syntax Specifications: ABNF (Đặc điểm cú pháp của dạng Backus-Naur gia tăng: ABNF).

IETF RFC 2396 (1998), Uniform Resource Identifiers (URI): Generic Syntax (Định danh tài nguyên thống nhất (URI): Cú pháp chung).

IETF RFC 2616 (1999), Hypertext Transfer Protocol – HTTP/1.1 (Giao thức truyền tải siêu văn bản – HTTP/1.1).

ISO/IEC 15444-4:2004, Information technology – JPEG 2000 image coding system: Conformance testing (Công nghệ thông tin – Hệ thống mã hóa hình ảnh: Kiểm tra sự phù hợp).

3 Thuật ngữ và định nghĩa

Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa sau:

3.1 Thuật ngữ JPEG 2000 Phần 1

Các thuật ngữ được định nghĩa trong Điều 3 của tiêu chuẩn ISO/IEC 15444-1:2004 và Điều 3 của tiêu chuẩn ISO/IEC 15444-2:2004 cũng áp dụng cho tiêu chuẩn này.

3.2 Thuật ngữ cho HTTP

3.2.1

Kết nối (connection)

Một mạch ảo lớp chuyển vận được thiết lập giữa hai chương trình nhằm mục đích trao đổi các bản tin.

3.2.2

Thực thể (Entity)

Thông tin được truyền qua phần tải tin (payload) trong một yêu cầu hoặc một đáp ứng. Một thực thể bao gồm thông tin đặc tả trong các trường tiêu đề và nội dung trong phần than của thực thể.

3.2.3

Proxy (Proxy)

Một chương trình trung gian đóng vai trò như cả máy chủ và máy khách nội bộ với mục đích thực thi các yêu cầu thay mặt cho các máy khách khác. Các yêu cầu được phục vụ nội bộ hoặc bằng cách đi qua nó, được biên dịch, và gửi đến các máy chủ khác.

3.3 Thuật ngữ cho JPIP

3.3.1

Bộ nhớ đệm (phía máy khách) (cache (client-side))

Bộ nhớ đệm trên Máy khách là bộ nhớ lưu trữ các ngăn dữ liệu JPIP. Máy khách có một bộ nhớ đệm giới hạn và thỉnh thoảng phải xóa các ngăn dữ liệu JPIP được lưu đệm.

3.3.2

Có thể lưu đệm (cacheable)

Một đáp ứng có thể lưu đệm nếu bộ nhớ đệm được phép lưu trữ một bản sao của bản tin đáp ứng để sử dụng cho việc trả lời các yêu cầu tiếp theo. Ngay cả một tài nguyên cũng có thể lưu đệm, có những ràng buộc bổ sung, có hay không một bộ nhớ đệm sử dụng để lưu đệm các bản sao của một yêu cầu cụ thể.

3.3.3

Mô hình bộ nhớ đệm (phía máy chủ) (cache-model (server-side))

Ước tính của máy chủ về các phần của các ngăn dữ liệu có sẵn trong bộ nhớ đệm máy khách. Các máy chủ có thể thêm các phần tử vào để ước lượng bộ nhớ đệm của máy khách vì nó giả định gửi đi thành công, hoặc do nó đã nhận tin báo nhận của dữ liệu được truyền, hoặc do các câu lệnh cập nhật mô hình.

3.3.4

Kênh (channel)

Một cơ chế cho nhóm các yêu cầu và đáp ứng để chỉ có một yêu cầu hoặc đáp ứng trong nhóm hoạt động tại một thời điểm. Càng nhiều yêu cầu và đáp ứng đồng thời đòi hỏi càng nhiều kênh.

3.3.5

Máy khách (client)

Một chương trình thiết lập các kết nối nhằm mục đích gửi các yêu cầu.

3.3.6

Vùng ảnh dòng mã (codestream image region)

Các vùng ảnh dòng mã là giao cắt giữa hình ảnh và vùng được xác định bởi Độ lệch và Kích cỡ vùng. Các vùng ảnh dòng mã có thể trống (không có vùng).

3.3.7

Ngăn dữ liệu (data-bin)

Một tập hợp các byte của cùng một loại dữ liệu có thể được chuyển tiếp từng phần.

3.3.8

Dòng mã tăng dần (incremental-codestream)

Biểu diễn dòng mã bằng một tập hợp các ngăn dữ liệu (tiêu đề chính, tiêu đề khối ảnh, ngăn dữ liệu phân khu ảnh hoặc khối ảnh) có cùng định danh dòng mã.

3.3.9

Bảng chỉ mục JPIP (JPIP index table)

Một khung định dạng tập tin cung cấp thông tin về vị trí các phần của tập tin hoặc dòng mã.

3.3.10

Địa chỉ logic (logical target)

Hình thức đại diện thay cho tài nguyên được chỉ rõ nguồn gốc cụ thể, hoặc một dãy byte gán cho tài nguyên được chỉ rõ nguồn gốc cụ thể, để yêu cầu JPIP định hướng đến. Hình thức đại diện này có thể được chuyển mã thành tài nguyên được chỉ rõ nguồn gốc cụ thể.

3.3.11

Bản tin (message)

Một tập hợp các byte từ ngăn dữ liệu và phần tiêu đề duy nhất xác định các byte này và ngăn dữ liệu.

3.3.12

Dòng mã thô (raw-codestream)

Biểu diễn dòng mã bằng một ngăn dữ liệu đặc tả duy nhất.

3.3.13

Yêu cầu (request)

Một nhóm các trường và các giá trị được gửi từ máy khách đến máy chủ để thu được các phần của ảnh hoặc dữ liệu đặc tả.

3.3.14

Tài nguyên (resource)

Một đối tượng dữ liệu hoặc dịch vụ mạng có thể được xác định bởi một URI. Một địa chỉ HTTP.

3.3.15

Đáp ứng (response)

Các byte gửi từ máy chủ tới máy khách sau khi nhận được yêu cầu.

3.3.16

Máy chủ (server)

Một chương trình ứng dụng chấp nhận các kết nối để phục vụ các yêu cầu bằng cách gửi lại các đáp ứng. Một chương trình bất kỳ cho trước có thể có khả năng là một máy khách hoặc một máy chủ; sử dụng các thuật ngữ này chỉ đề cập đến vai trò đang được thực hiện bởi chương trình cho một kết nối cụ thể, chứ không phải là khả năng của chương trình nói chung.

3.3.17

Phiên (session)

Một tập hợp các yêu cầu và đáp ứng áp dụng cho cùng một tài nguyên mà máy chủ duy trì mô hình bộ nhớ đệm.

3.3.18

Theo phiên (session-based)

Trường hợp máy chủ duy trì một mô hình bộ nhớ đệm.

3.3.19

Phi trạng thái (stateless)

Một yêu cầu duy nhất trong đó máy chủ không sử dụng mô hình bộ nhớ đệm trong việc xác định đáp ứng.

3.3.20

Địa chỉ (target)

Định danh logic của dữ liệu JPIP. Tên của địa chỉ chính thường là tên của một tập tin trên máy chủ.

CHÚ THÍCH: Các tập tin hoặc dòng mã JPEG 2000 có thể có sẵn trong nhiều phép biểu diễn (ví dụ, kiểu trả về, kích cỡ phân khu ảnh) hoặc thay đổi theo những cách khác, mỗi địa chỉ logic duy nhất đều được nhận dạng.

3.3.21

Tiêu đề khối ảnh (tile header)

Tất cả các tiêu đề phần khối ảnh đối với một khối ảnh cụ thể.

3.3.22

Cửa sổ hiển thị (view-window)

Phần của dữ liệu ảnh trên máy khách mong muốn, được thể hiện bởi sự kết hợp của trường sau đây xuất hiện trong các yêu cầu: Kích thước Vùng, Độ lệch, Kích thước Khung hình, Dòng mã, Ngữ cảnh Dòng mã, Tốc độ Lấy mẫu, ROI và Lớp. Các cửa sổ hiển thị thường nhỏ hơn so với toàn bộ dữ liệu ảnh. Nếu một cửa sổ hiển thị ẩn nhưng không xác định, thì nó sẽ được thực hiện như là một cửa sổ hiển thị trên dữ liệu ảnh trọn vẹn của địa chỉ logic.

3.3.23

Lát ảnh (slice)

Một tập hợp các điểm ảnh khối (voxel) trong một ảnh lập thể với các tọa độ Z không đổi.

3.3.24

Hồ sơ (profile)

Sự phù hợp được cấu trúc theo các hồ sơ; một hồ sơ định nghĩa tập hợp các trường yêu cầu mà máy chủ dự kiến sẽ hỗ trợ và thực hiện, máy khách giao tiếp với máy chủ trong hồ sơ này có thể kỳ vọng máy chủ sẽ hỗ trợ chúng. Máy chủ phù hợp với hồ sơ nếu nó hỗ trợ và thực hiện tất cả các trường yêu cầu trong hồ sơ này trong phạm vi quy định tại Phụ lục L.

3.3.25

Biến thể (variant)

Các biến thể xác định các chế độ hoạt động và tính năng của tiêu chuẩn JPIP mà máy khách và máy chủ sử dụng để trao đổi yêu cầu và dữ liệu. Máy khách và máy chủ phải cung cấp một tập hợp các biến chung để tương thích.

3.4 Ký hiệu

Tiêu chuẩn này sử dụng các ký hiệu sau:

c fx fy fz fx’ fy’ fz’ fx“ fy” fz” H_cod	Một chỉ mục (bắt đầu từ 0) của thành phần ảnh chứa phân khu ảnh Kích cỡ khung hình theo trục x đối với cửa sổ hiển thị yêu cầu máy khách Kích cỡ khung hình theo trục y đối với cửa sổ hiển thị yêu cầu máy khách Kích cỡ khung hình theo trục z đối với cửa sổ hiển thị yêu cầu máy khách Kích cỡ khung hình theo trục x đối với độ phân giải thích hợp của dòng mã Kích cỡ khung hình theo trục y đối với độ phân giải thích hợp của dòng mã Kích cỡ khung hình theo trục z đối với độ phân giải thích hợp của dòng mã Kích cỡ khung hình jpx sửa đổi theo trục x đối với độ phân giải thích hợp Kích cỡ khung hình jpx sửa đổi theo trục y đối với độ phân giải thích hợp Kích cỡ khung hình jpx sửa đổi theo trục z đối với độ phân giải thích hợp Chiều cao dòng mã được ghi lại trong khung Tiêu đề Ảnh (ihdr) (Xem Phụ lục I.5.3.1 của tiêu chuẩn ISO/IEC 15444-1:2004)
H_comp	Chiều cao của kết quả hợp thành, được cung cấp trong khung tùy chọn JPX hợp thành (xem Phụ lục M.11.10.1 của tiêu chuẩn ISO/IEC 15444-2:2004)
H_reg	Chiều cao của lớp hợp thành, do nó xuất hiện trên lưới tọa độ đăng ký của lớp hợp thành
Hs_inst Ht_inst l N_L num_components num_tiles ox ox’ ox” oy oy’ oy” oz oz’ oz” r s sx sx’ sx” sy sy’ sy” sz sz’ sz” t w_cod	Chiều cao bị cắt xén Chiều cao hợp thành Định danh duy nhất của phân khu ảnh trong dòng mã Số mức phân tách Số thành phần ảnh được mã hóa Số khối ảnh trong dòng mã Độ lệch theo trục x đối với cửa sổ hiển thị yêu cầu máy khách Độ lệch theo trục x đối với vùng thích hợp của dòng mã Độ lệch jpx sửa đổi theo trục x đối với vùng thích hợp Độ lệch theo trục y đối với cửa sổ hiển thị yêu cầu máy khách Độ lệch theo trục y đối với vùng thích hợp của dòng mã Độ lệch jpx sửa đổi theo trục y đối với vùng thích hợp Độ lệch theo trục z đối với cửa sổ hiển thị yêu cầu máy khách Độ lệch theo trục z đối với vùng thích hợp của dòng mã/ thành phần Độ lệch jpx sửa đổi theo trục z đối với vùng thích hợp Mức phân giải Số thứ tự để xác định phân khu ảnh trong thành phần khối ảnh Kích cỡ theo trục x đối với cửa sổ hiển thị yêu cầu máy khách Kích cỡ theo trục x đối với vùng thích hợp của dòng mã Kích cỡ jpx sửa đổi theo trục x đối với vùng thích hợp Kích cỡ theo trục y đối với cửa sổ hiển thị yêu cầu máy khách Kích cỡ theo trục y đối với vùng thích hợp của dòng mã Kích cỡ jpx sửa đổi theo trục y đối với vùng thích hợp Kích cỡ theo trục z đối với cửa sổ hiển thị yêu cầu máy khách Kích cỡ theo trục z đối với vùng thích hợp của dòng mã Kích cỡ jpx sửa đổi theo trục z đối với vùng thích hợp Chỉ mục (bắt đầu từ 0) của khối ảnh chứa phân khu ảnh Chiều rộng dòng mã được ghi lại trong khung Tiêu đề Ảnh (ihdr) (Xem Phụ lục I.5.3.1 của tiêu chuẩn ISO/IEC 15444-1:2004)
W_comp	Chiều rộng của kết quả hợp thành, được cung cấp trong khung tùy chọn JPX hợp thành (xem Phụ lục M.11.10.1 của tiêu chuẩn ISO/IEC 15444-2:2004)
W_reg	Chiều rộng của lớp hợp thành, do nó xuất hiện trên lưới tọa độ đăng ký của lớp hợp thành
Ws_inst Wt_inst XC_inst	Chiều rộng bị cắt xén Chiều rộng hợp thành Độ lệch cắt xén theo trục x được cung cấp thông qua hướng dẫn có liên quan (xem Phụ lục M.11.10.2.1 của tiêu chuẩn ISO/IEC 15444-2:2004)
XO_inst	Độ lệch hợp thành theo trục x được cung cấp thông qua hướng dẫn hợp thành có liên quan (xem Phụ lục M.11.10.2.1 của tiêu chuẩn ISO/IEC 15444-2:2004)
XO_reg XOsiz	Độ lệch đăng ký dòng mã theo trục x Độ lệch theo phương ngang tính từ gốc của lưới tọa độ tham chiếu của đoạn nhãn SIZ của dòng mã có liên quan
XR_re_g	Hệ số lấy mẫu đăng ký dòng mã theo trục x, được mô tả tại điểm bắt đầu của khung đăng ký dòng mã bất kỳ (xem Phụ lục M.11.7.7 của tiêu chuẩn ISO/IEC 15444-2:2004)
Xsiz	Chiều rộng của lưới tọa độ tham chiếu của đoạn nhãn SIZ của dòng mã có liên quan
XS_reg	Độ chính xác đăng ký theo trục x được mô tả tại điểm bắt đầu của khung đăng ký dòng mã bất kỳ (xem Phụ lục M.11.7.7 cửa tiêu chuẩn ISO/IEC 15444-2:2004)
YC_inst	Độ lệch cắt xén theo trục y được cung cấp thông qua hướng dẫn có liên quan (xem Phụ lục M.11.10.2.1 của tiêu chuẩn ISO/IEC 15444-2:2004)
YO_inst	Độ lệch hợp thành theo trục y được cung cấp thông qua hướng dẫn hợp thành có liên quan (xem Phụ lục M.11.10.2.1 của tiêu chuẩn ISO/IEC 15444-2:2004)
YO_reg YOsiz	Độ lệch đăng ký dòng mã theo trục y Độ lệch theo phương dọc tinh từ gốc của lưới tọa độ tham chiếu của đoạn nhãn SIZ của dòng mã có liên quan
YR_reg	Hệ số lấy mẫu đăng ký dòng mã theo trục y, được mô tả tại điểm bắt đầu của khung đăng ký dòng mã bất kỳ (xem Phụ lục M.11.7.7 của tiêu chuẩn ISO/IEC 15444-2:2004)
Ysiz	Chiều cao của lưới tọa độ tham chiếu của đoạn nhãn SIZ của dòng mã có liên quan
YS_r_e_g	Độ chính xác đăng ký theo trục y được mô tả tại điểm bắt đầu của khung đăng ký dòng mã bất kỳ (xem Phụ lục M.11.7.7 của tiêu chuẩn ISO/IEC 15444- 2:2004)

4 Chữ viết tắt

ABNF	Dạng Backus-Naur gia tăng	Augmented Backus-Naur Form
DICOM	Tiêu chuẩn ảnh số và truyền thông trong y tế	Digital Imaging and Communications in Medicine
DWT	Biến đổi Sóng con rời rạc	Discrete Wavelet Transformation
EOR	Kết thúc đáp ứng	End of Response
HTML	Ngôn ngữ đánh dấu siêu văn bản	HyperText Markup Language
IP	Giao thức Internet	Internet Protocol
JP3D	JPEG 2000 Phần 10: 3-D và dữ liệu dấu chấm động	JPEG 2000 Part 10: 3-D and floating point data
JPIP	Giao thức tương tác JPEG 2000	JPEG 2000 Interactive Protocol
JPP	Phân khu ảnh JPIP	JPIP Precinct
JPSEC	JPEG 2000 Phần 8: Bảo mật JPEG 2000	JPEG 2000 Part 8: Secure JPEG 2000
JPT	Phần khối ảnh JPIP	JPIP Tile-part
JPWL	JPEG 2000 Phần 11: Vô tuyến	JPEG 2000 Part 11: Wireless
JTC 1	Ủy ban kỹ thuật 1	Joint Technical Committee 1
MTF	Chức năng chuyển điều chế	Modulation Transfer Function
PDF	Định dạng tài liệu di động	Portable Document Format
SC 29	Tiểu ban kỹ thuật 29	Sub-Committee 29
SVG	Đồ họa véc-tơ có thể co giãn	Scalable Vector Graphics
TCP	Giao thức điều khiển truyền tin	Transmission Control Protocol
UDP	Giao thức UDP	User Datagram Protocol
UUID	Mã định danh phổ biến duy nhất	Universal Unique Identifier
VBAS	Đoạn Byte được đặt có độ dài biến đổi	Variable-length Byte Aligned Segment
WG1	Nhóm nghiên cứu 1	Working Group 1
XHTML	Ngôn ngữ đánh dấu siêu văn bản mở rộng	Extensible HyperText Markup Language
XML	Ngôn ngữ đánh dấu mở rộng	Extensible Markup Language

5 Quy ước

5.1 Các quy tắc ABNF

Tiêu chuẩn này sử dụng các ký hiệu ABNF định nghĩa trong RFC 2234, bao gồm cả các quy tắc cú pháp ABNF cốt lõi: ALPHA (chữ cái), CR (ký tự trả về đầu dòng), CRLF (ký tự sang dòng mới), CTL (ký tự điều khiển), DIGIT (chữ số thập phân), HEXDIG (chữ số thập lục phân), LF (ký tự qua dòng), LWSP (khoảng trắng tuyến tính) và SP (ký tự khoảng trắng). Theo mục đích của tiêu chuẩn này, các quy tắc ABNF sau đây được áp dụng.

Tiêu chuẩn này cũng xác định PATH, đại diện cho một tập tin hoặc đường dẫn. Thông thường, các giá trị PATH có thể chứa ký tự bất kỳ, mặc dù đối với một kiến trúc máy chủ nhất định, máy chủ sẽ từ chối ký tự bất kỳ không hợp lệ trên máy chủ cụ thể. Ngoài ra, PATH sẽ được mã hóa đúng theo quy định của công nghệ lớp truyền tải.

UINT-RANGE xác định một dãy giá trị nguyên. Số nguyên đầu tiên trong dãy chỉ ra bắt đầu của dãy. Nếu hai giá trị được xác định, thì các giá trị đầu tiên và thứ hai xác định giới hạn bắt đầu và kết thúc của dãy này. Nếu chỉ xác định giá trị đầu tiên và ký tự “-“, dãy bao gồm tất cả các giá trị lớn hơn hoặc bằng giá trị đầu tiên.

Giá trị số ngay trước ký hiệu ABNF đề cập đến số lần lặp lại của các tham số phía sau, không có khoảng trắng xen giữa mỗi lần xuất hiện.

Cấu trúc “1 #” đề cập đến một hoặc nhiều lần lặp lại của các tham số phía sau, mỗi lần xuất được phân cách bởi một dấu phẩy.

Cấu trúc “1 $” đề cập đến một hoặc nhiều lần lặp lại của các tham số phía sau, mỗi lần xuất hiện được phân cách bằng dấu chấm phẩy.

5.2 Quy tắc ABNF định dạng tập tin

box-type xác định bốn ký tự cho loại khung. Đối với từng ký tự cho loại khung, nếu ký tự là số-chữ cái (A..Z, a..z hoặc 0..9), các ký tự được viết trực tiếp vào chuỗi. Nếu ký tự này là một khoảng trắng (\040), thì ký tự đó sẽ được mã hóa như các ký tự gạch dưới (“_”) hoặc mã hóa hệ bát phân. Đối với các ký tự bất kỳ khác, một chuỗi 4 ký tự được viết vào đó, bao gồm một ký tự gạch chéo ngược (“\”) tiếp theo là ba chữ số hệ bát phân đại diện cho các giá trị của các ký tự cho loại khung trong hệ bát phân. compatibility-code được mã hóa giống như cách mã hóa box-type.

box-type-list xác định một danh sách các loại khung. Nếu giá trị của một trường box-type-list là “*”, thì trường này đề cập đến tất cá các loại khung.

5.3 Giải pháp mô tả đồ họa cho các khung (tham khảo)

Mô tả của mỗi khung đi kèm với hình vẽ biểu diễn thứ tự và mối quan hệ của các tham số trong khung. Hình 1 minh họa một ví dụ về loại hình này. Một hình chữ nhật được sử dụng để chỉ ra các tham số trong khung. Chiều rộng của hình chữ nhật tỷ lệ thuận với số byte trong tham số. Hình chữ nhật tô màu (sọc chéo) chỉ ra các tham số có kích thước thay đổi. Hai tham số có chỉ số trên và vùng màu xám ở giữa chỉ ra dải liên tục của các tham số này. Một dãy hai nhóm nhiều tham số có các chỉ số trên cách nhau bởi khu vực màu xám chỉ ra dải liên tục của nhóm các tham số này (một tập từng tham số trong nhóm, tiếp theo là tập từng tham số trong nhóm kế tiếp). Các tham số tùy chọn hoặc các khung sẽ được hiển thị bằng hình chữ nhật nét đứt.

Hình vẽ này đi kèm với một danh sách mô tả ý nghĩa của từng tham số trong khung. Nếu các tham số được lặp lại, độ dài và tính chất của dải liên tục các tham số được xác định. Ví dụ, trong Hình 1, các tham số A, B, C và D có độ dài 8, 16, 32 bit và độ dài thay đổi tương ứng. Ký hiệu E⁰ và E^N-¹ có nghĩa là tồn tại N tham số khác nhau trong một hàng, Eⁱ. Nhóm các tham số F⁰ và F^M^–¹, và G⁰ và G^M^–¹ chỉ ra khung sẽ chứa F⁰, tiếp theo là G⁰, tiếp theo là F¹ và G¹, tiếp tục F^M^–¹ và G^M-¹ (M biểu diễn tổng các tham số). Ngoài ra, các trường D là tùy chọn và có thể không xuất hiện trong khung này.

Ngoài ra, trong một số hình vẽ mô tả nội dung của một siêu khung, dấu chấm lửng (…) sẽ được sử dụng để chỉ ra rằng nội dung của các tập tin giữa hai khung không được xác định cụ thể. Khung bất kỳ (hoặc chuỗi các khung), trừ trường hợp được xác định bởi định nghĩa khung, có thể xuất hiện ở vị trí của dấu chấm lửng.

Hình 1 – Ví dụ về hình vẽ mô tả khung

Ví dụ, Siêu khung được minh họa trong Hình 2 phải chứa khung AA và khung BB, và khung BB phải theo sau khung AA. Tuy nhiên, có thể có các khung khác giữa hai khung AA và BB. Việc giải quyết các khung không xác định này được thảo luận trong Phụ lục I.8 của tiêu chuẩn ISO/IEC 15444-1:2004.

Hình 2 – Ví dụ về hình vẽ mô tả siêu khung

6 Mô tả chung

6.1 Giao thức JPIP

Tiêu chuẩn này mô tả các cú pháp và phương pháp được sử dụng khi một máy khách được truy cập vào dữ liệu ảnh JPEG 2000 nén và dữ liệu có liên quan đến ảnh lưu trên máy chủ cài đặt giao thức JPIP. Tiêu chuẩn này cho phép thay đổi linh hoạt và dự kiến chức năng trong tiêu chuẩn ISO / IEC 15444-1:2004 được thực hiện trên nhiều lớp truyền tải trong mạng máy khách / máy chủ.

JPIP định nghĩa giao thức tương tác để đạt được hiệu quả trao đổi dữ liệu ảnh JPEG 2000 và dữ liệu có liên quan đến ảnh. Giao thức định nghĩa sự tương tác máy khách-máy chủ dựa trên yêu cầu của máy khách và đáp ứng máy chủ biểu diễn trong Hình 3. Tiêu chuẩn này xác định các yêu cầu máy khách JPIP và các đáp ứng máy chủ JPIP. Các giao thức HTTP/1.1 (RFC 2616), TCP (RFC 793) và UDP (RFC 768) minh họa ví dụ về khả năng truyền tải của JPIP. Máy khách sử dụng yêu cầu Cửa sổ hiển thị để xác định độ phân giải, kích thước, vị trí, các thành phần, các lớp, và các thông số khác của ảnh và dữ liệu có liên quan đến ảnh được yêu cầu bởi máy khách. Máy chủ đáp ứng bằng cách cung cấp dữ liệu ảnh và dữ liệu có liên quan đến ảnh trên các dòng theo phân khu ảnh, dòng theo khối ảnh hoặc toàn bộ ảnh. Giao thức cũng cho phép đàm phán máy khách và máy chủ về năng lực và các hạn chế. Máy khách có thể yêu cầu thông tin về một hình ảnh được định nghĩa trong bảng chỉ mục JPIP từ máy chủ, cho phép máy khách hoàn thành yêu cầu Cửa sổ hiển thị của nó với các thông số hình ảnh cụ thể (ví dụ, yêu cầu phạm vi byte). Mô hình bộ nhớ đệm của máy chủ dựa vào khả năng xác định của máy khách và điều kiện có trạng thái của phiên.

Hình 3 – Tổng quan giao thức JPIP

Giao thức này có thể được sử dụng trên các lớp truyền tải khác nhau minh họa trong Hình 4. Tiêu chuẩn này bao gồm các phụ lục tham khảo về việc sử dụng các giao thức JPIP trên các giao thức HTTP, TCP và UDP, và cung cấp các đề xuất cho việc cài đặt các ví dụ này. Chính bản thân giao thức JPIP là trung gian đối với các cơ chế truyền tải lớp dưới cho các yêu cầu của máy khách và đáp ứng máy chủ, ngoại trừ trường hợp liên quan đến yêu cầu kênh được đại diện bởi trường yêu cầu Kênh Mới (“cnew”) (xem C.3.3) và tiêu đề đáp ứng Kênh Mới (“JPIP-cnew”) (xem D.2.3), trong đó chi tiết đặc tính truyền tải sẽ được chỉ ra. Tiêu chuẩn này định nghĩa bốn loại truyền tải cụ thể được xác định bởi các dãy “http”, “https”, “http-tcp” và “http-UDP” trong các chuỗi giá trị liên quan đến yêu cầu Kênh Mới.

Hình 4 – Chồng giao thức JPIP

Quy định bao gồm các phần mở rộng của giao thức JPIP để hỗ trợ tiêu chuẩn JPEG 2000 hiện tại. Tiêu chuẩn ISO / IEC 15444-3, Motion JPEG 2000 và tiêu chuẩn ISO / IEC 15444-6, Tài liệu hợp thành, và các phần tiếp theo của tiêu chuẩn JPEG 2000 (hiện là JP3D, JPSEC, và JPWL).

6.2 Mục đích

Tiêu chuẩn này định nghĩa cú pháp và các phương pháp cần thiết cho cả máy khách và máy chủ. Mỗi phụ lục định nghĩa một thành phần cần thiết để đạt được khả năng tương tác và chức năng giữa máy khách và máy chủ trên một số lớp truyền tải. Mỗi phụ lục có thể là một yêu cầu của máy khách, máy chủ, hoặc cả hai. Các phụ lục được mô tả dưới đây.

– Phụ lục A mô tả các dòng theo khối ảnh và dòng theo phân khu ảnh được yêu cầu cho cả máy khách và máy chủ. Các máy chủ yêu cầu tạo ra các dòng JPP và JPT phù hợp và biết cách tải lên các dòng này. Các máy khách yêu cầu hiểu và giải mã đúng những dòng trên và chịu trách nhiệm tạo ra các dòng phù hợp khi tải một phần hình ảnh lên máy chủ.

– Phụ lục B mô tả các phiên và mô hình bộ nhớ đệm của một phiên máy khách – máy chủ cần thiết cho cả máy khách và máy chủ.

– Phụ lục C định nghĩa cú pháp yêu cầu của máy khách. Các máy khách phải đưa ra các yêu cầu phù hợp và các máy chủ phải có khả năng phân tích, biên dịch và đáp ứng tất cả các yêu cầu phù hợp.

– Phụ lục D định nghĩa cú pháp đáp ứng máy chủ. Các máy chủ phải tạo ra các đáp ứng phù hợp và máy khách có thể hiểu được các đáp ứng phù hợp này.

– Phụ lục E định nghĩa cú pháp và phương pháp để tải một phần hình ảnh lên các hệ thống có sử dụng giao thức JPIP.

– Phụ lục F, G, H và K xác định các phương pháp và thủ tục tương tác máy khách – máy chủ JPIP thông qua các giao thức truyền tải khác nhau.

– Phụ lục I định nghĩa cú pháp thông tin lập chỉ mục chứa trong khung JPEG 2000 có thể được sử dụng bởi máy khách và máy chủ để truy cập dữ liệu ảnh và dữ liệu có liên quan đến ảnh hiệu quả hơn.

– Phụ lục L định nghĩa cách mở rộng tiêu chuẩn này thông qua việc đăng ký.

– Phụ lục M mô tả một vài ví dụ về cách sử dụng tiêu chuẩn này đối với các ứng dụng khác nhau.

– Phụ lục N định nghĩa tập quy tắc ABNF được sử dụng trong giao thức JPIP.

– Phụ lục O mô tả tuyên bố sáng chế của tổ chức ISO/IEC cho giao thức này.

– Sự tương thích của máy chủ và máy khách tiếp tục được cấu trúc thành các hồ sơ và các biến thể. Các hồ sơ xác định các trường mà các máy chủ phải hỗ trợ và thực hiện phân tích và biên dịch. Các biến thể xác định các chế độ và tính năng hoạt động của tiêu chuẩn JPIP mà máy khách và máy chủ sử dụng để truyền dữ liệu. Máy khách và máy chủ phải cung cấp một tập hợp các biến thể phổ biến để tương hợp. Xem Phụ lục J để biết chi tiết về sự tương thích và thử nghiệm về sự tương thích này.

7 Sự phù hợp

Sự phù hợp của máy khách với tiêu chuẩn này có nghĩa là các yêu cầu JPIP của máy khách có cấu trúc hợp lệ và phù hợp với các yêu cầu máy khách JPIP được quy định trong tiêu chuẩn này, và nó có thể phân tích các đáp ứng JPIP được định nghĩa tại tiêu chuẩn này.

Sự phù hợp của máy chủ với tiêu chuẩn này có nghĩa là các đáp ứng JPIP của máy chủ có cấu trúc hợp lệ và phù hợp với tín hiệu đáp ứng máy chủ JPIP được quy định trong tiêu chuẩn này, và có khả năng phân tích các yêu cầu JPIP được quy định trong tiêu chuẩn này. Máy chủ sẽ phân tích và biên dịch tất cả các loại yêu cầu và phải đáp ứng tất cả các yêu cầu phù hợp. Sự tương thích của hồ sơ yêu cầu máy chủ hỗ trợ và thực thi tất cả các trường bắt buộc của hồ sơ được quy định tại Phụ lục J.

Các hồ sơ phù hợp và các phương pháp luận kiểm tra sự phù hợp của tiêu chuẩn này được quy định tại Phụ lục J.

Người ta cho rằng các ứng dụng máy chủ có thể bị giảm hiệu quả do việc gửi dữ liệu bổ sung không rõ ràng hoặc dữ liệu dư thừa sinh ra từ QoS mạng. Quyết định thực thi như vậy là ứng dụng cụ thể và cung cấp cho hệ thống JPIP tính tiện ích cao.

Phụ lục A

(Quy định)

Các kiểu phương tiện truyền thông dòng JPP và dòng JPT

A.1 Tổng quan

Dòng JPP và dòng JPT là các kiểu phương tiện truyền thông hữu ích cho việc biểu diễn dòng mã JPEG 2000 và dữ liệu định dạng tập tin theo thứ tự tùy ý. Mỗi kiểu phương tiện truyền thông bao gồm một chuỗi các bản tin được ghép nối, mỗi bản tin có chứa một phần của ngăn dữ liệu đơn đặt trước bởi tiêu đề bản tin. Ngăn dữ liệu chứa các phần của biểu diễn ảnh nén JPEG 2000, như vậy nó có thể tạo ra một dòng miêu tả đầy đủ các thông tin có trong tập tin JPEG 2000 hoặc dòng mã. Mỗi bản tin hoàn toàn tự mô tả, do đó trình tự của bản tin có thể kết thúc bất cứ lúc nào và bản tin có thể sắp xếp lại đối tượng để tối thiểu các ràng buộc mà không làm mất đi ý nghĩa của chúng. Đối với những lý do này, các kiểu phương tiện truyền thông dòng JPP và dòng JPT rất hữu ích cho các máy chủ JPIP và giao thức JPIP được thiết kế với các kiểu phương tiện truyền thông này. Phụ lục này quy định các kiểu phương tiện truyền thồng dòng JPP và dòng JPT mà không cần tham chiếu đến các giao thức JPIP.

Hình A1 – Các ví dụ về tập tin JPEG 2000, ngăn dữ liệu JPIP và mối quan hệ giữa các dòng JPIP

Hình A.1 là một ví dụ minh họa mối quan hệ giữa các dòng bit từ tập tin JPEG 2000, các ngăn dữ liệu JPIP, và một dòng JPIP. Hình này cho thấy tiêu đề chính được mã hóa bằng màu đỏ, 2 phân khu ảnh với các gói được mã hóa bởi các sắc thái của màu vàng cam và màu xanh lá cây, khung dữ liệu đặc tả được mã hóa màu xanh dương. Các bản tin JPIP tự mô tả được hình thành từ các ngăn dữ liệu và được ràng buộc dưới hình thức của một dòng JPIP.

Dòng JPIP bao gồm một hoặc nhiều bản tin JPIP được ràng buộc. Mỗi bản tin JPIP bao gồm một tiêu đề và một phần thân. Các tiêu đề cung cấp thông tin mô tả để nhận dạng ngăn dữ liệu có liên quan. Phần thân là dữ liệu từ ngăn dữ liệu. Nếu không bổ sung thêm dấu hiệu, bản tin sẽ là sự ghép nối của phần tiêu đề và phần thân.

CHÚ THÍCH: Trong tiêu chuẩn này, tất cả các ví dụ được cung cấp dưới dạng bản tin nhị phân bằng cách ghép nối phần tiêu đề và phần thân. Điều này đặc trưng cho cách thực thi của lớp truyền tải và lớp ứng dụng nếu cung cấp thêm dấu hiệu khác cho tiêu đề và phần thân. Ví dụ, dấu hiệu bổ trợ để chống lỗi có thể thay đổi được sử dụng cho các ứng dụng vô tuyến.

A.2 Cấu trúc tiêu đề bản tin

A.2.1 Tổng quát

Mỗi bản tin đại diện cho một phần của ngăn dữ liệu xác định. Tiêu đề bản tin bao gồm một chuỗi các đoạn byte được sắp đặt có độ dài biến đổi (VBAS). Mỗi VBAS bao gồm một chuỗi các byte, với bit có trọng số cao nhất (bit 7) là 1, như Hình A.2. Bảy bit có trọng số thấp hơn trong VBAS ghép nối để tạo thành một dòng bit được sử dụng theo nhiều cách khác nhau cho các VBAS khác nhau.

Hình A2 – Cấu trúc VBAS

Các tiêu đề bản tin phục vụ cho việc xác định ngăn dữ liệu và phạm vi byte cụ thể được biểu diễn trong phần thân của bản tin. Tiêu đề bản tin có thể có dạng độc lập và dạng phụ thuộc. Dạng độc lập là một dạng đầy đủ trong đó tiêu đề bản tin hoàn toàn tự mô tả; việc giải thích chúng độc lập với bất kỳ tiêu đề bản tin khác. Các tùy chọn tiêu đề bản tin dạng phụ thuộc rút gọn sử dụng các thông tin trong các tiêu đề của bản tin trước đó; việc giải mã chúng phụ thuộc các bản tin trước đó. Các ứng dụng có thể chọn để sử dụng các tiêu đề bản tin dạng đầy đủ; những bản tin này có thể được sắp xếp lại theo thứ tự tùy ý. Ngoài ra, các ứng dụng có thể sử dụng các tiêu đề bản tin dạng rút gọn phụ thuộc vào tiêu đề bản tin trước đó; đây là các bản tin ngắn hơn nhưng sẽ cho kết quả sai nếu bản tin không được sắp xếp theo trình tự chính xác khi giải mã. Đây là một quyết định áp dụng, có hoặc không sắp xếp lại chuỗi các bản tin nhận được giả định là đáng tin cậy, cho dù sử dụng các tiêu đề bản tin dạng rút gọn.

Tiêu đề bản tin bao gồm các VBAS sau đây (các VBAS tùy chọn được xác định bằng việc sử dụng các dấu ngoặc vuông):

Bin-ID [, Class] [, CSn], Msg-Offset, Msg-Length [, Aux]

Sự tồn tại của VBAS Class và CSN được xác định bằng cách kiểm tra VBAS Bin-ID. Sự tồn tại của VBAS Aux được xác định bởi VBAS Class hoặc VBAS Class trước đó, nếu không có VBAS Class trong tiêu đề bản tin hiện tại.

VBAS Bin-ID phục vụ nhiều vai trò. Bit 6 và 5 trong byte đầu tiên của VBAS Bin-ID, được dán nhãn ‘b’ trong Hình A.3, chỉ ra các VBAS Class và CSN có mặt trong tiêu đề bản tin. Bảng A.1 xác định các giá trị bit và ý nghĩa của nó.

Bit 4 trong byte đầu tiên của VBAS Bin-ID, được dán nhãn ‘c’ trong Hình A.3, cho biết bản tin này có hay không chứa các byte cuối cùng trong ngăn dữ liệu được gán: “0” có nghĩa là nó không phải là byte cuối cùng trong ngăn dữ liệu; “1” chỉ ra rằng nó là byte cuối cùng trong ngăn dữ liệu. Nhận bản tin với tập bit này cho phép xác định độ dài của ngăn dữ liệu hoàn chỉnh, mặc dù nó không phải là dòng JPP hoặc dòng JPT hoàn chỉnh bao gồm đầy đủ các bản tin để kết hợp tất cả các byte từ ngăn dữ liệu.

Bốn bit còn lại của byte đầu tiên và bảy bit trọng số thấp của byte bất kỳ còn lại trong VBAS Bin-ID (được dán nhãn ‘d’ trong Hình A.3) tạo thành một “định danh lớp trong”, được sử dụng để nhận diện ngăn dữ liệu duy nhất trong các lớp, theo cách thức được mô tả trong Điều A.2.3.

Hình A.3 – Cấu trúc VBAS bin-ID

Bảng A.1 – Chỉ số VBAS bin-ID bổ sung

Bit Chỉ số ‘bb’	Ý nghĩa
00	Bị cấm.
01	Không xuất hiện VBAS Class hoặc CSn trong tiêu đề bản tin
10	Xuất hiện VBAS Class nhưng không xuất hiện CSn trong tiêu đề bản tin
11	Cả VBAS Class and CSn đều xuất hiện trong tiêu đề bản tin

VBAS CLass, nếu có, cung cấp một định danh lớp bản tin. Định danh lớp bản tin là một số nguyên không âm, hình thành bằng cách ghép 7 bit trọng số thấp trong mỗi byte của VBAS theo trình tự big endian. Nếu không có VBAS Class, thì định danh lớp bản tin không thay đổi so với bản tin trước đó. Nếu không có VBAS Class và cũng không có bản tin trước đó, thì định danh lớp bản tin bằng 0. Định danh lớp bản tin hợp lệ được mô tả trong Điều A.2.2.

VBAS CSN, nếu có, xác định các chỉ số (bắt đầu từ 0) của dòng mã thuộc ngăn dữ liệu. Chỉ số dòng mã được hình thành bằng cách ghép 7 bit trọng số thấp trong mỗi byte của VBAS theo trình tự big endian. Nếu không có VBAS CSN, thì chỉ số dòng mã không thay đổi so với bản tin trước đó. Nếu không có VBAS CSN và cũng không có bản tin trước đó, thì chỉ số dòng mã bằng 0.

Các VBAS Msg-offset và Msg-Length biểu diễn bằng các giá trị số nguyên không âm, hình thành bằng cách ghép 7 bit trọng số thấp trong mỗi byte của VBAS theo trình tự big endian. Số nguyên Msg-Offset xác định độ dịch của dữ liệu trong bản tin này so với điểm bắt đầu của ngăn dữ liệu. Số nguyên Msg-Length xác định tổng số byte trong phần thân của bản tin.

VBAS Aux có thể có. Sự xuất hiện của nó, và ý nghĩa nếu có, được xác định bởi các định danh lớp bản tin tìm thấy trong VBAS Bin-ID, được giải thích trong Điều A.2.2. Nếu VBAS Aux biểu diễn bởi một giá trị nguyên không âm, thì nó được hình thành bằng cách ghép 7 bit trọng số thấp trong mỗi byte của VBAS theo trình tự big endian.

CHÚ THÍCH: Các thông tin trong VBAS Aux không ảnh hưởng đến độ dài của phần thân bản tin.

A.2.2 Định danh lớp bản tin

Các định danh lớp bản tin theo quy định của tiêu chuẩn này là những số nguyên không âm thể hiện trong Bảng A.2. Việc giải thích của các lớp ngăn dữ liệu chỉ được mô tả trong Điều A.3. Tất cả các giá trị khác của định danh lớp bản tin được dự trữ, và các bản tin liên quan được bỏ qua do bộ giải mã không công nhận nhận giá trị.

Các định danh lớp được lựa chọn như vậy sao cho VBAS Aux xuất hiện khi và chỉ khi định danh là số lẻ. Đặc tính này cho phép phân tích một cách chính xác và bỏ qua nội dung các tiêu đề bản tin không được công nhận.

Các bản tin ngăn dữ liệu phân khu ảnh mở rộng giải thích giống như bản tin ngăn dữ liệu phân khu ảnh không mở rộng và chúng đề cập đến chính xác cùng một ngăn dữ liệu phân khu ảnh. Các bản tin phân khu ảnh mở rộng bao gồm VBAS Aux trong đó xác định số lượng các gói hoàn chỉnh (các lớp chất lượng) có sẵn trong phân khu ảnh nếu các byte trong bản tin này được kết hợp với tất cả các byte trước đó của phân khu ảnh đó. Nếu bản tin này cũng chứa các byte cuối cùng của ngăn dữ liệu, VBAS Aux cho biết tổng số lớp chất lượng liên quan đến phân khu ảnh trong dòng mã gốc. Nếu không, VBAS Aux chỉ ra lớp chất lượng của các byte ngay sau byte cuối cùng thuộc bản tin. Các thông tin trong VBAS Aux có thể hữu ích cho các máy khách nhất định.

Bảng A.2 – Định danh lớp cho các lớp bản tin ngăn dữ liệu khác nhau

Định danh lớp	Lớp bản tin	Lớp ngăn dữ liệụ	Loại dòng
0	Bản tin ngăn dữ liệu phân khu ảnh	Ngăn dữ liệu phân khu ảnh	Chỉ dòng JPP
1	Bản tin ngăn dữ liệu phân khu ảnh mở rộng	Ngăn dữ liệu phân khu ảnh	Chỉ dòng JPP
2	Bản tin ngăn dữ liệu tiêu đề khối ảnh	Ngăn dữ liệu tiêu để khối ảnh	Chỉ dòng JPP
4	Bản tin ngăn dữ liệu khối ảnh	Ngăn dữ liệu khối ảnh	Chỉ dòng JPT
5	Bản tin ngăn dữ liệu khối ảnh mở rộng	Ngăn dữ liệu khối ảnh	Chỉ dòng JPT
6	Bản tin ngăn dữ liệu tiêu đề chính	Ngăn dữ liệu tiêu đề chính	Dòng JPP và JPT
8	Bản tin ngăn dữ liệu đặc tả	Ngăn dữ liệu đặc tả	Dòng JPP và JPT

Bản tin ngăn dữ liệu khối ảnh mở rộng giải thích giống như bản tin ngăn dữ liệu khối ảnh không mở rộng và chúng đề cập đến chính xác cùng một ngăn dữ liệu khối ảnh. Các bản tin khối ảnh bao gồm VBAS Aux trong đó xác định giá trị n nhỏ nhất, trong tất cả các thành phần ảnh mà (NL – n) không âm, mức phân giải (NL – n) và tất cả các mức phân giải thấp hơn được hoàn thành khi các byte trong bản tin này được kết hợp với tất cả các byte trước đó của khối ảnh đó, trong đó NL là số mức phân tách, có thể thay đổi tùy theo thành phần ảnh. Nếu không có mức phân giải của bất kỳ thành phần ảnh đã được hoàn thành, giá trị VBAS Aux sẽ bằng giá trị tối đa NL trên tất cả các thành phần ảnh cộng với một. Giá trị bằng không khi tất cả độ phân giải trong tất cả các thành phần ảnh được hoàn thành. Do độ phân giải không nhất thiết phải xuất hiện theo thứ tự trong một khối ảnh, một vài mức phân giải trên giá trị được đánh dấu bằng VBAS có thể được hoàn thành, nhưng điều này không thể được xác định từ tiêu đề bản tin. Các thông tin trong VBAS Aux có thể hữu ích cho các máy khách nhất định.

A.2.3 Định danh lớp trong

Bốn bit trọng số thấp của byte đầu tiên và 7 bit trọng số thấp của các byte khác từ VBAS Bin-ID được ghép nối theo trình tự big endian để tạo thành một từ đơn, có 7k-3 bit, với k là số byte trong VBAS. Từ này đại diện cho một số nguyên không dấu để phục vụ cho việc nhận diện ngăn dữ liệu duy nhất trong lớp và dòng mã của nó. Điều A.3 cung cấp mô tả cho các lớp ngăn dữ liệu khác nhau, tương ứng với định danh lớp trong.

A.3 Các ngăn dữ liệu

A.3.1 Tổng quan

Ngăn dữ liệu chứa các phần của một dữ liệu tập tin hoặc dòng mã JPEG 2000. Điều này dựa trên các yếu tố dữ liệu ảnh, chẳng hạn như là dữ liệu phân khu ảnh, dữ liệu khối ảnh, và các tiêu. đề. Chúng cũng có thể dựa trên dữ liệu đặc tả. Cho dù nội dung của ngăn dữ liệu, mỗi ngăn dữ liệu được đối xử như một dòng bit riêng.

A.3.2 Ngăn dữ liệu phân khu ảnh

A.3.2.1 Định dạng ngăn dữ liệu phân khu ảnh

Ngăn dữ liệu phân khu ảnh chỉ xuất hiện trong kiểu phương tiện truyền thông dòng JPP. Mỗi ngăn dữ liệu phân khu ảnh tương ứng với một phân khu ảnh duy nhất trong một dòng mã duy nhất. Các định danh lớp trong được xác định bởi Phương trình A -1.

I = t + (c + s x num_compon ents) x num_tiles

(A-1)

Trong đó:

I là định danh duy nhất của phân khu ảnh trong dòng mã của nó;

t là chỉ số (bắt đầu từ 0) của khối ảnh chứa phân khu ảnh;

c là chỉ số (bắt đầu từ 0) của thành phần ảnh chứa phân khu ảnh;

s là số thứ tự xác định phân khu ảnh trong khối ảnh thành phần.

Trong mỗi khối ảnh thành phần, phân khu ảnh được gán số thứ tự liên tiếp, s, như sau. Tất cả các phân khu ảnh của mức phân giải thấp nhất (chỉ chứa các mẫu băng con LL) được sắp xếp đầu tiên, bắt đầu từ 0, sau đó sắp xếp theo trình tự quét mành. Phân khu ảnh của từng mức phân giải liên tiếp được sắp xếp lần lượt theo trình tự quét mành trong mức phân giải của chúng.

Định danh phân khu ảnh 0 đề cập đến phân khu ảnh phía trên cùng bên tay trái từ băng con LL của thành phần ảnh 0 trong khối ảnh 0.

Đối với hình ảnh lập thể được mã hóa trong JP3D (ISO/IEC 15444-10), số thứ tự của phân khu ảnh trong thành phần k được tính như sau: Tất cả các phân khu ảnh của mức phân giải thấp nhất, nghĩa là chúng chỉ chứa các mẫu [L|X][L|X][L|X] được sắp xếp đầu tiên, bắt đầu từ số không, theo trình tự quét mành quy định tại Điều 3.11 của tiêu chuẩn ISO / IEC 15444-10. Các phân khu ảnh từ mỗi mức phân giải liên tiếp được sắp xếp lần lượt, theo trình tự quét mành tại Điều 3.11. Các phân khu ảnh với số thứ tự 0 đề cập đến các phân khu ảnh phía trên cùng bên trái của băng con độ phần giải thấp nhất của các thành phần ảnh 0 trong khối ảnh 0.

Mỗi ngăn dữ liệu phân khu ảnh tương ứng với chuỗi các byte được hình thành bằng cách ghép tất cả các gói dòng mã với các tiêu đề gói có liên quan hoàn chỉnh thuộc phân khu ảnh. Có thể hiểu rằng tiêu đề gói sẽ được đóng gói vào đoạn nhãn PPM hoặc PPT sau đó thuộc về các ngăn dữ liệu tiêu đề chính hoặc tiêu đề khối ảnh, trong trường hợp ngăn dữ liệu phân khu ảnh chỉ chưa thành phần chính gói. Trong mọi trường hợp, các dòng dữ liệu phân khu ảnh nên trùng khớp với đoạn liền kề của byte đó sẽ tìm thấy trong dòng mã JPEG 2000 một trong các trình tự lũy tiến lớp-phụ thuộc (CPRL, PCRL hoặc RPCL).

Hình A.4 – Ví dụ Ngăn dữ liệu phân khu ảnh

CHÚ THÍCH: Do mục đích hiệu quả khi phục vụ một hình ảnh có chứa nhãn PPM, máy chủ có thể chuyển mã các tiêu đề gói đóng gói trong tiêu đề chính vào tiêu đề khối ảnh (nhãn PPT). Nếu không, máy khách sẽ yêu cầu nhãn độ dài phần khối ảnh (TLM) được gửi đi. Các máy chủ có thể chuyển mã các hình ảnh (minh bạch cho máy khách) theo cách như vậy để tránh việc sử dụng các tiêu đề gói được đóng gói hoàn toàn.

A.3.2.2 Ví dụ về ngăn dữ liệu phân khu ảnh (Tham khảo)

Hình A.4 minh họa một ví dụ về ngăn dữ liệu phân khu ảnh (định danh lớp trong 3) với 4 lớp chất lượng (hoặc gói).

Đối với Trường hợp A, B và C, tiêu đề bản tin được hiển thị dưới đây, dựa trên các cấu trúc bản tin ngăn dữ liệu phân khu ảnh mở rộng và không mở rộng. Các dữ liệu gạch dưới biểu thị VBAS Aux để xác định số lượng các lớp được hoàn tất vào bản tin.

(Trường hợp A)

Tiêu đề không mở rộng: 00100011 01101011 10000001 00100101 xxxxxxxx …

Bit 0 khởi tạo chỉ ra rằng chỉ có một byte được sử dụng trong VBAS Bin-ID. Hai bit (“01”) tiếp theo chỉ ra rằng không xuất hiện VBAS Class hay CSN. Bit “0” tiếp theo chỉ ra rằng ngăn dữ liệu của tin nhắn không được hoàn thành. Các bit còn lại của byte đầu tiên (“0011”) chỉ ra rằng bin-ID bằng 3. Bit đầu tiên của byte thứ hai chỉ ra rằng chỉ có một byte được sử dụng trong VBAS Msg-Offset. Bảy bit tiếp theo (“1101011”) có nghĩa là độ dịch là 107. Bit đầu tiên của byte thứ 3 chỉ ra rằng cả byte này và ít nhất một byte kế tiếp là một thành phần của VBAS Msg-Length. Các bit 0 bắt đầu từ byte thứ 4 chỉ ra rằng nó là byte cuối cùng của VBAS Msg-Length. Như vậy tất cả các bit bậc thấp từ byte thứ 3 và thứ 4 được kết hợp để xác định chiều dài. Trong trường hợp này, “0000001 0100101” = 165.

Tiêu đề mở rộng: 01000011 00000001 01101011 10000001 00100101 00000011 xxxxxxxx …

(Trường hợp B)

Tiêu đề không mở rộng: 00100011 10000001 00001000 01010100 xxxxxxxx …

Tiêu đề mở rộng: 01000011 00000001 10000001 00001000 01010100 00000011 xxxxxxxx …

(Trường hợp C)

Tiêu đề không mở rộng: 00110011 10000001 00001000 10000001 00110101 xxxxxxxx ….

Tiêu đề mở rộng: 01010011 00000001 10000001 00001000 10000001 00110101 00000100 xxxxxxxx …

Lưu ý rằng do dữ liệu đáp ứng chứa byte cuối cùng của ngăn dữ liệu trong Trường hợp C, VBAS Bin- ID chỉ ra rằng nó là một bản tin “hoàn chỉnh”.

A.3.3 Ngăn dữ liệu tiêu đề khối ảnh

Ngăn dữ liệu tiêu đề khối ảnh chỉ xuất hiện trong kiểu phương tiện truyền thông dòng JPP. Đối với ngăn dữ liệu thuộc lớp này, định danh lớp trong giữ chỉ số (bắt đầu từ 0) của khối ảnh mà ngăn dữ liệu. Ngăn dữ liệu này bao gồm các nhãn và đoạn nhãn cho khối ảnh n. Nó không chứa đoạn nhãn SOT. Tùy chọn bao gồm các nhãn SOD. Ngăn dữ liệu này có thể được hình thành từ một dòng mã hợp lệ, bằng cách ghép tất cả các đoạn nhãn trừ SOT trong tất cả các tiêu đề phần khối ảnh của khối ảnh n.

CHÚ THÍCH 1: Đoạn nhãn POC cũng có thể được loại bỏ vì chúng không đáp ứng yêu cầu của một máy khách JPIP điển hình. Tuy nhiên, một máy chủ cần phải bao gồm các nhãn POC cho một ứng dụng máy khách là đầu ra của một tập tin JPEG 2000 với cùng thứ tự lũy tiến với hình ảnh gốc có sẵn tại máy chủ.

Một máy chủ có thể gửi dữ liệu theo thứ tự bất kỳ, nhưng phải gửi ngăn dữ liệu khối ảnh cho một khối ảnh ngay cả khi tiêu đề khối ảnh trống.

CHÚ THÍCH 2: Một máy khách tiếp nhận dữ liệu hình ảnh cho một khối ảnh nhưng vẫn chưa nhận được tiêu đề khối ảnh của nó thì không nên cho rằng tiêu đề khối ảnh trống và hãy cố gắng giải mã dữ liệu. Nó có thể mang lại lợi ích cho máy khách nhất định để nhận được ngăn tiêu đề khối ảnh trong ngăn dữ liệu khối ảnh.

A.3.4 Ngăn dữ liệu khối ảnh

Ngăn dữ liệu khối ảnh chỉ được sử dụng với kiểu phương tiện truyền thông dòng JPT. Đối với ngăn dữ liệu thuộc lớp này, định danh lớp trong là chỉ số (bắt đầu từ 0) của khối ảnh chứa ngăn dữ liệu đó. Mỗi ngăn dữ liệu tương ứng với chuỗi các byte được hình thành bằng cách ghép tất cả phần khối ảnh thuộc khối ảnh đó, theo thứ tự, hoàn thành với SOT của chúng, SOD và tất cả các đoạn nhãn có liên quan khác.

A.3.5 Ngăn dữ liệu tiêu đề chính

Cả hai kiểu phương tiện truyền thông dòng JPP và dòng JPT sử dụng ngăn dữ liệu tiêu đề chính. Đối với ngăn dữ liệu thuộc lớp tiêu đề chính dòng mã (hoàn chỉnh hoặc các biến thể không hoàn chỉnh), định danh lớp trong sẽ bằng 0. Ngăn dữ liệu này bao gồm danh sách liên kết của tất cả các nhãn và đoạn nhãn trong tiêu đề chính, bắt đầu từ nhãn SOC. Nó không chứa các nhãn SOT, SOD hay EOC.

A.3.6 Các ngăn dữ liệu đặc tả

A.3.6.1 Giới thiệu về ngăn dữ liệu đặc tả

Cả hai kiểu phương tiện truyền thông dòng JPP và dòng JPT sử dụng ngăn dữ liệu đặc tả. Ngăn dữ liệu đặc tả được sử dụng để truyền tải dữ liệu đặc tả từ địa chỉ logic chứa dòng mã hoặc các dòng mã mà thành phần có thể được tham chiếu bởi ngăn dữ liệu khác liên quan đến dòng JPP hoặc dòng JPT. Với mục đích của tiêu chuẩn này, thuật ngữ “dữ liệu đặc tả” dùng để chỉ tập hợp các “khung” bất kỳ từ tập tin họ tiêu chuẩn JPEG 2000. Chỉ số dòng mã được bỏ qua trong bản tin bất kỳ mà có các định danh lớp ngăn dữ liệu đặc tả.

Không giống như các số ID đã sử dụng cho các loại ngăn dữ liệu, ID của ngăn dữ liệu đặc tả của không ánh xạ thuật toán để một số cấu tạo định dạng tập tin hoặc độ dịch byte. Các máy chủ tự do lựa chọn số ID bất kỳ cho bất kỳ ngăn dữ liệu đặc tả cụ thể. Nó và chỉ có nó ngoại trừ việc đầy các ngăn dữ liệu đặc tả chứa địa chỉ logic gốc thì được gán ID bằng 0.

CHÚ THÍCH 1: Cơ chế gán được thực hiện phụ thuộc; tuy nhiên, nó là một gợi ý mang thông tin để các máy chủ chỉ định bin-ID dùng cho các số liên tiếp.

Máy chủ phải gửi ít nhất một ngăn dữ liệu đặc tả với bin-ID bằng 0, thậm chí nếu không có dữ liệu đặc tả. Trong trường hợp này, metabin # 0 sẽ trống.

CHÚ THÍCH 2: Máy chủ không nên cho rằng không có sẵn dữ liệu đặc tả nếu nó vẫn chưa nhận được bất kỳ ngăn dữ liệu đặc tả nào. Nó có thể mang lại lợi ích cho máy nhất định để nhận được các ngăn dữ liệu đặc tả với bin-ld 0 trước cho tất cả bin khác.

A.3.6.2 Phân chia địa chỉ logic chứa một tập tin JPEG 2000 vào ngăn dữ liệu đặc tả

Tất cả dữ liệu đặc tả có thể hình dung được nằm trong ngăn dữ liệu đặc tả 0 Trong trường hợp này, tất cả các khung địa chỉ logic thuộc về ngăn dữ liệu đặc tả 0, và xuất hiện theo thứ tự ban đầu của chúng. Do định dạng họ tiêu chuẩn JPEG 2000 bao gồm một chuỗi các khung, điều này có nghĩa là ngăn dữ liệu đặc tả 0 sẽ bao gồm toàn bộ địa chỉ logic. Tổng quát hơn, nó rất hữu ích trong việc chia nhỏ địa chỉ logic thành nhiều phần có thể được truyền dưới hình thức có điều khiển. Điều này cho phép các máy chủ hình ảnh để bỏ qua có chủ đích các phần của địa chỉ logic mà không theo yêu cầu của máy khách. Để kết thúc việc này, JPIP định nghĩa một loại khung đặc biệt mới, được gọi là “Khung Chờ”. Khung Chờ phục vụ để xác định kích thước và loại khung từ địa chỉ logic, trong khi trỏ đến ngăn dữ liệu chứa nội dung của khung. Khung Chờ cũng có thể đại diện cho các dòng mã từ địa chỉ logic. Điều này đặc biệt quan trọng trong bối cảnh thực tế là các dữ liệu nén được biểu diễn bởi dòng mã bất kỳ nhất định có thể được gửi từng bước thông qua các loại ngăn dữ liệu khác (ngăn dữ liệu tiêu đề và ngăn dữ liệu phân khu ảnh hoặc ngăn dữ liệu khối ảnh).

Chính thức, ngăn dữ liệu đặc tả 0 bao gồm tất cả các khung từ địa chỉ logic, xuất hiện theo thứ tự ban đầu của chúng, ngoại trừ việc khung Chờ có thể thay thế khung bất kỳ cho trước. Khung Chờ chứa các tiêu đề của khung đó đó đã được thay thế, cùng với định danh của ngăn dữ liệu đặc tả chứa nội dung của khung đó, không bao gồm tiêu đề của chính nó. Mỗi ngăn dữ liệu đặc tả, khác với ngăn dữ liệu đặc tả 0, sẽ bao gồm các nội dung của một vài khung, tiêu đề xuất hiện trong khung Chờ tham chiếu đến ngăn dữ liệu. Những nội dung khung có thể bao gồm các khung con, khung bất kỳ sau này có thể được thay thế bằng các khung Chờ.

Sơ đồ màu dưới đây sẽ được sử dụng để minh họa ví dụ về ngăn dữ liệu đặc tả (Hình A.5):

Hình A.5 – Sơ đồ ví dụ màu ngăn dữ liệu đặc tả

Ví dụ, xem xét một tập tin JP2 đơn giản với cấu trúc khung bên dưới (Hình A.6):

Hình A.6 – Ví dụ tập tin JP2

Tập tin này có thể được chia thành ba ngăn dữ liệu đặc tả: một đại diện cho mức cao nhất của các tập tin ban đầu (ngăn dữ liệu 0); một đại diện cho khung Tiêu đề JP2; và một đại diện cho dòng mã. Sự phân chia này được thể hiện trong Hình A.7.

Trong khi các nội dung của ngăn dữ liệu đặc tả bất kỳ sẽ là nội dung của khung hoặc tập tin được biểu diễn bởi ngăn đó, các dữ liệu thực tế có trong những nội dung có thể thay đổi tùy thuộc vào loại khung. Ví dụ, ngăn dữ liệu đặc tả 1 trong Hình A.7, biểu diễn cho nội dung của khung Tiêu đề JP2, nội dung của khung đó thực ra là một loạt các khung hoàn chỉnh khác do khung Tiêu đề JP2 là một siêu khung. Không có dữ liệu nào khác những khung hoàn chỉnh được tìm thấy trong ngăn dữ liệu đặc tả 1, vì không có dữ liệu khác trong khung Tiêu đề JP2. Ngược lại, các dữ liệu bên trong ngăn dữ liệu đặc tả 2 là nội dung thô của khung Dòng mã Liền kề, không có tiêu đề khung, bởi vì khung đó không phải là một siêu khung.

Một điểm đặc biệt quan tâm được chú ý từ ví dụ trong Hình A.7 là việc truy cập dữ liệu dòng mã được cung cấp theo hai cách. Khung Chờ ngăn thứ hai được sử dụng để thay thế các khung Dòng mã Liền kề (jp2c) trong tập tin ban đầu. Nó nhận dạng ngăn dữ liệu đặc tả 2 nắm giữ các nội dung ban đầu của khung này, ví dụ, dòng mã thô chính nó. Để thuận tiện cho việc mô tả trong tiêu chuẩn này, điều này được gọi là biểu diễn “dòng mã thô”. Dòng mã thô được phục vụ từ ngăn dữ liệu đặc tả.

Hình A.7 – Tập tin JP2 mẫu chia thành ba ngăn dữ liệu đặc tả

Khung Chờ cũng có thể cung cấp định danh dòng mã. Bất kỳ ngăn dữ liệu thuộc tiêu đề chính, tiêu đề khối ảnh, phân khu ảnh, hoặc các lớp ngăn dữ liệu khối ảnh có cùng định danh dòng mã này, truyền tải dữ liệu nén kết hợp với các dòng mã tìm thấy trong ngăn dữ liệu đặc tả 2. Để thuận tiện cho mô tả tiêu chuẩn này, nó được gọi là biểu diễn “dòng mã tăng dần”. Dòng mã tăng dần được phục vự từ các ngăn dữ liệu.

Nói chung, các khung Chờ tham chiếu dữ liệu dòng mã bằng cách tham chiếu một ngăn dữ liệu đặc tả riêng biệt (dòng mã thô), hoặc bằng cách cung cấp định danh dòng mã (dòng mã tăng dần), hoặc cả hai. Thậm chí nếu cung cấp cả hai phương pháp, dữ liệu dòng JPP hoặc dòng JPT có sẵn tại máy khách hoặc chương trình chạy ngầm kiết xuất ảnh có các nội dung của dòng mã thô, hoặc có dữ liệu từ dòng mã tăng dần. Hơn nữa, nếu cả hai phiên bản thô và gia tăng của dòng mã có sẵn, không đảm bảo rằng hai biểu diễn sẽ có các thông số mã hóa tương thích. Chỉ có các mẫu tái tạo hình ảnh liên quan đến hai biểu diễn được đảm bảo phù hợp.

Nó cũng có thể sử dụng khung Chờ để kết hợp nhiều dòng mã với một khung gốc duy nhất. Việc biên dịch của ràng buộc này phụ thuộc vào khung được thay thế. Vấn đề này được thảo luận thêm trong Điều A.3.6.4.

Trong ví dụ đơn giản Hình A.7, các khung Chờ chỉ xuất hiện ở các mức cao nhất của tập tin, trong ngăn dữ liệu đặc tả 0. Như đã lưu ý, các khung Chờ có thể được sử dụng để thay thế khung bất kỳ, trong ngăn dữ liệu đặc tả bất kỳ. Điều này cho phép các tập tin phức tạp được giải nén dưới hình thức phân cấp. Như vậy, một tập tin ban đầu duy nhất có thể được đóng gói trong một loạt các cấu trúc ngăn dữ liệu đặc tả khác nhau, tùy thuộc vào cách sử dụng khung Chờ. Tuy nhiên, dòng JPP hoặc dòng JPT đơn sẽ tương thức với một sự đóng gói như vậy. Trong các ứng dụng khách – chủ, máy chủ sẽ thường xác định cấu trúc ngăn dữ liệu đặc tả thích hợp cho các tập tin, gán một định danh duy nhất cho các dòng kết quả, và sử dụng cùng các cấu trúc ngăn dữ liệu đặc tả cùng trong tất cả các giao tiếp với tất cả các máy khách cùng tham chiều đến một định danh duy nhất.

Khi một khung Chờ định vị lại khung vào một ngăn dữ liệu đặc tả mới, tiêu đề khung (trường LBox, TBox và XLBox) sẽ được lưu trữ nguyên vẹn trong khung Chờ. Nếu một máy khách hoặc chương trình chạy ngầm kiết xuất ảnh cần ánh xạ các khung cụ thể vào độ dịch tập tin ban đầu, nó có thể làm như vậy bằng cách sử dụng tiêu đề khung gốc xuất hiện trong các khung Chờ. Thông tin này cho phép bất kỳ vị trí nào trong tập tin ban đầu sẽ được ánh xạ tới một vị trí cụ thể trong ngăn dữ liệu đặc tả cụ thể nếu nội dung của ngăn dữ liệu tồn tại. Điều này rất quan trọng vì một số các tập tin họ tiêu chuẩn JPEG 2000 chứa các khung tham chiếu đến khung khác thông qua vị trí của chúng trong tập tin.

Trong khi tự do quyết định cách tốt nhất để chia một tập tin thành các ngăn dữ liệu đặc tả, thì có một hạn chế. Bất kỳ khung Chờ xuất hiện bên trong ngăn dữ liệu đặc tả thay thế khung mức cao trong ngăn dữ liệu. Tương tự, bất cứ vị trí nào một khung con được thay thế bằng một khung Chờ, thì nó ngay lập tức có chứa siêu khung tức nó sẽ cư trú trong ngăn dữ liệu đặc tả của riêng mình. Ví dụ, trong các tập tin mẫu được hiển thị trong Hình A.6, dữ liệu XML chứa trong các khung Tiêu đề JP2 có thể được đặt trong một ngăn dữ liệu riêng biệt từ các khung khác. Điều này cho phép máy chủ chỉ chuyển các ngăn dữ liệu thực sự cần thiết để giải mã và hiển thị hình ảnh, nếu dữ liệu XML được yêu cầu một cách rõ ràng. Một cấu trúc ngăn dữ liệu thích hợp được thể hiện trong Hình A.8.

Hình A.8 – Siêu khung với ngăn dữ liệu đặc tả tham chiếu

Sẽ là không hợp lệ, nếu khung Tiêu đề JP2 bị bỏ lại trong ngăn dữ liệu đặc tả 0, như trong hình A.9:

Hình A.9 – Phần không hợp lệ của tập tin trong ngăn dữ liệu đặc tả

CHÚ THÍCH: Một cách tương đương để diễn tả cùng một sự hạn chế này là như sau. Bất cứ khung Chờ nào thay thế một khung con, thì khung Chờ cũng thay thế khung chứa nó. Hạn chế này đảm bảo rằng nó luôn luôn là có thể cho một máy khách hoặc chương trình chạy ngầm kiết xuất ảnh khôi phục độ dài và vị trí của các khung ban đầu trong tập tin, ngay cả khi một số khung chưa được hiểu bởi máy khách.

Ngoài việc cung cấp các nội dung ban đầu của khung trong ngăn dữ liệu đặc tả riêng biệt, dòng JPP và JPT cũng được phép cung cấp biểu diễn thay thế của khung, không xuất hiện rõ ràng trong tập tin ban đầu. Các biểu diễn thay thế này được gọi là “tương đương dòng”. Ví dụ, các tập tin ban đầu có thể chứa khung tham chiếu chéo có khung danh sách phân mảnh thu thập một hoặc nhiều mảnh của tập tin để khôi phục lại khung Đặc tính Không gian màu. Trong khi máy khách hoặc chương trình chạy ngầm kiết xuất ảnh có thể thực hiện theo các con trỏ tập tin có liên quan để khôi phục lại khung Đặc tính Không gian màu, biểu diễn thuận tiện hơn của dòng JPP hoặc JPT có thể chứa một khung Chờ tham chiếu tới một ngăn dữ liệu chứa trong khung Đặc tính Không gian màu được khôi phục lại như một tương đương dòng. Để làm được điều này, khung Chờ bao gồm một tiêu đề khung cho các tương đương dòng, cùng với đình danh ngăn dữ liệu đặc tả chứa nội dung của khung tương đương dòng.

Ví dụ sau đây (xem Hình A.10) minh họa việc sử dụng các tương đương dòng cho các khung tham chiếu chéo. Trong trường hợp này, ngăn dữ liệu chứa các nội dung các tương đương dòng cũng được tham chiếu như nội dung ban đầu của khung khác. Trong khi điều này có thể sẽ là tình huống chung mà tập tin ban đầu chứa khung tham chiếu chéo, không có nhu cầu cho các tương đương dòng trỏ đến ngăn dữ liệu đặc tả được kết nối với phân cấp tập tin ban đầu. Nội dung các tương đương dòng của khung có thể được tạo ra từ điểm bắt đầu hoặc chúng có thể đề cập đến nội dung tồn tại ban đầu trong tập tin khác. Điều này cho phép khung tham chiếu chéo chứa danh sách phân mảnh tham chiếu đến các tập tin khác hoặc các URL khác được đóng gói đầy đủ trong một dòng JPP hoặc dòng JPT đơn.

Tương đương dòng có thể được sử dụng trong bất kỳ tình huống nào mà các máy chủ có thể tạo ra một hình thức thay thế các nội dung của một khung cung cấp một số lợi ích cho máy khách; chúng không chỉ cung cấp truy cập dữ liệu rõ ràng dữ liệu tham chiếu chéo.

Ngoài ra để trỏ đến dữ liệu khung thực tế hoặc tương đương, một khung Chờ có thể trỏ đến một hoặc nhiều dòng mã nơi mà các khung thay thế này tương đương với các dòng mã khác. Ví dụ, khung Dòng mã Liền kề có thể được thay thế bằng khung Chờ tham chiếu, ID của dòng mã tăng dần chứa trong khung Dòng mã Liền kề. Một ví dụ khác sẽ được thay thế khung Độ dịch Khúc dữ liệu trong tập tin Motion JPEG 2000 với khung Chờ xác định một mảng các ID dòng mã. Các ID dòng mã tham chiếu các dòng mã được trỏ đến bởi khung Độ dịch Khúc dữ liệu.

Hình A.10 – Ví dụ về việc sử dụng tương đương dòng

A.3.6.3 Định dạng khung Chờ

Hình A.11 minh họa định dạng của khung Chờ, bao gồm tiêu đề khung (không giống như định nghĩa của hầu hết các khung trong Phụ lục I và các phần khác của tiêu chuẩn này); nó được xác định theo cách này để nhấn mạnh rằng việc sử dụng các trường độ dài trong tiêu đề khung cho khung Chờ là hạn chế hơn so với các khung khác.

Hình A.11 – Cấu trúc khung Chờ

LBox: Đây là trường độ dài trình tự big endian 4-byte tiêu chuẩn của một khung. Giá trị khác 1 với khung Chờ, có nghĩa là không có khung XLBox.

TBox: Đây là trường kiểu khung 4-byte tiêu chuẩn cho của một khung. Giá trị kiểu cho khung Chờ sẽ là ‘phld’ (0x7068 6c64).

Flags: Trường này xác định những nhân tố trong khung Chờ chứa dữ liệu hợp lệ. Trường này được mã hóa như là một số nguyên trình tự big endian 4-byte. Giá trị hợp lệ của trường Flags được quy định tại Bảng A.3.

OrigID: trường này quy định các ngăn dữ liệu đặc tả ID chứa các nội dung của khung ban đầu tham chiếu đến khung Chờ này. Nó được mã hóa như là một số nguyên không dấu trình tự big endian 8-byte.

OrigBH: trường này quy định các tiêu đề ban đầu (LBox, TBox và XLBox, khi cần thiết) của khung ban đầu được tham chiếu bởi khung Chờ này. Chiều dài của trường này là 8 byte nếu trường LBox của tiêu đề khung ban đầu không bằng 1 và bằng 16 byte với giá trị khác.

EquivlD: trường này quy định các ngăn dữ liệu đặc tả ID chứa hình thức tương đương dòng của các nội dung của khung này. Trường này được mã hóa như là một số nguyên không dấu trình tự big endian 8-byte.

EquivBH: trường này quy định các tiêu đề của khung tương đương dòng (LBox, TBox và XLBox, khi cần thiết) của khung tham chiếu bởi khung Chờ. Độ dài của trường này là 8 byte nếu trường LBox của tiêu đề khung tương đương không bằng 1 và bằng 16 byte với giá trị khác.

CSID: trường này xác định ID của dòng mã đầu tiên kết hợp với khung thay thế. Đây là ID được kết hợp với tất cả các tiêu đề, ngăn dữ liệu phân khu ảnh hoặc khối ảnh được sử dụng để từng bước giao tiếp nội dung của dòng mã đầu tiên kết hợp với khung thay thế. Trường này được mã hóa như là một số nguyên không dấu trình tự big endian 8-byte.

NCS: Trường này xác định số lượng dòng mã trong mảng của nó tương đương với khung thay thế. Các giá trị ID dòng mã của các dòng mã chạy liên tục kế nhau từ giá trị cho trước theo quy định tại trường CSID. Trường này được mã hóa như là một số nguyên không dấu trình tự big endian 4-byte.

ExtendedBoxList: trường này không được thể hiện rõ trong Hình A.11. Trường NCS có thể được theo sau bởi một chuỗi các khung có chứa thông tin mở rộng từ máy chủ. Sự tồn tại của bất kỳ khung sau trường NCS sẽ được xác định thông qua một bit trong trường Flags. Tuy nhiên, không có khung mở rộng, cũng không phải bất kỳ cờ bit bổ sung, được định nghĩa tiêu chuẩn này. Máy khách phải bỏ qua khung bất kỳ trong ExtendedBoxList không được hiểu.

Một bit giá trị “x” trong Bảng A.3 chỉ ra rằng giá trị quy định bao gồm các trường hợp bit được thiết lập hoặc là “1” hoặc là “0”. Bit chỉ ra là “y” là không được sử dụng theo tiêu chuẩn này và được thiết lập là 0 bởi các máy chủ và được bỏ qua trên máy khách.

Không phải tất cả các trường được xác định cho khung Chờ cần phải xuất hiện trong mỗi khung Chờ. Theo gợi ý của các mũi tên trong Hình A.11, nếu khung tương đương hoặc ID dòng mã tăng dần không được cung cấp, các khung có thể được chấm dứt vào cuối của trường OrigBH. Tương tự như vậy, nếu ID dòng mã tăng dần được không cung cấp, các khung có thể được chấm dứt vào cuối của trường EquivBH, và nếu không cung cấp nhiều hơn một ID dòng mã tăng dần, các khung có thể được chấm dứt vào cuối của trường CSID.

Bảng A.3 – Các giá trị hợp lệ cho trường Flags của khung Chờ

Giá trị	Ý nghĩa
yyyy yyyy yyyy yyyy yyyy yyyy yyyy xxx1	Cung cấp truy cập tới các nội dung gốc trong khung này thông qua ngăn dữ liệu đặc tả được quy định trong trường OriglD.
yyyy yyyy yyyy yyyy yyyy yyyy yyyy xxx0	Không cung cấp truy cập tới các nội dung gốc trong khung này và giá trị trường OriglD sẽ bị bỏ qua.
yyyy yyyy yyyỵ yyyy yyyỵ yyyy yyyy xx1x	Cung cấp một khung tương đương dòng, chứa các nội dung trong ngăn dữ liệu đặc tả được quy định trong trường EquivlD.
yyyy yyyy yyyy yyyy yyyy yyyy yyyy xx0x	Không cung cấp một khung tương đương dòng, và các giá trị bất kỳ của trường EquivlD và EquivBH sẽ bị bỏ qua.
yyyy yyyy yyyy yyyy yyyy yyyy yyyy 01xx	Giá trị của trường NCS sẽ được xử lý nếu như thể nó được thiết lập bằng “1” không phục thuộc vào giá trị của trường đó khi trường đó xuất hiện.
yyyy yyyy yyyy yyyy yyyy yyyy yyyy 11xx	Cung cấp truy cập hình ảnh đại diện cho khung này bằng các dòng mà hóa gia tăng theo quy định của trường CSID và NCS.
yyyy yyyy yyyy yyyy yyyy yyyy yyyy x0xx	Khung Chờ này không cung cấp truy cập hình ảnh đại diện cho khung ban đầu bằng một dòng mã tăng dần, các trường CSID và NCS sẽ bị bỏ qua.
Các giá trị khác	Dành riêng cho ISO sử dụng

CHÚ THÍCH: Định nghĩa trên có nghĩa là khung Chờ có thể được rút ngắn sau khi trường được sử dụng cuối cùng, nhưng các khung trung gian, ngay cả khi không sử dụng, vẫn phải có mặt.

A.3.6.4 Tham chiếu dòng mã tăng dần với các khung Chờ

Bất cứ nơi nào tồn tại tiêu đề, ngăn dữ liệu phân khu ảnh hoặc khối ảnh, thì ID dòng mã của chúng sẽ xuất hiện trong khung Chờ trong ngăn dữ liệu thích hợp. Trường hợp ngoại lệ duy nhất cho yêu cầu này là dòng mã JPEG 2000 được triển khai, không nhúng vào trong một định dạng tập tin họ tiêu chuẩn JPEG 2000.

Các giá trị ID dòng mã xuất hiện trong khung Chờ có liên quan phải phù hợp với bất kỳ yêu cầu áp đặt bởi các định dạng tập tin có chứa chúng. Ví dụ, các tập tin JPX hình thức chỉ định một số thứ tự để các dòng mã được tìm thấy trong các khung Dòng mã Liền kề hoặc khung Bảng Phân mảnh, hoặc ở mức cao nhất của tập tin, hoặc trong các khung Đa Dòng mã. Dòng mã đầu tiên trong địa chỉ logic sẽ có ID là 0; tiếp theo ID dòng mã là 1;…

Khung Chờ tham chiếu nhiều ID dòng mã có thể được sử dụng duy nhất mà ý nghĩa của các dòng mã cũng được xác định bởi các kiểu khung đang được thay thế. Đối với các tập tin JPX, các khung khung Dòng mã Liền kề, Bảng Phân mảnh và Đa Dòng mã có thể được thay thế bằng khung Chờ chỉ ra ID dòng mã. Khung Chờ thay thế khung Dòng mã Liền kề, Bảng Phân mảnh có thể chỉ ra chỉ có một ID dòng mã duy nhất, trong khi Giữ chỗ thay thế khung Đa Dòng mã lại có thể chỉ ra nhiều ID dòng mã, tương ứng với số lượng dòng mã được tìm thấy trong khung.

A.3.6.5 Sử dụng các khung Chờ với MJ2

Tiêu chuẩn này xác định chỉ có hai loại khung thích hợp cho Giữ chỗ với các tập tin Motion JPEG 2000 (MJ2). Đặc biệt, hoặc khung Độ dịch Khúc dữ liệu (‘stco’ ) hoặc khung Độ dịch Khúc dữ liệu Lớn (‘co64’) có thể được thay thế khung Chờ trong đó xác định nhiều ID dòng mã.

Mỗi rãnh ghi trong tập tin MJ2 chứa chính xác một khung Độ dịch Khúc dữ liệu (hoặc ‘stco’ hoặc ‘co64‘) đó, kết hợp với các mẫu của khung Khúc dữ liệu (‘stsc’), phục vụ cho việc xác định vị trí của tất cả các khung Dòng mã Liền kề trong đường hình (track video). Nếu khung Độ dịch Khúc dữ liệu được thay thế bằng khung Chờ cung cấp một hoặc nhiều ID dòng mã, phải có chính xác một ID dòng mã cho mỗi khung Dòng mã Liền kề trong đường hình. Nếu mẫu trực quan khung Nhập liệu (‘mjp2‘) xác định một trường đếm từ 2, phải có 2N ID dòng mã trong phạm vi cung cấp bởi khung Chờ, trong đó N là số lượng mẫu hình (ví dụ, N là số lượng khung hình). Nếu không, chỉ có N ID dòng mã trong phạm vi cung cấp bởi các khung Chờ. Các ID dòng mã được sắp đặt theo số thứ tự mẫu (số khung) và theo số tứ tự trường trong mỗi mẫu.

CHÚ THÍCH: Đối với các tập tin MJ2 trong biểu diễn dòng JPP hoặc dòng JPT, không cần thiết các dòng chứa nội dung của khung Độ dịch Khúc dữ liệu ban đầu, các mẫu thuộc khung Khúc dữ liệu (‘stsc‘), hoặc khung Kích thước Mẫu (‘stsz’). Thông tin chỉ mục này có thể được sử dụng lại khi cần thiết nếu biểu diễn dòng được chuyển đổi thành một tập tin MJ2.

A.4 Quy ước phân tích và chuyển tiếp dòng JPP và dòng JPT (tham khảo)

Các khung Chờ tạo ra sự linh hoạt bổ sung và một số tiềm năng không rõ ràng cho cả máy khách và máy chủ trong cách chúng phân tích hay phát tán dòng JPP và JPT. Một máy chủ có thể chọn phân vùng khung ban đầu từ một tập tin họ tiêu chuẩn JPEG 2000 vào trong ngăn dữ liệu đặc tả sử dụng phạm vi kế hoạch bất kỳ, bằng cách giới thiệu khung Chờ tại các điểm thích hợp. Các máy chủ sẽ làm điều này một cách nhất quán để các ngăn dữ liệu kết hợp với một dòng JPP hoặc JPT có các nội dung danh nghĩa tương tự cho tất cả máy khách truy cập địa chỉ logic tương tự (có thể đủ điều kiện bởi một ID đích duy nhất), bất cứ khi nào chúng truy cập vào nó.

Quan trọng hơn, các khung Chờ cho phép các máy chủ xây dựng một dòng JPP hoặc JPT có ngăn dữ liệu cung cấp nhiều biểu diễn thay thế cho nội dung ban đầu giống nhau. Điều này có thể xảy ra khi một tương đương dòng được xác định trong khung Chờ, và / hoặc khi một ID dòng mã tăng dần được xác định trong khung Chờ. Trong những trường hợp này, khung ban đầu có thể được cung cấp trong ngăn dữ liệu đặc tả, trong khi đang được thực hiện như là một tương đương dòng, bằng một ngăn dữ liệu đặc tả khác, hoặc đang được thực hiện như là một dòng mã tăng dần thông qua tiêu đề, ngăn dữ liệu phân khu ảnh, khối ảnh. Trong khi các máy chủ có thể phân phối các nội dung của tất cả các ngăn dữ liệu đại diện cho khung ban đầu, vì lý do hiệu quả các máy chủ sẽ dự kiến phân phối thông tin chỉ đủ để chuyển tải các nội dung ban đầu, trừ khi có yêu cầu phân phối dự phòng ngăn dữ liệu. Phân tích cú pháp phía máy khách của dòng JPP hoặc JPT, khi phải đối mặt với nhiều biểu diễn của khung ban đầu, có thể lựa chọn bỏ qua tất cả, hoặc một trong các biểu diễn. Quy ước trên máy khách dự kiến sẽ có một tác động đáng kể đến ngăn dữ liệu đặc tả trên máy chủ lựa chọn để thực sự gửi cho máy khách.

Với quan điểm này, tiêu chuẩn này khuyến cáo các quy ước sau:

– Trừ khi một máy chủ có lý do để tin rằng nếu không, nó sẽ giả định rằng phân tích cú pháp của máy khách sẽ phân tích một khung tương đương dòng ưu tiên cho khung ban đầu nếu sự hiện diện của cả hai loại khung đã được báo hiệu cho máy khách bằng các khung Chờ

– Trừ khi một máy chủ có lý do để tin rằng nếu không, nó sẽ giả định rằng phân tích cú pháp của máy khách sẽ sử dụng các biểu diễn dòng mã tăng dần (tiêu đề, ngăn dữ liệu phân khu ảnh, khối ảnh) ưu tiên cho một dòng mã thô nếu sự hiện diện của cả hai loại khung đã được báo hiệu máy khách bằng các khung Chờ.

A.5 Quy ước khả năng tương tác cho dòng JPP và dòng JPT (tham khảo)

Quy ước này mô tả các định dạng tập tin để trao đổi cho dòng JPP và JPT, ở đây gọi là tập tin JPP và JPT tương ứng. Một tập tin có thể chứa dữ liệu JPEG 2000 đã nhận từ một phiên JPIP (bộ nhớ đệm của máy khách chẳng hạn), hoặc một tập con của nó. Nó có thể cho một máy khách JPIP khác đọc và sử dụng tập tin này vì dòng JPP và dòng JPT là các kiểu phương tiện truyền thông tự mô tả.

Những tập tin này được hình thành bởi kết nối của các bản tin dòng JPT hoặc dòng JPP. Ví dụ, họ có thể được hình thành bởi các ghép nối đơn giản của tất cả các bản tin như vậy mà một máy khách nhận được trong một phiên duy nhất hoặc từ nhiều phiên. Một tình huống cải tiến sẽ là nơi các máy khách tạo ra một dòng JPT hoặc JPP hợp lệ sử dụng Tiêu đề Bản tin và Bản tin cho mỗi ngăn dữ liệu.

Quy ước khuyến cáo rằng phần mở rộng “.jpp” và “.jpt” được sử dụng cho những tập tin này nếu thích hợp, tên tập tin bao gồm tham chiếu đến một thẻ target hoặc target-id của JPIP liên quan.

Quy ước này không quy định việc thực hiện hoặc cấu trúc của bộ nhớ đệm cho máy khách. Ví dụ, một máy khách có thể sử dụng một cơ sử dữ liệu để phục vụ như việc thực hiện các chức năng lưu đệm hơn là hệ thống lưu đệm dựa trên tập tin.

Phụ lục B

(Quy định)

Phiên, kênh, mô hình bộ nhớ đệm và tập mô hình

B.1 Các yêu cầu có trạng thái (bên trong một phiên) và các yêu cầu phi trạng thái

Giao thức JPIP phân biệt rõ ràng giữa hai loại yêu cầu khác nhau: yêu cầu phi trạng thái và các yêu cầu trong một phiên.

Mục đích của các phiên là để giảm số lượng của giao tiếp rõ ràng cần thiết giữa máy khách và máy chủ. Trong một phiên, máy chủ dự kiến sẽ ghi nhớ khả năng và ưu tiên của máy khách cung cấp trong yêu cầu trước đó để thông tin này không cần phải gửi mọi yêu cầu. Quan trọng hơn nữa, các máy chủ có thể giữ một bản ghi dữ liệu để biết máy khách đã nhận được và các thông tin này không cần phải gửi lại để đáp ứng với yêu cầu trong tương lai. Bản ghi này sau đó được gọi là mô hình bộ nhớ đệm. Mô hình bộ nhớ đệm thường được kéo dài trong suốt thời gian của một phiên. Trừ khi có chỉ dẫn rõ ràng, máy vào bộ đệm dữ liệu đáp ứng của tất cả các yêu cầu trong một phiên và mô hình bộ đệm này để máy chủ chỉ gửi đi những phần của dữ liệu ảnh nén và dữ liệu đặc tả không có trong bộ đệm của máy khách.

Các yêu cầu phi trạng thái không liên kết với bất kỳ phiên nào và như vậy sẽ hoàn toàn khép kín. Cần lưu ý rằng thuật ngữ “phi trạng thái” chỉ áp dụng cho các máy chủ, không phải là máy khách. Đối với phiên, máy khách thường phải lưu đệm các đáp ứng từ yêu cầu trước đó liên quan đến địa chỉ logic. Máy khách phát ra nhiều yêu cầu phi trạng thái cho cùng một địa chỉ chung nên bao gồm thông tin về nội dung bộ nhớ đệm của chúng với mỗi yêu cầu, để tránh việc truyền tải dữ liệu dư thừa. Như vậy, lợi ích là phiên sẽ ngắn hơn, yêu cầu ít phức tạp và dữ liệu đáp ứng từ máy chủ ít dư thừa. Lợi ích của giao tiếp phi trạng thái là máy chủ không cần phải duy trì thông tin trạng thái giữa các yêu cầu; điều này có nghĩa là cùng một máy chủ không cần phục vụ tất cả các yêu cầu cho một hình ảnh đích duy nhất mà bắt nguồn từ một máy khách.

B.2 Kênh và phiên

Các yếu tố sau đây được kết hợp với mỗi phiên:

– Một hoặc nhiều địa chỉ logic (thường là tập tin hình ảnh), có nội dung không thay đổi so với phiên.

– Một kiểu dữ liệu ảnh trả về duy nhất cho mỗi địa chỉ logic liên quan đến phiên.

– Đối với mỗi địa chỉ logic kết hợp với phiên, một mô hình cho nội dung bộ nhớ đệm của máy khách phải được duy trì bất cứ nơi nào các kiểu dữ liệu trả về là một trong những “dòng JPP” hoặc “dòng JPT”. Lưu ý, mô hình này không cần phải hoàn hảo, phản ánh tình trạng thực tế của bộ nhớ đệm trên máy khách. Quy tắc về việc bảo trì các mô hình bộ nhớ đệm được nêu trong Điều B.3.

– Một hoặc nhiều kênh JPIP. Máy khách nói chung có thể mở nhiều kênh trong cùng một phiên. Mỗi kênh JPIP có thể được liên kết với một kênh truyền tải lớp dưới riêng biệt (ví dụ, một kết nối TCP riêng), mặc dù điều này có thể không phải là cá biệt. Nhiều kênh cho phép máy khách phát đi yêu cầu đồng thời cho nhiều vùng ảnh, với hy vọng rằng các máy chủ sẽ đáp ứng những yêu cầu này đồng thời. Các kênh cũng cho phép phân bổ băng thông thông minh giữa các loại khác nhau của các yêu cầu hoặc trong một hình ảnh đích đơn lẻ hoặc thông qua nhiều đích.

– Trường hợp nhiều kênh khác nhau có liên quan đến cùng một địa chỉ logic, mô hình bộ nhớ đệm cho phiên được áp dụng trên tất cả các kênh. Nhiều máy khách có thể mở các kênh JPIP trong cùng một phiên, mặc dù điều này có thể có tác dụng phụ không mong muốn nếu các kênh tham chiếu cùng một địa chỉ logic.

Các yếu tố sau đây được kết hợp với mỗi kênh:

– Một địa chỉ logic duy nhất (thường là một tập tin hình ảnh).

– Một định danh gán với máy chủ sẽ được bao gồm trong mỗi yêu cầu. JPIP không định nghĩa một định danh phiên riêng biệt, do định danh kênh đủ để kết hợp các yêu cầu cho phiên.

– Một bản ghi khả năng và ưu tiên của máy khách, có thể được điều chỉnh thông qua các trường yêu cầu thích hợp.

– Trong phạm vi mà hàng đợi máy chủ yêu cầu, nó sẽ cung cấp một hàng đợi riêng cho mỗi kênh JPIP.

Có một sự tương quan một-một cho các yêu cầu của máy khách và đáp ứng của khách hàng trên một kênh. Các kênh JPIP khác nhau có thể trên cùng một kênh truyền tải hoặc trên các kênh truyền tải khác nhau. Các yêu cầu sử dụng các kênh JPIP khác nhau có thể đến không đồng bộ với máy chủ nếu các sử dụng các kênh truyền tải riêng để vận chuyển các yêu cầu. Các đáp ứng sử dụng các kênh JPIP khác nhau có thể đến không đồng bộ với máy khách nếu sử dụng các kênh truyền tải riêng để vận chuyển các đáp ứng. Phục vụ của nhiều kênh là quyết định của máy chủ, tuy nhiên, các trường yêu cầu tỷ lệ phân phối và băng thông tối đa và ưu tiên băng thông được hướng dẫn cho các máy chủ.

B.3 Quản lý mô hình bộ nhớ đệm

Như đã đề cập, một trong những chức năng chính của một phiên là các mô hình phía máy chủ của bộ nhớ đệm máy khách. Trừ khi thông báo rõ ràng, máy chủ có thể giả định rằng máy khách lưu trữ tất cả thông tin được gửi để đáp ứng yêu cầu trong phiên: thông tin này không cần phải được gửi lại. Lưu ý, các máy chủ không có nghĩa vụ duy trì mô hình bộ nhớ đệm đầy đủ hoặc mô hình bộ nhớ đệm bất kỳ ở tất cả: dữ liệu dư thừa có thể được truyền để đáp ứng yêu cầu.

Ngoài tác động của dữ liệu truyền, các câu lệnh thao tác mô hình bộ nhớ đệm rõ ràng trong các yêu cầu của máy khách có thể cập nhật mô hình bộ nhớ đệm của máy chủ. Các báo cáo này sẽ được xử lý trước khi xác định dữ liệu đó phải được trả về cho máy khách để đáp ứng với yêu cầu của nó. Có hai loại câu lệnh thao tác mô hình bộ nhớ đệm: Thêm và bớt.

Câu lệnh thao tác thêm vào mô hình bộ nhớ đệm phục vụ để tăng cường mô hình bộ nhớ đệm của máy chủ, thêm ngăn dữ liệu, hoặc các phần của ngăn dữ liệu vào mô hình hiện tại. Chúng cung cấp một cơ chế cho máy khách để thông báo cho máy chủ về thông tin mà nó nhận được trong phiên trước đó, hoặc sử dụng các yêu cầu phi trạng thái trước đó. Một máy chủ nên cố gắng khai thác câu lệnh thao tác thêm vào mô hình bộ nhớ đệm xuất hiện trong các yêu cầu của máy khác. Tuy nhiên, các máy chủ không bắt buộc phải duy trì mô hình bộ nhớ đệm đầy đủ, do đó, máy chủ có thể bỏ qua hoặc bỏ qua một phần, Câu lệnh thao tác thêm vào mô hình bộ nhớ đệm

Câu lệnh bớt phục vụ việc loại bỏ ngăn dữ liệu, hoặc các phần của ngăn dữ liệu từ mô hình bộ nhớ đệm của máy chủ. Một máy khách có thể phát đi câu lệnh thao tác bớt đi mô hình bộ nhớ đệm để thông báo cho máy chủ rằng nó đã không được lưu trữ hoặc đã bỏ đi một số dữ liệu mà trước đây đã được gửi cho các máy chủ. Các máy chủ tự do giả định rằng máy khách đã lưu trữ tất cả dữ liệu truyền trong phiên. Các máy chủ sẽ loại bỏ tất cả các thông tin xác định bởi câu lệnh thao tác bớt đi mô hình bộ nhớ đệm từ bất kỳ mô hình bộ nhớ đệm (hoàn chỉnh hay cách khác) rằng nó được duy trì.

Yêu cầu JPIP dựa trên phiên có các tác dụng phụ, có thể ảnh hưởng đến đáp ứng các yêu cầu trong tương lai. Điều này cũng đúng với các yêu cầu có chứa câu lệnh thao tác mô hình bộ nhớ đệm – ảnh hưởng của thao tác mô hình bộ nhớ đệm là liên tục. Hơn nữa, tác dụng phụ của yêu cầu đến kênh JPIP được phản ánh trong đáp ứng với bất kỳ yêu cầu có thể thuộc về một kênh JPIP khác được kết hợp với cùng một địa chỉ logic. Điều này xuất phát từ thực tế là chỉ có một mô hình bộ nhớ đệm cho mỗi địa chỉ logic trong một phiên.

B.4 Truy vấn và thao tác tập mô hình

Khi một địa chỉ logic kết hợp với một phiên có chứa một số lượng lớn các dòng mã (ví dụ, địa chỉ hình ảnh), hoặc một máy khách vẫn còn kết nối trong một thời gian dài, một phần mô hình bộ nhớ đệm trở thành một chiến lược ngày càng có khả năng cho việc triển khai máy chủ thực tế. Nó cũng trở nên ngày càng có khả năng là do máy khách sẽ không thể lưu đệm tất cả thông tin được gửi bởi máy chủ. Đề tránh giao tiếp thiếu hiệu quả trong hoàn cảnh như vậy, khái niệm về một “mset” (model-set) được giới thiệu. Các “mset” là tập hợp của các dòng mã mà nội dung bộ nhớ đệm của máy khách được được mô hình hóa bởi các máy chủ.

Trong yêu cầu bất kỳ, máy khách có thể hướng dẫn máy chủ để hạn chế “mset” của mình cho một tập các dòng mã. Điều này cung cấp một cơ chế thuận tiện cho máy khách loại bỏ toàn bộ các dòng mã từ bộ nhớ đệm của chúng mà không cần chạy, các nguy cơ máy chủ sẽ tạo ra các đáp ứng đầy đủ cho các yêu cầu trong tương lai của các dòng mã.

Các yêu cầu “mset” là kết quả của các đáp ứng máy chủ chỉ ra tập thực tế của các dòng mã để duy trì thông tin mô hình bộ nhớ đệm. Điều này cho phép máy khách xác định có hay câu lệnh thao tác mô hình bộ nhớ đệm trong đó đề cập đến một loạt các dòng mã được bỏ qua bởi máy chủ.

Trong trường hợp không có bất kỳ truy vấn hoặc thao tác “mset” rõ ràng nào, máy khách có thể giả định rằng “mset” của máy chủ chỉ bao gồm tất cả các dòng mã tạo ra các dữ liệu đáp ứng theo yêu cầu của mình. Do các máy chủ nói chung có quyền giới hạn phạm vi yêu cầu của máy khách với số lượng dòng mã nhỏ hơn số ban đầu cho trước, không có đảm bảo rằng “mset” của máy chủ sẽ bao gồm tất cả các dòng mã đề cập trong một yêu cầu, trừ khi yêu cầu chỉ đề cập đến một dòng mã. Những vấn đề này được giải thích thêm trong Điều C.8.6.

Phụ lục C

(Quy định)

Yêu cầu của máy khách

C.1 Cú pháp yêu cầu

C.1.1 Tổng quan

Phụ lục này mô tả tất cả các yếu tố có thể có trong một yêu cầu JPIP. Mỗi điều khoản nhỏ mô tả một nhóm các trường và các giá trị có thể cho các trường này. Nói chung, một yêu cầu sẽ bao gồm các trường từ nhiều nhóm, nhưng cũng có một số nhóm không tương thích. Trong mỗi nhóm, cũng có một số trường yêu cầu không phù hợp. Một số yêu cầu hợp lệ khác có thể không có giá trị sử dụng trong một số trường hợp (chẳng hạn, như các phiên), mặc dù điều này không được chỉ ra bởi các cú pháp BNF. Cuối cùng, ngay cả với một yêu cầu phù hợp, một máy chủ có thể không thực hiện tất cả các trường yêu cầu có thể hoặc kết hợp there-of, nhưng nó phải phân tích và biên dịch tất cả các trường yêu cầu và đáp ứng chính thức một cách thích hợp, ngay cả khi đáp ứng lỗi. Thông tin chi tiết về những gì máy chủ dự kiến để thực hiện được quy định tại Phụ lục J.

CHÚ THÍCH: Những đáp ứng hoặc các phương pháp báo hiệu lỗi phụ thuộc vào các lớp truyền tải được sử dụng. Điều D.1 cung cấp các ví dụ về các máy chủ sử dụng HTTP như là giao thức truyền dẫn.

C.1.2 Cấu trúc yêu cầu

Yêu cầu, JPIP bao gồm các trường sau đây:

– Các trường xác định Địa chỉ;

– Các trường quản lý kênh và phiên;

– Các trường yêu cầu Cửa sổ hiển thị;

– Trường dữ liệu đặc tả;

– Các trường yêu cầu hạn chế dữ liệu;

– Các trường yêu cầu điều khiển máy chủ;

– Các trường yêu cầu quản lý bộ nhớ đệm;

– Các trường yêu cầu tải lên;

– Các trường tham chiếu và năng lực của máy khách.

Các thành phần trong yêu cầu sẽ được gửi phù hợp với các giao thức truyền tải được chọn. Ví dụ, trong HTTP, các yêu cầu được thể hiện bằng các ký tự được liệt kê trong cú pháp BNF, nhiều tham số được kết hợp bởi ký tự “&”, và các yêu cầu có thể là một phần của trường truy vấn của yêu cầu GET, hoặc phần thân của yêu cầu POST. Xem phụ lục F, G và H để biết thêm chi tiết.

Các trường trong yêu cầu được gửi phù hợp với các giao thức truyền tải được chọn. Ví dụ, trong HTTP, các yêu cầu có thể là một phần của trường truy vấn của yêu cầu GET, hoặc phần thân của yêu cầu POST, với các trường yêu cầu riêng phân tách với nhau bởi ký tự “&” (xem Phụ lục F, G và H để biết thêm chi tiết). Trong ngữ cảnh như thế này, một số ký tự được tìm thấy trong cú pháp BNF hoặc các tham số yêu cầu phải thoát ra để tránh sự nhập nhằng. Ví dụ, một trường yêu cầu có dạng “target=me&my dog” trong ngữ cảnh HTTP nên được chuyển ngữ thành “target=me%26my%20dog”, để tránh nhầm lẫn với “&” được sử dụng để phân tách các trường yêu cầu. Một ví dụ khác, “metareq=[roid/w]” trong ngữ cảnh HTTP nên chuyển ngữ thành “metareq=%5broid/w%5d” để tránh việc sử dụng ký tự non-URI (xem IETF RFC 2396 để biết thêm trên về các ký tự dành riêng), làm rõ nghĩa và chuyển ngữ qua quá trình mã hóa hex-hex. Phân tích cú pháp của các yêu cầu được tìm thấy trong ngữ cảnh như vậy cần được chuẩn bị để thực hiện giải mã hex-hex của từng trường yêu cầu.

C.1.3 Các giới hạn trên các trường yêu cầu kết hợp

Mỗi loại trường yêu cầu JPIP sẽ xuất hiện không quá một lần trong một yêu cầu.

Nhìn chung, các yêu cầu về dữ liệu hình ảnh (các yêu cầu Cửa sổ hiển thị) có thể được kết hợp với các yêu cầu bổ sung dữ liệu đặc tả. Tuy nhiên, có những hạn chế về cách kết hợp các trường yêu cầu.

Trường yêu cầu tải lên sẽ không được kết hợp với metadata-field hoặc data-limit-field hoặc server-control-field

C.2 Các trường xác định Địa chỉ

C.2.1 Giới thiệu về các địa chỉ logic

Mỗi yêu cầu JPIP hướng đến một đại diện cụ thể của tài nguyên được chỉ rõ nguồn gốc cụ thể hoặc một phần cụ thể của tài nguyên đó. Đó có thể là một tập tin hoặc đối tượng được lưu trữ vật lý, hoặc có thể là một cái gì đó được tạo ra chính thức bởi các yêu cầu trên máy chủ.

Các đại diện cụ thể, cho dù đó là hình thức mã hóa ban đầu hay hình thức chuyển mã, hoặc cho dù đó là một loạt byte cụ thể hay toàn bộ tài nguyên, được gọi là địa chỉ logic. Địa chỉ logic được xác định thông qua ba trường yêu cầu: ID Địa chỉ, Địa chỉ và Địa chỉ Phụ.

Trường yêu cầu Địa chỉ xác định tài nguyên được chỉ rõ nguồn gốc từ những yêu cầu trực tiếp. Nó được xác định bằng cách sử dụng PATH, có thể là một chuỗi đơn giản hoặc một URI. Nếu trường Địa chỉ không được xác định và yêu cầu được thực hiện qua HTTP (hay HTTPS), sau đó yêu cầu JPIP sẽ được hướng đến các tài nguyên xác định thông qua các thành phần đường dẫn URL của yêu cầu JPIP. Tài nguyên được chỉ rõ nguồn gốc này có thể là một tập tin thực tế hoặc đối tượng khác được lưu trữ trên máy chủ, hoặc nó có thể là một cái gì đó mà máy chủ tạo ra để đáp ứng với yêu cầu JPIP.

Các trường yêu cầu Địa chỉ Phụ xác định cụ thể phạm vi byte của tài nguyên được chỉ rõ nguồn gốc (xác định thông qua các trường yêu cầu Địa chỉ) mà yêu cầu được hướng tới. Nếu trường yêu cầu Địa chỉ Phụ không được xác định, các yêu cầu được gửi cho toàn bộ dãy byte của tài nguyên ban đầu.

Trường yêu cầu ID Địa chỉ có thể được sử dụng để tiếp tục xác định một quá trình mã hóa đặc biệt của tài nguyên trong trường hợp máy chủ và máy khách đã từng trao đổi dữ liệu từ các tài nguyên này. Ví dụ, máy chủ có thể đã từng cung cấp một phiên bản chuyển mã các tập tin cho máy khách dựa trên thông tin cung cấp và các điều kiện xung quanh một yêu cầu trước đó. Nếu máy khách đã lưu các dữ liệu trước đây đã truyền đi trong bộ nhớ đệm của nó, nó sẽ muốn tiếp tục nhận được dữ liệu bằng cách sử dụng cùng một mã để có thể tiếp tục sử dụng các dữ liệu trong bộ nhớ đệm. ID Địa chỉ là một chuỗi nhận diện dạng máy chủ xác định, mà các máy chủ trước đây đã liên kết với đại diện cụ thể đó của tài nguyên được chỉ rõ nguồn gốc cụ thể, hoặc một dãy byte của một số tài nguyên được chỉ rõ nguồn gốc cụ thể.

Nếu một máy khách xác định cả hai tài nguyên được chỉ rõ nguồn gốc (thông qua một trong hai trường yêu cầu Địa chỉ hoặc thông qua các thành phần đường dẫn URL của yêu cầu JPIP) và ID Địa chỉ, máy chủ sẽ xác minh có hay không có nó để có thể đáp ứng yêu cầu theo cách tương tự như khi nó được gán với ID Địa chỉ của nguồn tài nguyên đó. Nếu máy chủ không thể đáp ứng theo cách tương tự, nó sẽ sử dụng một tiêu đề đáp ứng JPIP-tid để thông báo cho máy khách của một ID Địa chỉ mới, lúc đó máy khách sẽ biết rằng nó phải loại bỏ bất kỳ dữ liệu được lưu trữ trước đó.

Nếu một địa chỉ logic dùng để phục vụ các bản tin dòng JPP hoặc dòng JPT, các ngăn dữ liệu liên quan sẽ vẫn phù hợp trong tất cả các đáp ứng được phát đi trong cùng một phiên. Trong trường hợp máy chủ, hoặc máy chủ có liên quan, cũng phát đi một ID Địa chỉ, thì các ngăn dữ liệu sẽ vẫn phù hợp trên tất cả các đáp ứng phát đi cùng một ID Địa chỉ, cho dù chúng có được phát đi trong cùng một phiên hay không.

Nếu trường yêu cầu ID Kênh được bao gồm trong yêu cầu, thì yêu cầu không cần phải bao gồm các trường ID Địa chỉ, Địa chỉ và Địa chỉ Phụ.

Các ví dụ sau đây cho thấy các đặc điểm kỹ thuật của các địa chỉ logic:

VÍ DỤ 1: Đối với URL của yêu cầu JPIP

“http://one.jpeg.org/imageserver.cgi?target=http%3A%2F%2Fone.jpeg.org%2Fimages%2Fpicture.jp2&fsiz=200.00” địa chỉ logic là toàn bộ dãy byte chứa trong các URI “http://one.jpeg.org/images/picture.jp2. ” liên quan đến thư mục tài liệu gốc máy chủ.

VÍ DỤ 2: Đối với URL của yêu cầu JPIP là

“http://one.jpeg.org/imageserver.cgi?target=http%3A%2F%2Fone.jpeg.org%2Fimages%2Fpicture.jp2&tid=4384-5849-af4d-3dca&fsiz=200.200” địa chỉ logic là toàn bộ dãy byte chứa trong các URI “http://one.jpeg.org/images/picture.jp2.” liên quan đến thư mục tài liệu gốc máy chủ, với một đạl diện được xác định bởi các máy chủ với ID Địa chỉ 4384-5849-af4d-3dca .

VÍ DỤ 3: Đối với URL của yêu cầu JPIP

“http://one.jpeg.org/imageserver.cgi?target=http%3A%2F%2Fone.jpeg.org%2Fimages%2Fpicture.jp2&subtarget=1.038-13.458&fsiz=200.200” địa chỉ logic là một loạt các byte, bắt đầu với byte 1038, và tất cả các byte lớn hơn và bao gồm byte 13458, chứa trong các URI “http://one.jpeg.org/images/picture.jp2.” liên quan đến thư mục tài liệu gốc máy chủ.

VÍ DỤ 4: Đối với URL của yêu cầu JPIP “http://one.jpeg.org/imageserver.cgi?cid=1234-5849-af4d-3dca&fsiz=200.200” địa chỉ logic là tài nguyên mà máy chủ đã liên kết với các kênh có ID 1234-5849-af4d-3dca.

VÍ DỤ 5: Đối với URL của yêu cầu JPIP “http://one.jpeg.org/images.jp2?fsiz=200.200” địa chỉ logic là toàn bộ phạm vi byte chứa trong các tập tin “lmages/picture.jp2″, liên quan đến thư mục tài liệu gốc máy chủ.

VÍ DỤ 6: Đối với URL của yêu cầu JPIP “http://one.jpeg.org/images/picture.jp2?subtarget=1038-13458&fsiz=200.200” địa chỉ logic là một loạt các byte, bắt đầu với byte 1038, và tất cả các byte lớn hơn và bao gồm byte 13458, chứa trong các tập tin “images/picture.jp2.” liên quan đến thư mục tài liệu gốc máy chủ.

C.2.2 Địa chỉ (target)

target = “target” “=” PATH

Trường này được sử dụng để chỉ ra tài nguyên được chỉ rõ nguồn gốc (thường là tên của một tập tin trên máy chủ). Nếu trường yêu cầu Địa chỉ bị mất thì các tài nguyên được đặt tên gốc sẽ được xác định bằng các phương tiện khác.

C.2.3 Địa chỉ Phụ (subtarget)

Trường này có thể được sử dụng để xác định tài nguyên được chỉ rõ nguồn gốc thông qua các đặc điểm kỹ thuật của một dãy byte hoặc một dãy các dòng mã trong tài nguyên ban đầu. Địa chỉ logic được hiểu là phạm vi byte chỉ định hoặc một loạt các dòng mã của tài nguyên được chỉ rõ nguồn gốc. Với mục đích của các yêu cầu và đáp ứng liên quan đến địa chỉ logic này, dòng mã trong địa chỉ này sẽ được gán các chỉ số liên tiếp bắt đầu từ số không.

CHÚ THÍCH: Việc xác định địa chỉ logic cho một loạt các dòng mã cần phải dán nhãn lại các dòng mã, và thay thế hiệu quả các chỉ số dòng mã, nếu có, trong tài nguyên được chỉ rõ nguồn gốc bằng các chỉ số liên tiếp bắt đầu từ số không.

Các giới hạn trên và dưới của dãy byte được cung cấp đã bao gồm, trong đó các byte hoặc các dòng mã được đếm từ không.

C.2.4 ID Địa chỉ (tid)

tid = “tid” “=” target-id

target-id = IDTOKEN

Trường này có thể được sử dụng để cung cấp một chuỗi target-id, mà trước đó đã được tạo ra bởi các máy chủ đề hoàn toàn xác định các địa chỉ logic đang được truy cập, bao gồm cả các mã tùy ý thực hiện bởi các máy chủ. Tên địa chỉ logic không cần thiết phải duy nhất và không cần thiết tương ứng với một quá trình mã hóa đơn nội dung của nó, trong khi chuỗi target-id, cùng với tên nguồn tài nguyên ban đầu và dãy byte, hoàn toàn xác định cho cả hình ảnh lẫn quá trình mã hóa của nó.

Nếu target-id là “0”, thì địa chỉ logic được xác định thông qua việc sử dụng Target, Sub-target và các thành phần đường dẫn URL của JPIP, và máy khách yêu cầu một cách rõ ràng rằng các máy chủ thông tin cho nó trong những targer-id được gán, nếu chỉ có một. Các máy chủ sẽ bao gồm tiêu đề Target ID trong đáp ứng của nó với tất cả các yêu cầu máy khách với một target-id là “0”.

target-id không được vượt quá 255 ký tự về độ dài.

C.3 Các trường làm việc với phiên và kênh

C.3.1 Tổng quan

Một yêu cầu sẽ là phi trạng thái trừ khi thỏa mãn một hoặc cả hai điều kiện sau đây:

– Yêu cầu bao gồm trường ID Kênh hợp lệ;

– Yêu cầu bao gồm trường Kênh Mới (xem bên đây), và đáp ứng máy chủ bao gồm tiêu đề đáp ứng Kênh Mới với channel-id mới phát đi.

Xem B.2 thảo luận về các phiên và các kênh.

C.3.2 ID Kênh (cid)

cid = “cid” “=” channel-id

channei-id = IDTOKEN

– Trường này được sử dụng để kết hợp yêu cầu với một kênh JPIP đặc biệt, và kể từ phiên bao gồm kênh đó.

C.3.3 Kênh Mới (cnew)

cnew = “cnew” “=” 1#transport-name

transport-name = TOKEN

Trường này được sử dụng để yêu cầu một kênh JPIP mới. Nếu không có trường yêu cầu ID Kênh được đưa ra, yêu cầu sẽ dành cho một phiên mới. Mặt khác, yêu cầu dành cho một kênh mới trong phiên tương tự như các kênh được xác định bởi trường yêu cầu ID Kênh.

Chuỗi giá trị nhận diện tên của một hoặc nhiều giao thức truyền tải mà máy khách sẵn sàng chấp nhận. Tiêu chuẩn này xác định chỉ sử dụng các tên giao thức truyền tải, “http”, “https”, “http-tcp”, và “http-udp”. Chi tiết về việc sử dụng JPIP qua giao thức truyền tải “http” xuất hiện trong Phụ lục F. Phụ lục G mô tả việc sử dụng JPIP qua giao thức truyền tải “http-tcp” và Phụ lục K mô tả việc sử dụng JPIP qua giao thức truyền tải “http-udp”.

Nếu máy chủ sẵn sàng để thiết lập một kênh mới, sử dụng một trong các giao thức vận chuyển được chỉ định, nó sẽ trả về thẻ định danh kênh mới bằng cách sử dụng đáp ứng tiêu đề Kênh Mới (xem D.2.3). Trong trường hợp này, yêu cầu hiện nay là yêu cầu đầu tiên trong kênh mới.

Nó là có thể cho một máy khách để mở một kênh cho một địa chỉ logic mới trong cùng một phiên. Để làm điều này, theo yêu cầu máy khách phải xác định cả ID Kênh hiện có, lẫn địa chỉ logic. Khi mở một kênh mới để có cùng một địa chỉ logic gắn với kênh hiện tại, không cần phải xác định địa chỉ logic một cách rõ ràng.

Nếu máy chủ không sẵn sàng để mở ra một kênh mới, nó sẽ không trả về đáp ứng tiêu đề Kênh Mới, nhưng yêu cầu được phục vụ như trường yêu cầu Kênh Mới đã không được bao gồm. Điều này có nghĩa rằng yêu cầu chỉ ra một ID Kênh hiện có sẽ được coi là một yêu cầu trong kênh, trong khi yêu cầu không bao gồm trường yêu cầu ID Kênh sẽ được coi là một yêu cầu phi trạng thái. Trong trường hợp yêu cầu Kênh Mới xác định một địa chỉ logic khác kết hợp với ID Kênh hiện có được cung cấp, máy chủ sẽ không thể đáp ứng yêu cầu mà không phát đi một ID Kênh mới hoặc trả lại một mã lỗi.

VÍ DỤ 1: “target=nice.jp2&cnew=http” yêu cầu kênh đầu tiên của một phiên mới cho hình ảnh “nice.jp2” sử dụng giao thức truyền tải “http”. Nếu không có kênh được chỉ định bởi máy chủ, yêu cầu sẽ được coi là phi trạng thái.

VÍ DỤ 2: “cid = 013ac8 & cnew = http-tcp” yêu cầu một kênh mới trong cùng một phiên liên kết với ID Kênh 013ac8. Các kênh mới sử dụng giao thức truyền tải “http-tcp” và đề cập đến địa chỉ logic như ID Kênh 013ac8. Một mô hình bộ nhớ đệm duy nhất được chia sẻ bởi các kênh này. Nếu không có kênh được chỉ định bởi các máy chủ, yêu cầu sẽ được xử lý như các trường yêu cầu Kênh Mới đã được bỏ qua.

VÍ DỤ 3: “target = nice.jp2 & cid = 013ac8 & cnew = http” yêu cầu một kênh mới trong cùng một phiên được kết hợp với ID Kênh “013ac8.” Các kênh mới sử dụng giao thức truyền tải “http”. Địa chỉ logic kết hợp với các kênh mới tách biệt từ đó kết hợp với ID Kênh “013ac8” và một mô hình bộ nhớ đệm riêng biệt được sử dụng cho các kênh mới. Các mô hình bộ nhớ đệm cho cả hai địa chỉ liên quan đến phiên dùng chung này.

C.3.4 Đóng Kênh (cclose)

cclose = “cclose” “=” (“*” / 1#channel-id)

Trường này được sử dụng để đóng một hoặc nhiều kênh đã mở cho một phiên. Nếu trường giá trị chứa một hoặc nhiều thẻ channel-id, thì tất cả đều thuộc cùng một phiên. Trong trường hợp này, không cần thiết các trường yêu cầu ID Kênh mới, nhưng nếu nó cung cấp cũng phải tham chiếu đến một kênh thuộc cùng một phiên.

Nếu trường có giá trị là “*”, tất cả các kênh liên quan đến phiên sẽ đóng. Trong trường hợp này, phiên được xác định bao gồm một trường yêu cầu ID Kênh.

Các máy chủ phải hoàn thành đáp ứng của nó trên bất kỳ kênh quy định trong yêu cầu Đóng Kênh trước khi thực sự đóng kênh.

CHÚ THÍCH: Không nên kết hợp của “wait = yes” với “cclose=*“. Nếu gặp phải tình trạng này, các ứng dụng có thể quyết định thực hiện một trong hai ưu tiên.

C.3.5 ID Yêu cầu (qid)

qid = “qid” “=” UINT

Trường này được sử dụng để xác định giá trị ID Yêu cầu. Mỗi kênh có yêu cầu xếp hàng đợi riêng của mình, với bộ đếm ID Yêu cầu của nó. Các máy chủ có thể xử lý các yêu cầu mà không chứa ID Yêu cầu yêu cầu, hoặc có ID Yêu cầu bằng không, trên một cơ sở đến trước được phục vụ trước. Tuy nhiên, nó sẽ không xử lý yêu cầu đến với giá trị ID Yêu cầu bằng n cho đến khi nó đã xử lý xong tất cả các yêu cầu với giá trị ID Yêu cầu từ n0 đến n-1. Ở đây n0 là qid cung cấp trong yêu cầu tạo ra các kênh, hoặc bằng 1 nếu không có qid khi tạo kênh.

CHÚ THÍCH: Đáp ứng một yêu cầu chứa cnew mà kết quả trong việc tạo ra một kênh mới được xử lý như yêu cầu được đưa ra trong các kênh mới. Điều này có nghĩa các yêu cầu tiếp theo với giá trị qid khác không được xử lý trong các kênh mới có giá trị qid bằng n0 + 1.

C.4 Các trường yêu cầu Cửa sổ hiển thị

C.4.1 Ánh xạ các yêu cầu Cửa sổ hiển thị đến các độ phân giải và vùng ảnh dòng mã

Mục đích của JPIP là cung cấp các phần của một hình ảnh JPEG 2000 và kết hợp dữ liệu đặc tả để đáp ứng yêu cầu của máy khách. Điều này được thực hiện thông qua một loạt các yêu cầu và đáp ứng. Đối với một phần hình ảnh, dữ liệu được yêu cầu ít hơn so với hình ảnh đầy đủ về kích thước khung, vùng, chất lượng, và các thành phần ảnh.

Trong trường hợp đơn giản, một phần hình ảnh trong câu hỏi được xác định trực tiếp trên phương diện lưới tọa độ tham chiếu có độ phân giải cao của các dòng mã JPEG 2000 được xác định trong yêu cầu, không phải lưới tọa độ lấy mẫu của bất kỳ thành phần hình ảnh đặc biệt nào. Tổng quát hơn, máy khách có thể yêu cầu các đối tượng hình ảnh mức cao hơn (ví dụ, các lớp hợp thành JPX hoặc các đường hình MJ2) thông qua các trường yêu cầu Ngữ cảnh Dòng mã (xem C.4.7). Trong trường hợp này, phần hình ảnh yêu cầu cần chủ động biến đổi tọa độ, nhằm xác định các phần của mỗi dòng mã liên quan được yêu cầu. Các phép biến đổi tọa độ được mô tả trong Điều C.4.7, và chúng được xem như là các mô tả sau đây của về các vùng ảnh dòng mã.

Hình C.1 – Vùng mong muốn trong một hình ảnh

Các vùng ảnh dòng mã được mô tả bằng cách sử dụng 3 tham số n-chiều trong đó n là số chiều yêu cầu để mồ tả hình ảnh này. Các thông số kích thước và các thông số độ lệch xác định độ lớn và vị trí của vùng ảnh dòng mã mong muốn đối với một hình ảnh hoàn chỉnh có kích thước khung cho trước. Hình C.1 minh họa điều này thiết lập hình ảnh chính thức với n = 2, cấu trúc sẽ mang lại tính tự nhiên với số chiều cao hơn. Đối với phần còn lại của Điều này, chúng ta sẽ chỉ xem xét trường hợp này, đặt tên kích thước khung là fx và fy, độ lệch của vùng ảnh là ox và oy và kích thước của vùng ảnh sx và sy được chỉ ra trong Hình C.1.

VÍ DỤ 1: Một máy khách có nhu cầu chiếm một vùng hiển thị 640×480 của hình ảnh hoàn chỉnh có thể thực hiện yêu cầu như sau: “fsiz=640,480&rsiz=640,480&roff=0,0″. Lưu ý rằng điều này có thể được thực hiện không phụ thuộc vào kích thước ban đầu của ảnh (và thực sự cũng không biết kích thước ban đầu của ảnh).

Khi không có sẵn các độ phân giải hình ảnh trong dòng mã JPEG 2000 tương ứng với kích thước khung yêu cầu, dữ liệu hình ảnh phản hồi có thể lớn hơn hoặc nhỏ hơn so với kích thước khung yêu cầu, và thậm chí có thể khác nhau về tỷ lệ. Máy chủ quyết định độ phân giải thích hợp của dòng mã, biểu diễn bằng các thông số kích thước fx’ và fy’, và vùng thích hợp trên dòng mã, biểu diễn bằng các thông số sx’, sy‘, ox’ và oy’, như thể hiện trong Hình C.2 . Mặc dù máy khách có thể hướng dẫn làm tròn, như một phần của trường yêu cầu Kích thước Khung hình, máy khách sẽ được chuẩn bị để đối phó với dữ liệu trả về không phù hợp với các thông số được yêu cầu chính xác.

Hình C.2 – Vùng mong muốn về khía cạnh lưới tọa độ tham chiếu được lấy mẫu phụ

Trong Hình C.2, kích thước của độ phân giải thích hợp của dòng mã được đưa ra bởi fx’ =Xsiz’ – XOsiz’ and fy‘ = Ysiz’ – YOsiz‘, trong đó XOsiz’, YOsiz’, Xsiz’, và Ysiz’ được tính bằng cách sử dụng Công thức C-1.

Trong đó:

(C-1)

Trong đó:

r được xác định bởi máy chủ để phù hợp với kích thước ảnh yêu cầu (fx và fy), tùy thuộc vào các mong muốn làm tròn được cung cấp thông qua trường yêu cầu Kích thước Khung hình.

Ở đây, XOsiz, YOsiz, Xsiz và Ysiz được lấy từ đoạn nhãn SIZ của dòng mã liên quan. Điều này bản chất là để giải thích r là số mức DWT cao nhất bị loại bỏ, và thực sự r phải là số nguyên lớn hơn hoặc bằng 0. Tuy nhiên, giá trị của r ris không bị giới hạn bởi số mức DWT được sử dụng để nén khối ảnh thành phần bất kỳ trong dòng mã.

Một khi kích thước khung phù hợp, fx’ và fy‘, đã được xách định, kích thước vùng, sx và sy, và độ lệch ox’ và oy‘, được kết hợp với vùng hình ảnh dòng mã xác định bởi công thức C-2.

(C-2)

VÍ DỤ 2: Giả thiết yêu cầu Định cơ Khung hình là 128x128, và hình ảnh trong lưới tọa độ tham chiếu độ phân giải cao của dòng mã được mô tả bởi XOsiz = 127, Xsiz = 648, YOsiz = 0 và Ysiz = 504. Giả thiết tồn tại 3 mức biến đổi sóng con cho tất cả các thành phần ảnh trong dòng mã. Các kích thước hình ảnh dòng mã có sẵn sẽ như sau:

Vì vậy, nếu yêu cầu dành cho kích thước khung lớn (round-direction là round-up) thì kích thước khung hình trả về sẽ là 260x252. Nếu yêu cầu dành là cho kích thước khung nhỏ (round-direction là round-down), thì kích thước khung hình 65x63 sẽ được sử dụng. Lưu ý, trong ví dụ này, kích thước khung hình dòng mã nói chung là không chính xác là lũy thừa của 2.

Lấy mẫu phụ thành phần hình ảnh, được xác định bởi XRsiz và YRsiz, không ảnh hưởng đến việc biểu diễn vùng ảnh yêu cầu hoặc độ phân giải ảnh trong dòng mã yêu cầu bất kỳ.

VÍ DỤ 3: Một yêu cầu vùng 256x256 từ góc trên bên trái của hình ảnh 512x512 có thể được thực hiện với: fsiz = 512,512 & rsiz = 256,256

Giả thiết dòng mã chứa hình ảnh được lấy mẫu phụ trong các thành phần ảnh 1 và 2 nhưng không có trong thành phần ảnh 0. Cụ thể, giả thiết Xsiz=1024, Ysiz=1024, XOsiz=0, YOsiz=0, và XRsiz0=1, YRsiz0=1, XRsiz1=2, YRsiz1=2, XRsiz2=2, and YRsiz2=2. Các máy chủ sẽ bỏ qua mức phân giải cao nhất của cả ba thành phần, và trả về các khối ảnh và phân khu ảnh đủ để cung cấp các mẫu 256x256 của thành phần ảnh 0, nhưng chỉ có các mẫu 128x128 của các thành phần ảnh 1 và 2. Máy khách có dữ liệu để hiển thị ở góc trên bên trái với kích thước bằng nửa kích thước hình ảnh hoàn chỉnh và vẫn được lấy mẫu phụ. Nếu máy khách muốn hiển thị các thành phần màu sắc không được lấy mẫu phụ, nó có thể phát đi một yêu cầu bổ sung như:

fsiz = 1024,1024 & rsiz = 512,512 & Comp = 1,2

Máy chủ sau đó sẽ trả về dữ liệu đầy đủ để cung cấp các mẫu 256x256 của các thành phần ảnh 1 và 2, được kết hợp với dữ liệu thành phần ảnh 0, dữ liệu đã nhận được để có được một hình ảnh không lấy mẫu phụ nhưng với kích thước một nửa.

Nếu tất cả ba thành phần ảnh đã được lấy mẫu phụ, máy chủ sẽ chỉ cung cấp các mẫu 128x128 cho cả ba thành phần ảnh của yêu cầu ban đầu (fsiz = 512,512 & rsiz = 256,256) do độ phân giải ảnh và các vùng ảnh được đánh giá đối với lưới tọa độ tham chiếu của mỗi dòng mã yêu cầu.

Các xem xét ở trên dành cho ảnh hai chiều, để mang lại tính tự nhiên phải tăng số chiều lên, ví dụ như, đối với trường hợp n = 3, trong đó tọa độ thứ ba được thêm vào mỗi nhóm tham số. Cụ thể, kích thước khung sau đó được biểu diễn bởi ba số fx, fy và fz, độ lệch bằng ox, oy và oz và kích thước vùng bằng sx, sy và sz. Trong trường hợp đó, Công thức C-1 được mở rộng thành:

Trong đó ZOsiz và Zsiz xác định độ lệch và kích thước canvas của ảnh ban đầu theo chiều Z, theo thứ tự. Phương trình C-2 được mở rộng thành:

Đối với các hình ảnh biểu diễn trong dòng mã của tiêu chuẩn ISO / IEC 15444-10, ZOsiz và Zsiz được lấy từ đoạn nhãn NSI có liên quan.

Ngoài ra, máy chủ có thể chọn để nhận diện dòng mã của tiêu chuẩn ISO / IEC 15444-2 bằng cách thực hiện biến đổi sóng con như là một biến đổi đa thành phần với hình ảnh lập thể, sử dụng các thành phần được tạo ra để biểu diễn chiều thứ ba (Z). Việc nhận diện bằng cách tạo ra các thành phần cấu thành từ các lát ảnh rời rạc của các máy chủ, và như vậy chọn ra các giá trị thích hợp cho ZOsiz và Zsiz. Trong trường hợp này, các máy khách có thể lựa chọn sử dụng cú pháp yêu cầu hai chiều hoặc ba chiều để lấy lại dữ liệu từ máy khách. Đối với yêu cầu hai chiều, đó là việc các máy khách xác định các lát ảnh với các thành phần ảnh và thực hiện những yêu cầu cần thiết; còn đối với các yêu cầu ba chiều, đó là nhiệm vụ của máy chủ để tìm các thành phần ảnh có liên quan đến ảnh lập thể được yêu cầu. Trong trường hợp này, các máy chủ không cần phải thực hiện các trường comp và mctres, xem C.4.5 và C.4.11, và cách sử dụng chúng không được khuyến khích cho trường hợp này.

Lưu ý áp dụng:

Trong trường hợp các máy chủ phải xác định tiêu chuẩn ISO / IEC 15444-2 mã hóa dữ liệu lập thể của hình ảnh, chúng được khuyến khích sử dụng những lựa chọn sau đây đối với ZOsiz và Zsiz cung cấp một cách hiệu quả và nhất quán cho các mức phân giải theo chiều Z:

• ZOsiz sẽ được xác định đến mức tối thiểu tất cả các giá trị Omcci trong các nhãn MCC trong dòng mã xác định bởi các yêu cầu, xem Phụ lục A.3.8 của tiêu chuẩn ISO / IEC 15444-2. Việc lựa chọn này đảm bảo xác định hợp lý cho các mức phân giải theo chiều Z tương thích với biến đổi sóng con ban đầu, và giảm bớt việc trích xuất các hình ảnh có độ phân giải thấp hơn từ dòng.

• Zsiz được xác định với số lượng lát ảnh xác định bằng các phương pháp mô tả dưới đây cộng với ZOsiz được tính toán bởi thủ tục trên.

Nên sử dụng các thủ tục sau đây để xác định các thành phần ảnh được tạo nên lát ảnh trong trường hợp tiêu chuẩn ISO / IEC 15444-2 phù hợp với định dạng tập tin có sẵn đối với địa chỉ yêu cầu:

• Xác định tất cả các lớp hợp thành của tập tin sử dụng dòng mã tại các địa chỉ yêu cầu. Mỗi lớp hợp thành trong tập này xác định chính xác một lát ảnh của ảnh lập thể. Tọa độ Z được gán với lớp hợp thành đầu tiên trong tập hợp này ZOsiz, như được định nghĩa ở trên, và tất cả các lát ảnh sau được gán vào tọa độ Z liên tục tăng dần theo thứ tự chúng xuất hiện trong các tập tin.

• Trong mỗi lớp hợp thành, quét một khung xác định kênh. Nếu có một khung xác định kênh, thì nhận diện kênh gán với một màu sắc bằng cách kiểm tra trường Asoc của khung Cdef cho kênh đó và thực hiện các bước tiếp theo. Nếu không, áp dụng các bước tiếp theo cho tất cả các kênh.

• Việc nhận diện trong lớp hợp thành tạo ra các thành phần ảnh cung cấp dữ liệu cho các kênh được tìm thấy trong bước trên. Đối với ánh xạ trực tiếp, đây là mối quan hệ 1:1, nhưng đối với ảnh được ánh xạ bằng bảng ánh xạ, khung ánh xạ thành phần được phân tích.

Nếu không có sẵn định dạng tập tin phù hợp tiêu chuẩn ISO / IEC 15444-2, thì dữ liệu đặc tả khác nằm ngoài phạm vi của tiêu chuẩn này có thể có sẵn để xác định các lát ảnh được tạo ra từ các thành phần ảnh. Trong trường hợp này, máy chủ dự kiến sẽ sử dụng dữ liệu đặc tả bất kỳ có sẵn và phù hợp với các thông số kỹ thuật được quy định trong đó.

Trong trường hợp không có sẵn dữ liệu đặc tả bổ sung, hoặc thuộc phạm vi của 15444 hoặc nằm ngoài phạm vi của nó, các thuật toán sau đây có thể được sử dụng như phương pháp cuối cùng để định nghĩa hợp lý các lát ảnh:

Dòng mã được nhận diện như là ảnh lập thể đa mức xám nếu mỗi thành phần tạo ra được tái tạo bằng đúng một bước biến đổi sóng con được giới thiệu trong Phụ lục J của tiêu chuẩn ISO / IEC 15444-2. Một dòng mã được xác định là ảnh màu lập thể, nếu mỗi thành phần tạo ra được tái tạo một cách chính xác bởi hai bước biến đổi, đầu tiên, áp dụng biến đổi sóng con cho các thành phần không gian của dòng mã, bước thứ hai không phải là biến đổi sóng con, mà là biến đổi giải tương quan hoặc phụ thuộc. Tất cả thiết lập khác không thể xử lý được.

Tọa độ Z của lát ảnh của thành phần ảnh được tạo ra được xác định như sau: Đối với thành phần ảnh được tạo ra g, xác định nhãn MCC (MCCi) mô tả các bước biến đổi sóng con thực hiện tính toán g đến từ các thành phần không gian của hệ thống canvas. Theo định nghĩa trên, có chính xác một nhãn như vậy. Nếu ảnh là một ảnh đa mức xám, tìm chỉ số j tại đầu ra của tập thành phần mà có nhãn Wmccij bằng g, tức là tìm thấy vị trí đầu ra trong biến đổi của thành phần này. Sau đó, thành phần ảnh được tạo ra g đóng góp lát ảnh với Z = j + Omcci. Điều này sẽ xác định một tọa độ Z với các thành phần g dựa trên thứ tự của đầu ra của bước biến đổi sóng con.

Đối với các ảnh màu, trước hết xác định tất cả các thành phần đầu vào trung gian của biến đổi giải tương quan hoặc phụ thuộc cần thiết để tái tạo lại tạo ra thành phần g, sau đó tìm tọa độ Z cho chúng theo mô tả ở trên. Yêu cầu tọa độ Z này không phụ thuộc vào các thành phần trung gian; nếu không, thuật toán này bị lỗi.

C.4.2 Kích thước Khung hình (fsiz)

Trường này được sử dụng để xác định độ phân giải gắn với yêu cầu Cửa sổ hiển thị. Các giá trị fx và fy xác định kích thước của độ phân giải hình ảnh mong muốn. Giá trị round-direction chỉ ra cách độ phân giải ảnh dòng mã được lựa chọn cho mỗi dòng mã yêu cầu, nếu không có sẵn độ phân giải ảnh yêu cầu trong dòng mã đó. Kích thước khung hình yêu cầu được ánh xạ tới độ phân giải ảnh dòng mã theo đúng quy trình được mô tả trong Điều C.4.1, có thể với các biến đổi tọa độ bổ sung được yêu cầu thông qua trường yêu cầu Ngữ cảnh Dòng mã (xem C.4.7). Một máy khách có nhu cầu kiểm soát chính xác số lượng mẫu nhận được của một thành phần ảnh cụ thể cần phải tăng kích thước khung yêu cầu, như giải thích trong Điều C.4.1. Các tùy chọn round-direction được quy định trong tiêu chuẩn này được mô tả trong Bảng C.1.

Bảng C.1 – Các tùy chọn round-direction

Round-direction	Ý nghĩa
“round-up”	Đối với mỗi yêu cầu dòng mã, độ phân giải hình ảnh dòng mã nhỏ nhất có chiều rộng và chiều cao đều lớn hơn hoặc bằng với kích thước quy định sẽ được lựa chọn. Nếu không có, sau đó độ phân giải hình ảnh dòng mã có sẵn lớn nhất được sử dụng.
“round-down”	Đối với mỗi dòng mã yêu cầu, độ phân giải hình ảnh dòng mã lớn nhất có chiều rộng và chiều cao đều nhỏ hơn hoặc bằng với kích thước quy định sẽ được lựa chọn. Nếu không có, sau đó có sẵn độ phân giải hình ảnh dòng mã nhỏ nhất được sử dụng. Đây là giá trị mặc định khi tham số round-direction không được xác định.
“closest”	Đối với mỗi dòng mã yêu cầu, độ phân giải hình ảnh dòng mã đó là gần nhất với kích thước quy định trong vùng ảnh (trong đó diện tích = fx x fy) sẽ được lựa chọn. Trong trường hợp hai độ phân giải hình ảnh dòng mã có vùng ảnh cách đều fx x fy, thì vùng ảnh lớn hơn của hai vùng ảnh sẽ được lựa chọn.

Nếu bỏ qua trường yêu cầu Kích thước Khung hình từ yêu cầu Cửa sổ hiển thị và metadata-only không được xác định trong một trường yêu cầu dữ liệu đặc tả (xem C.5.1), thì yêu cầu Cửa sổ hiển thị không bao gồm dữ liệu ảnh nén và không có tiêu đề khối ảnh cụ thể, nhưng nó không bao gồm tất cả tiêu đề khác (dòng mã và định dạng tập tin) thông tin có thể đã được trả về máy khách bao gồm các trường yêu cầu Kích thước Khung hình. Xem C.5.1 để biết thêm thông tin về thông tin định dạng tập tin (dữ liệu đặc tả) được ngầm yêu cầu cùng với yêu cầu Cửa sổ hiển thị.

C.4.3 Độ lệch (roff)

Trường này được sử dụng để xác định góc trên bên trái (độ lệch) của vùng không gian liên quan đến Cửa sổ hiển thị yêu cầu; nếu quy định, các độ lệch mặc định là 0. Kích thước thực tế của vùng ảnh dòng mã kéo dài đến góc dưới bên phải của hình ảnh, tại độ phân giải ảnh dòng mã thực tế được lựa chọn bởi máy chủ, tính toán theo các thủ tục được mô tả trong Điều C.4.1, có thể với biến đổi tọa độ bổ sung được yêu cầu thông qua trường yêu cầu Ngữ cảnh Dòng mã hóa (xem C.4.7).

Việc sử dụng trường Độ lệch chỉ hợp lệ khi liên kết với trường yêu cầu Kích thước Khung hình.

Nếu vùng ảnh dòng mã quy định Kích thước Vùng và Độ lệch để trống (không có vùng), thì đáp ứng của máy chủ không bao gồm bất kỳ dữ liệu hình ảnh nén cho dòng mã đó. Trong đó, đáp ứng của loại dòng JPP hoặc dòng JPT không nên chứa các bản tin tham chiếu ngăn dữ liệu phân khu ảnh, khối ảnh hoặc các tiêu đề khối ảnh của dòng mã đó. Các máy chủ lựa chọn để trả về tiêu đề chính hoặc bản tin ngăn siêu văn bản mà có thể đã được trả lại để đáp ứng yêu cầu bỏ qua các trường yêu cầu Kích thước Khung hình.

C.4.4 Kích thước Vùng (rsiz)

Trường này được sử dụng để xác định phạm vi ngang và dọc (kích thước) của vùng không gian liên quan đến Cửa sổ hiển thị yêu cầu; nếu không quy định, vùng này sẽ kéo dài đến góc dưới bên phải của hình ảnh. Các kích thước thực tế của vùng ảnh dòng mã, tại độ phân giải ảnh dòng mã thực tế được lựa chọn bởi máy chủ, tính toán theo các thủ tục được mô tả trong Điều C.4.1, có thể với biến đổi tọa độ bổ sung được yêu cầu thông qua trường yêu cầu Ngữ cảnh Dòng mã (xem C.4.7). Một vùng ảnh dòng mã yêu cầu không nhất thiết phải chứa đầy đủ trong dòng mã, trong trường hợp máy chủ đơn giản chỉ cần thực hiện giao nhau giữa các vùng ảnh dòng mã có sẵn và vùng được yêu cầu.

Việc sử dụng trường Kích thước Vùng chỉ hợp lệ khi liên kết với trường yêu cầu Kích thước Khung hình.

Các vùng ảnh dòng mã để trống, ví dụ sx hoặc sy bằng không, thì đáp ứng của máy chủ không bao gồm bất kỳ dữ liệu hình ảnh nén cho dòng mã đó. Trong đó, đáp ứng của loại dòng JPP hoặc dòng JPT không nên chứa các bản tin tham chiếu đến ngăn dữ liệu phân khu ảnh, khối ảnh hoặc tiêu đề khối ảnh của dòng mã đó. Các máy chủ lựa chọn để trả về tiêu đề chính hoặc bản tin ngăn dữ liệu đặc tả mà có thể đã được trả lại để đáp ứng yêu cầu bỏ qua các trường yêu cầu Kích thước Khung hình.

C.4.5 Kích thước Khung hình đối với dữ liệu chiều thay đổi (fvsiz)

Yêu cầu này lấy một số biến của các đối số. Sẽ có nhiều đối số là số có các kích thước trong nguồn dòng mã. Cụ thể, nếu hình ảnh là một hình ảnh hai chiều thường xuyên, trường yêu cầu này tương đương với trường fsiz với đối số đầu tiên xác định fx và xác định thứ hai fy. Nếu dòng đại diện cho nguồn dung lượng dữ liệu, phải có ba đối số quy định cụ thể các mở rộng Cửa sổ hiển thị fx, fy và fz, theo thứ tự đó.

Trường này được sử dụng để nhận diện các giải pháp liên quan đến việc yêu cầu Cửa sổ hiển thị. Các đối số xác định độ phân giải hình ảnh mong muốn, mỗi chiều. Giá trị round-direction quy định cụ thể như thế nào một độ phân giải hình ảnh dòng mã có sẵn được lựa chọn cho mỗi dòng mã yêu cầu, nếu độ phân giải hình ảnh được yêu cầu không có sẵn trong dòng mã đó. Kích thước khung hình yêu cầu được ánh xạ tới một độ phân giải hình ảnh dòng mã theo đúng quy trình được mô tả trong C.4.1, có thể với việc bổ sung các yêu cầu phối hợp biến đổi qua các trường yêu cầu Ngữ cảnh Dòng mã (xem C.4.7).

C.4.6 Độ lệch đối với dữ liệu chiều thay đổi (rvoff)

rvoff’= “rvoff” “=” #1UINT

Trường này được sử dụng để nhận diện góc phía trên bên trái (phía trước) (độ lệch) của khu vực không gian liên quan đến việc yêu cầu Cửa sổ hiển thị; nếu không có, các giá trị mặc định độ lệch là 0, Các hiển thị vị trí thực tế của một vùng ảnh dòng mã từ góc phía trên bên trái (phía trước) của hình ảnh, ở hình ảnh thực tế độ phân giải dòng mã được lựa chọn bởi các máy chủ, thu được theo quá trình được mô tả trong Điều C.4.1, có thể với việc bổ sung phối hợp chuyển đổi theo yêu cầu thông qua một trường yêu cầu Ngữ cảnh Dòng mã (xem C.4.7). Trường này lấy một số đối số thay đổi, có một vài đối số trong trường rvoff là kích thước của dòng mã ban đầu. Cụ thể, đối với các hình ảnh hai chiều, hai đối số được yêu cầu và trường này tương đương với roff. Đối với ảnh lập thể, ba đối số được yêu cầu, đó là ox, oy và oz.

Sử dụng trường độ lệch dữ liệu kích thước biến thể chỉ có giá trị kết hợp với khung Kích thước Khung hình đối với trường dữ liệu kích thước biến thể. Nếu Cửa sổ hiển thị chỉ ra Kích thước Vùng hoặc Độ lệch là trống (không có vùng), thì đáp ứng của máy chủ không nên bao gồm bất kỳ dữ liệu hình ảnh nén nào. Trong đó, đáp ứng của kiểu “dòng JPP” hoặc” dòng JPT” không nên chứa các bản tin tham chiếu đến ngăn dữ liệu phân khu ảnh, khối ảnh hoặc tiêu đề khối ảnh. Các máy chủ có thể lựa chọn trả về bản tin tiêu đề hoặc ngăn dữ liệu đặc tả có thể đã được trả lại để đáp ứng với yêu cầu bỏ qua các trường yêu cầu Kích thước Khung hình.

C.4.7 Kích thước Vùng đối với dữ liệu chiều thay đổi (rvsiz)

rvsiz = “rvsiz” “=” #1UINT

Trường này được sử dụng để nhận diện các quy mô (kích thước) của vùng không gian liên quan đến việc yêu cầu Cửa sổ hiển thị; nếu không đưa ra, quy mô của vùng góc phía dưới bên phải (phía sau) của hình ảnh. Quy mô thực tế của Cửa sổ hiển thị, tại mức phân giải thực tế được lựa chọn bởi các máy chủ, được tính toán theo các thủ tục được mô tả trong Điều C.4.1. Cửa sổ hiển thị không nhất thiết phải chứa đầy đủ hình ảnh của nó, trong trường hợp máy chủ đơn giản chỉ cần giao nhau giữa các vùng ảnh đầy đủ và yêu cầu Cửa sổ hiển thị.

Trường này này có một số đối số thay đổi, và một vài đối số là các kích thước trong dòng đích. Nếu Cửa sổ hiển thị chỉ ra Kích thước Khung hình hoặc Độ lệch là trống (không có vùng), thì đáp ứng của máy chủ không nên bao gồm bất kỳ dữ liệu hình ảnh nén nào. Trong đó, đáp ứng của kiểu “dòng JPP” hay “dòng JPT“ không nên chứa các bản tin tham chiếu đến các ngăn dữ liệu phân khu ảnh, khối ảnh và tiêu đề khối ảnh. Các máy chủ có thể lựa chọn để trả về bản tin tiêu đề hoặc ngăn dữ liệu đặc tả có thể đã được trả lại để đáp ứng với yêu cầu bỏ qua yêu cầu Kích thước Khung hình cho trường Dữ liệu Chiều Thay đổi. Trong trường hợp hình ảnh là một ảnh hai chiều thông thường, yêu cầu có hai đối số, và giống hệt với trường rsiz. Đối với hình ảnh lập thể, ba đối số sx, sy và sz, theo thứ tự này.

C.4.8 Thành phần ảnh (comp)

comps = “comps” “=” 1#UINT-RANGE

Trường này được sử dụng để nhận diện các thành phần ảnh được bao gồm trong Cửa sổ hiển thị yêu cầu; nếu không đưa ra, yêu cầu được hiểu là bao gồm tất cả các thành phần ảnh có sẵn của tất cả các dòng mã xác định thông qua các trường yêu cầu Dòng mã, và tất cả các thành phần có liên quan của tất cả các yêu cầu các dòng mã qua trường yêu cầu Ngữ cảnh Dòng mã (xem C.4.7). Các thành phần “có liên quan” này liên quan đến việc tái tạo các thực thể hình ảnh (ví dụ, các lớp hợp thành JPX hoặc đường hình MJ2) được xác định bằng trường yêu cầu Dòng mã

Các giá trị trong trường yêu cầu này đại diện cho các chỉ số của các thành phần hình ảnh quan tâm. Chỉ số thành phần hình ảnh bắt đầu từ 0, và được giải thích bằng việc gán cho chúng cú pháp dòng mã JPEG 2000, mô tả trong tiêu chuẩn ISO / IEC 15444-1, nhưng lưu ý rằng đây là những thành phần được thu được bằng cách giải mã và biến đổi sóng con ngược các dữ liệu đã được nén, trước khi áp dụng các biến đổi thành phần ICT hoặc RCT ngược. Đối với các dòng mã phù hợp với tiêu chuẩn ISO / IEC 15444-2, nhận diện các thành phần là “thành phần không gian”, nghĩa là những thứ thu được bằng cách giải mã và biến đổi sóng con ngược các dữ liệu đã được nén, trước khi áp dụng biến đổi đa thành phần ngược bất kỳ, biển đổi thành phần phụ thuộc, hoặc biến đổi sóng con đa thành phần.

Các thành phần không tồn tại trong dòng mã yêu cầu bất kỳ sẽ bị loại bỏ.

Cách sử dụng của trường comps kết hợp với trường yêu cầu Khung Hình, Vùng hoặc Độ lệch vùng đối với Dữ liệu Chiều Thay đổi với ba hoặc nhiều đối số trên dòng mã theo tiêu chuẩn ISO / IEC 15444-2 không được khuyến khích và phục vụ không thể xử lý nó theo dự kiến.

C.4.9 Dòng mã (stream)

Trường này được sử dụng để nhận diện dòng mã hoặc các dòng mã thuộc về yêu cầu Cửa sổ hiển thị. Nếu trường được bỏ đi và dòng mã không thể được xác định bằng các phương tiện khác, mặc định là dòng mã duy nhất với định danh bằng 0. Lưu ý rằng trường yêu cầu Ngữ cảnh Dòng mã (xem C.4.7) cung cấp thêm các giải thích cho yêu cầu các dòng mã.

Đối với các đích họ tiêu chuẩn JPEG 2000, chỉ số dòng mã là những thứ được nhúng vào trong khung Chờ tương ứng xuất hiện bên trong ngăn dữ liệu đặc tả tương ứng, như mô tả trong Điều A.3.6. Đối với các định dạng tập tin đã bao hàm các định danh dòng mã, những định danh đó nên chấp nhận các chỉ số sử dụng ở đây.

Trong đó một loạt các dòng mã được xác định, sự thiếu vắng giới hạn trên có nghĩa là phạm vi mở rộng cho tất cả các dòng mã với các định danh lớn hơn. Trường hợp cung cấp giới hạn trên, các giới hạn trên cung cấp định danh tuyệt đối của dòng mã cuối cùng trong phạm vi.

Có hay không một giới hạn trên được cung cấp, một loạt dòng mã có thể có đủ điều kiện bởi sampling-factor. Việc sampling-factor, nếu cung cấp, sẽ là một số nguyên dương, F. Phạm vi bao gồm tất cả các định danh dòng mã L + Fk nằm trong phạm vi không đủ tiêu chuẩn, trong đó L là định danh của dòng mã đầu tiên trong phạm vi. Chỉ số của máy khách của các dòng mã quan tâm là k và k là một UINT.

C.4.10 Ngữ cảnh Dòng mã (context)

Trường này có thể được sử dụng để yêu cầu các dòng mã gián tiếp thông qua các thực thể hình ảnh “mức cao hơn”. Tiêu chuẩn này xác định ngữ cảnh tương ứng với lớp hợp thành JPX (một lớp hợp thành JPX có thể bao gồm một hoặc nhiều dòng mã) và các đường hình MJ2; tuy nhiên, cơ chế này được thiết kế để đáp ứng khả năng mở rộng.

Nếu trường yêu cầu Ngữ cảnh Dòng mã được cung cấp, Cửa sổ hiển thị yêu cầu bao gồm từng dòng mã được gắn với ngữ cảnh yêu cầu, ngoài ra bất kỳ dòng mã yêu cầu thông qua các trường yêu cầu Dòng mã.

Phần thân của trường yêu cầu Ngữ cảnh Dòng mã bao gồm một hoặc nhiều giá trị context-range. Mỗi context-range có liên quan đến một tập hợp các dòng mã có thể được xác định bởi các máy chủ. Context-range cũng có thể xác định biến đổi ánh xạ lại tọa độ được áp dụng cho tham số Kích thước Khung hình, Kích thước Vùng và Độ lệch để xác định độ phân giải hình ảnh dòng mã và vùng ảnh dòng mã cho mỗi dòng mã gán với context-range. Trong trường hợp máy chủ được chuẩn bị để xử lý context-range thì xác định dòng mã được gán với context-range bằng một tiêu đề đáp ứng Ngữ cảnh Dòng mã.

Tiêu chuẩn này xác định bốn loại cụ thể của context-range, được dự định để xử lý nhu cầu của các định dạng tập tin JPX, MJ2 và JPM. Đầu tiên các loại context-range, context-range-jpxl, được sử dụng để nhận diện một hoặc nhiều lớp hợp thành JPX. Các chỉ số của các lớp hợp thành liên kết với một context-range-jpxl được cung cấp dưới dạng một dãy đã lấy mẫu, theo ngữ nghĩa tương tự như phạm vi dòng mã lấy mẫu trong trường yêu cầu Dòng mã. Trong trường hợp context- range-jpxl được xử lý bởi máy chủ, dòng mã thuộc lớp hợp thành tương ứng sẽ được xác định trong tiêu đề đáp ứng Ngữ cảnh Dòng mã.

Một jpxl-context-range có thể nhận diện một biến đổi ánh xạ lại tọa độ, được sử dụng trong kết luận độ phân giải hình ảnh dòng mã và vùng ảnh dòng mã cho mỗi dòng mã của nó. Biến đổi ánh xạ lại tọa độ này được xác định bởi hai số nguyên không âm, jpx-iset và jpx-inum. Cặp hai số nguyên xác định một hướng dẫn hợp lại cụ thể trong khung Hợp thành JPX (comp), được tìm thấy trong phạm vi của đích logic. Các hướng dẫn cụ thể trong câu hỏi nằm trong khung tập chỉ dẫn (iset) có số thứ tự vị trí (bắt đầu từ 0) trong khung hợp thành được cho bởi giá trị jpx-iset. Giá trị jpx-inum cung cấp cho các số thứ tự vị trí (bắt đầu từ 0) của các hướng dẫn trong khung tập chỉ dẫn đó. Việc giải thích các chỉ số này độc lập với số lượng lặp lại có thể xuất hiện trong một khung hợp thành JPX.

Khi các giá trị jpx-iset và jpx-inum được xử lý bởi các máy chủ, tham số kích thước khung và vùng hình ảnh yêu cầu fx, fy, sx, sy, ox và oy, đầu tiên sẽ được ánh xạ tới các tham số kích thước khung và vùng sửa đổi fx “, fy” , sx “, sy“, ox “và oy” bằng cách sử dụng các biểu thức trong Phương trình C-3. Những tham số vùng sửa đổi được tính riêng cho từng dòng mã yêu cầu và sau đó sẽ được sử dụng thay cho fx, fy, sx, sy, ox và oy khi xác định độ phân giải hình ảnh dòng mã và vùng ảnh dòng mã theo thủ tục được mô tả trong Điều C.4.1.

Đầu tiên, xác định kích thước khung, độ lệch, chiều rộng và chiều cao luân phiên của hình ảnh tổng hợp như sau:

Ở trên, Wcomp và Hcomp là chiều rộng và chiều cao của hình ảnh hợp thành, quy định trong khung hợp thành; Wtinst và Htinst là chiều rộng và chiều cao hợp thành được xác định theo chỉ dẫn hợp thành; XOinst và YOinst là độ lệch phương ngang và dọc hợp thành được xác định theo chỉ dẫn hợp thành; Wsinst và Hsinst là chiều rộng và chiều cao của lớp hợp thành bị cắt xén xác định bởi chỉ dẫn hợp thành; XCinst và YCinst là độ lệch cắt xén của lớp hợp thành phương ngang và dọc được xác định theo chỉ dẫn hợp thành và Rinst được suy ra từ trường ROT của các chỉ dẫn hợp thành. Nếu chỉ dẫn hợp thành không chứa trường ROT hoặc trường ROT bằng 0, thì Rinst = 0o | NoFlip. Nếu không, góc quay cho Rinst (thể hiện ở các chia độ đồng hồ) được lấy từ 3 bit trọng số thấp của trường ROT sử dụng Bảng M-47 của tiêu chuẩn ISO / IEC 15444-2, trong khi các trạng thái Flip | NoFlip của Rinst được thiết lập để Flip nếu bít thứ 4 của trường ROT khác 0 và NoFlip với các trường hợp khác.

Sau đó, xác định kích thước khung sửa đổi fx “, fy” như sau:

(C-3b)

Để tính toán vùng sửa đổi, đầu tiên xác định các cạnh của vùng bị cắt xén:

;

(C-3c)

Kích thước vùng sửa đổi sx” và sy” và độ lệch vùng ox” và oy” sau đó được tính:

(C-3d)

Lưu ý rằng vùng Cửa sổ hiển thị sửa đổi, xác định bởi sx “, sy”, ox” và oy”, có thể nằm phía bên trái và bên trên gốc tọa độ. Vì vậy, ox” hoặc oy” có thể âm. Bất kỳ phần nào của vùng Cửa sổ hiển thị nằm bên trái hoặc bên trên gốc nên bỏ qua khi xác định vùng ảnh dòng mã theo thủ tục được mô tả trong Điều C.4.1.

Nếu các giá trị jpx-iset và jpx-inum không được cung cấp, các tham số sửa đổi được sử dụng ở vị trí của fx, fy, sx, sy, ox và oy được đưa ra bởi các biểu thức trong Phương trình C-4. Như trước đây, các tham số sửa đổi sẽ được sử dụng khi xác định độ phân giải hình ảnh dòng mã và vùng ảnh dòng mã bằng các thủ tục sau trong Điều C.4.1.

;

sx”=sx; sy”=sy

(C-4)

Loại thứ hai của context-range được mô tả bởi tiêu chuẩn này, mj2t-context, cho phép máy khách yêu cầu các track cụ thể từ một tập tin MJ2. Định danh mj2-track phải là một số nguyên dương, do 1 là định danh rãnh ghi nhỏ nhất cho phép trong tập tin MJ2. Nếu định danh mj2-track bao gồm các tùy chọn hậu tố “+now”, thì mj2t-context bao gồm tất cả các dòng mã phụ thuộc đường hình MJ2, bắt đầu với dòng mã có thời gian ghi lại dữ liệu tương ứng với thời gian nhận được yêu cầu. Điều này rất hữu ích khi nguồn là một dòng video trực tiếp. Nếu không, các máy chủ có thể kết hợp “now” với bất kỳ dòng mã nó thấy phù hợp. Nếu không bao gồm hậu tố “+now”, các mj2t-context bao gồm tất cả các dòng mã phụ thuộc vào đường hình MJ2.

Một mj2t-context có thể chỉ ra biến đổi ánh xạ lại tọa độ, được sử dụng trong việc tính toán độ phân giải hình ảnh dòng mã và vùng ảnh dòng mã cho mỗi các dòng mã của nó. Nếu không có, thì các tham số kích thước khung và vùng được cung cấp thông qua các trường yêu cầu Kích thước Khung hình, Độ lệch và Kích thước Vùng phải được giải thích trực tiếp theo thủ tục nêu trong Điều C.4.1. Nếu không, một trong hai loại biến đổi tọa độ sẽ được yêu cầu, xác định bởi sự xuất hiện của một trong những thẻ “track” hoặc “movie”.

Trong đó “track” được xác định, các trường yêu cầu Kích thước Khung hình, Độ lệch và Kích thước Vùng được sử dụng để xác định một kích thước trình diễn mong muốn và một vùng chữ nhật mong muốn trong hình chữ nhật giới hạn nhỏ nhất chứa các trình diễn của rãnh ghi, ở kích thước trình diễn mong muốn này. Các phép biến đổi hình học được mô tả bởi khung Tiêu đề Rãnh ghi MJ2 (tkhd) được áp dụng để xác định độ phân giải và vùng ảnh tương ứng trên mỗi dòng mã liên quan đến rãnh ghi.

Ở đây “movie” được xác định, các trường yêu cầu Kích thước Khung hình, Độ lệch và Kích thước Vùng được sử dụng để xác định một kích thước mong muốn cho toàn bộ đoạn phim tái tạo (có thể phức hợp), và một vùng chữ nhật mong muốn trong hình chữ nhật giới hạn nhỏ nhất, chứa phim, ở kích thước mong muốn này. Các phép biến đổi hình học được mô tả bởi khung Tiêu đề Rãnh ghi MJ2 (tkhd) được kết hợp với các phép biến đổi hình học được mô tả bởi khung Tiêu đề Movie (mvhd) và được áp dụng để xác định độ phân giải và vùng ảnh tương ứng trên mỗi dòng mã liên quan đến rãnh ghi.

Trong trường hợp một máy chủ là không thể áp dụng bất kỳ biến đổi hình học mj2t-context mô tả ở trên, nó sẽ cung cấp một chuỗi mj2t-context thay đổi trong tiêu đề đáp ứng Ngữ cảnh Dòng mã của nó.

CHÚ THÍCH 1: Việc sử dụng trường yêu cầu Ngữ cảnh Dòng mã cùng với trường yêu cầu Dòng mã có thể dẫn đến một dòng mã được yêu cầu nhiều lần với các biến đổi hình học khác nhau của các trường yêu cầu Kích thước Khung hình, Độ lệch và Kích thước Vùng. Trong trường hợp này, nhiều phần hình ảnh của dòng mã rời rạc hoặc chồng chéo ảnh hưởng đến yêu cầu.

CHÚ THÍCH 2: Các biểu thức trong Phương trình C-4 tương đương có thể thu được bằng cách thiết lập XScomp = Wsinst = Wtinst = WREG, YScomp = Hsinst = Htinst = Hreg và XOinst = YOinst trong Phương trình C-3 khi giới hạn sx”, sy”, ox“ và oy” không bao quanh bởi x_l_im, x_min, y_lim, y_min.

Loại thứ ba của context-range được mô tả trong tiêu chuẩn này, jpm-context, cho phép các máy khách yêu cầu các đối tượng sắp xếp cụ thể từ tập tin JPM. Việc sử dụng đơn giản nhất cho phép một yêu cầu được thực hiện cho tất cả các phần tử dữ liệu cần thiết để kiết xuất ảnh một trang đơn. Sử dụng phức tạp hơn chỉ cho phép một số đối tượng sắp xếp hoặc chỉ có một loại đối tượng được yêu cầu. jpm-context luôn luôn chứa một yêu cầu cho các trang cụ thể, nó cũng có thể chứa đặc điểm chi tiết cho tập hợp các trang, một danh sách các lớp đối tượng bố trí và các loại đối tượng.

Nếu jpm-context không có phần tử jpm-page-collection thì tập hợp trang chính là giả định. Nếu TEXT-LABEL được quy định trong phần tử jpm-page-collection nó phải tương ứng với một nhãn của khung tập hợp trang trong tập tin JPM địa chỉ. Nếu UINT được quy định trong phần tử jpm-page-collection nó cho thấy tập hợp trang ở vị trí đó trong tập tin, nơi mà khung tập hợp trang được đánh số từ 0.

Một loạt các trang là một phần bắt buộc của jpm-context. Phạm vi trang có thể là “0-” xác định tất cả các trang trong tập hợp trang. Các trang được đánh số theo các tập hợp trang và các trang trong các tập tin JPM, và gán số từ 0 cho trang đầu tiên trong cây tìm kiếm theo chiều sâu. Gốc của cây được đưa ra bởi phần tử jpm-page-collection hoặc tập hợp trang chính nếu jpm-page-collection không là một phần của yêu cầu. Các vòng lặp trong cây tập hợp trang được phát hiện và phản hồi lỗi.

Nếu sử dụng “hệ số lấy mẫu” như một phần của jpm-sampled-range, máy khách mong muốn trang bắt đầu với số đầu tiên trong mỗi phạm vi, và nhỏ hơn hoặc bằng số cuối cùng trong dãy và ở tất cả các bội số nguyên của các hệ số lấy mẫu cộng với số trang ban đầu. Như vậy hai phạm vi lấy mẫu có thể yêu cầu số trang chẵn và lẻ khi sử dụng hệ số lấy mẫu bằng 2, bằng cách bắt đầu mỗi dãy có một số chẵn hoặc lẻ.

Nếu jpm-context không có phần tử jpm-object-range sau đó nó được coi là “1” tương ứng với tất cả các đối tượng trên trang trừ hình thu nhỏ. Nếu hình ảnh thu nhỏ cho một trang là cần thiết thì phần tử jpm-object-range sẽ bao gồm không. Các jpm-object-range chỉ có các đối tượng bố trí trên tất cả các trang trong jpm-object-range được yêu cầu.

Nếu jpm-context không có jpm-object-type sau đó tất cả các loại được sử dụng. Nếu jpm-object-type là loại “mask” chỉ các đối tượng mặt nạ là mối quan tâm cho các yêu cầu. Nếu jpm-object-type là “image” chỉ có đối tượng hình ảnh được quan tâm. Nếu jpm-object-type là “nostrm”, thì các khung cho cả mặt nạ và hình ảnh được quan tâm.

Nếu tham số jpm-context xuất hiện trong một yêu cầu mà không có yêu cầu Kích thước Khung hình (fsiz) thì các giá trị Kích thước Khung hình fx và fy được thiết lập là chiều rộng và chiều cao của trang. Nếu tham số jpm-context xuất hiện trong một yêu cầu mà không có một yêu cầu Kích thước Vùng (rsiz) thì các giá trị Kích thước Vùng sx và sy được thiết lập để các giá trị kích thước khung hình fx và fy (sau khi fx và fy đã được thiết lập là chiều rộng và chiều cao trang nếu cần thiết).

Khi tham số jpm-context được sử dụng, tương ứng với yêu cầu cho Cửa sổ hiển thị áp dụng cho từng trang một cách độc lập. Các giá trị Kích thước Khung hình fx và fy được ánh xạ tới chiều rộng và chiều cao theo quy định của các yếu tố Pwidth và Pheight của Khung Tiêu đề Trang của JPM trong tiêu chuẩn ISO / IEC15444-6.

Một đối tượng bố trí trong một trang được coi là một phần của yêu cầu khi và chỉ khi tất cả những điều sau đây là đúng:

trong đó:

và fx, fy, ox, oy, sx, là từ yêu cầu Cửa sổ hiển thị, LHoff, LVoff, LHeight, và LWidth là từ Khung Tiêu đề Đối tượng Bố trí của 15444-6.

Đối tượng bố trí 0 được dành riêng cho một hình ảnh thu nhỏ của trang, nó nên được coi là một phần của yêu cầu phụ thuộc vào Cửa sổ hiển thị khi và chỉ khi 0 được bao gồm trong jpm-object-range

Các máy khách được cho là đã yêu cầu dòng mã bất kỳ kết hợp với mặt nạ hoặc hình ảnh hay phân cắt Cửa sổ hiển thị trừ khi loại jpm-object-type là “nostrm”. Nếu dòng mã không nén theo chuẩn JPEG 2000 thì yêu cầu cho dòng mã được hoàn thành. Nếu dòng mã được nén với chuẩn JPEG 2000 thì một Cửa sổ hiển thị tương đương có thể được xác định cho dòng mã cụ thể bằng cách ánh xạ các cửa sổ yêu cầu trên trang lên cửa sổ yêu cầu trên đối tượng như sau:

Lưu ý rằng cần thiết để đưa ra một yêu cầu khung hình có kích thước với giá trị lớn hơn so với chiều rộng và chiều cao của trang theo thứ tự để có được đầy đủ độ phân giải dòng mã JPEG 2000 nếu tập tin JPEG 2000 có chứa dữ liệu ở độ phân giải cao hơn so với trang. Ngoài ra, máy khách có thể quyết định số lượng dòng mã và đưa ra một yêu cầu trực tiếp trên dòng mã đó với một Cửa sổ hiển thị được chọn thích hợp.

VÍ DỤ 1: “context = jpxl <0-4:2> [s5i2]”

Trong trường hợp này, máy chủ được yêu cầu trả về các dòng mã được sử dụng bởi các lớp hợp thành JPX 0, 2, 4, ánh xạ lại kích thước khung hình yêu cầu và vùng ảnh theo quy định của các điều chỉnh hình học đại diện bởi các chỉ dẫn thứ ba trong Khung tập chỉ dẫn thứ sáu trong khung hợp thành (các tập tin JPX có ít nhất một khung hợp thành).

VÍ DỤ 2: “stream=0&context=mj2t<1+now>[track]”

Trong trường hợp này, máy chủ được yêu cầu trả về dòng mã 0, cũng như tất cả các dòng mã thuộc về rãnh ghi đầu tiên của tập tin MJ2, bắt đầu từ dòng mã có thời gian lấy mẫu tương ứng với thời gian hiện tại. Hơn nữa, các máy chủ được yêu cầu sắp xếp lại kích thước khung hình và vùng ảnh yêu cầu theo các điều chỉnh hình học mô tả trong khung Tiêu đề Rãnh ghi, không tính đến các điều chỉnh bổ sung hình học bất kỳ có thể được mô tả trong khung Tiêu đề Movie.

VÍ DỤ 3: “context=jpmp<0-10,21-30:2>[1-3:mask]”

Trong trường hợp này, máy chủ được yêu cầu trả về toàn bộ dữ liệu tương ứng để che giấu ba đối tượng bố trí đầu tiên trên các trang 0, 2, 4, 6, 8, 10, 21, 23, 25, 27, và 29 yêu cầu này bao gồm tất cả các khung cần thiết để kiết xuất ảnh cho vùng ảnh mong muốn, ví dụ: khung Trang, khung Đối tượng Bố trí, cũng như bất kỳ các dòng mã tham chiếu bởi các đối tượng đó.

Đối với các tập tin JPM, các yếu tố dữ liệu đặc tả dưới đây được coi là yêu cầu theo kèm với Cửa sổ hiển thị:

– Dấu hiệu trang JP2 (“JP”)

– Loại tập tin (“ftyp”)

– Tiêu đề Ảnh Hợp thành (“mhdr”)

– Khung Tập hợp Trang (“pcol”)

– Khung Bảng trang (“pagt”)

– Khung Trang (“page”)

– Đối với các trang có liên quan với yêu cầu Cửa sổ hiển thị:

• Khung Tiêu đề Trang (“phdr”)

• Khung Đối tượng Bố trí (“lobj”)

• Khung Tiêu đề Đối tượng Bố trí (“Ihdr”)

• Khung Đối tượng (“objc”)

• Khung Tiêu đề Đối tượng (“ohdr”)

• Khung Tỷ lệ Đối tượng (“scal”)

• Khung Màu Cơ sở (“bclr”)

Các cân nhắc ở trên, đặc biệt là phương trình C-3 và C-4, giá trị chỉ có dữ liệu hình ảnh hai chiều. Chúng được mở rộng tự nhiên số chiều lớn hơn bằng cách sao chép các tính toán cho mỗi chiều bổ sung. Cách sử dụng của trường ngữ cảnh dòng mã không được khuyến khích nếu địa chỉ của các yêu cầu chứa các dòng mã với số chiều khác nhau, và các máy chủ không thể dự kiến xử lý trường hợp này.

C.4.11 Tốc độ Lấy mẫu (srate)

srate = “srate” “=” streams-per-second

streams-per-second = UFLOAT

Nếu trường này được cung cấp, các dòng mã thuộc Cửa sổ hiển thị thu được bằng cách lấy mẫu phụ các giá trị được cập bởi các trường yêu cầu Dòng mã, ngoài ra các giá trị này được mở rộng từ các giá trị phạm vi ngữ cảnh trong trường yêu cầu Ngữ cảnh Dòng mã (xem C.4.7), để đạt được một tốc độ lấy mẫu trung bình không lớn hơn giá trị số dòng trên mỗi giây. Điều này có thể xảy ra khi dòng mã có liên quan đến thông tin định thời (ví dụ, nếu chúng thuộc về một địa chỉ logic phù hợp với các định dạng tập tin MJ2).

Trường yêu cầu này chỉ phục vụ để xác định các dòng mã nên được coi là thuộc Cửa sổ hiển thị. Các máy chủ sẽ quét qua tất cả các dòng mã đó nếu không sẽ được bao gồm trong Cửa sổ hiển thị, loại bỏ các dòng mã theo yêu cầu để đảm bảo rằng các lần phân tách trung bình giữa các thời điểm gốc của dòng mã không ít hơn so với các giá trị số dòng trên mỗi giây tương ứng. Tiêu chuẩn này không quy định thuật toán cho lấy mẫu phụ, hoặc giải thích chính xác cho thuật ngữ “phân tách trung bình.”

Nếu không có thông tin định thời gốc, Cửa sổ hiển thị sẽ bao gồm tất cả các dòng mã xác định thông qua các trường yêu cầu Dòng mã và trường yêu cầu Ngữ cảnh Dòng mã, nhưng trường yêu cầu này dù sao cũng có thể ảnh hưởng đến việc giải thích của một trường yêu cầu Tốc độ chuyển tiếp, nếu có.

C.4.12 ROI (rol)

Trường này quy định các vùng không gian mong muốn của hình ảnh thông qua một tên gọi hơn là thông qua vị trí tọa độ. Việc sắp xếp giữa tên vùng và vùng không gian cụ thể của hình ảnh có thể đến từ một vài vị trí; nó có thể được định nghĩa trong khung mô tả ROI tại một địa chỉ logic, hoặc nó có thể được xác định bằng việc thực hiện trên chính các máy chủ.

Một giá trị region-name của “dynamic” (Một ROI động) được dành riêng để đại diện cho một vùng ảnh không cố định trong các hình ảnh được ánh xạ tới một vùng không gian độc lập đối với mỗi và mọi yêu cầu. Các máy chủ có thể sử dụng bất kỳ thông tin về máy khách và các thông số yêu cầu khác khi xác định những vùng không gian mà nó sẽ cung cấp yêu cầu cụ thể. Ví dụ, nếu máy chủ biết rằng màn hình trên máy khách là rất nhỏ, nó có thể chọn cung cấp chỉ vùng phía trước của ảnh ở độ phân giải cao hơn chứ không phải là toàn bộ vùng ảnh ở độ phân giải thấp hơn. Máy chủ không cần phải hỗ trợ ROI động.

Nếu một trường ROI tồn tại, và máy chủ biết làm thế nào để xử lý yêu cầu ROI, thì trường ROI được ưu tiên hơn các trường yêu cầu Độ lệch và các trường Kích thước Vùng, mà sẽ được bỏ qua bởi các máy chủ. Nếu một trường ROI tồn tại, nhưng máy chủ không biết làm thế nào để xử lý nó vì lý do nào, máy chủ sẽ bỏ qua các trường ROI và sử dụng các trường Độ lệch và các trường Kích thước Vùng. Nếu các trường này được bỏ qua, các giá trị mặc định của các trường này sẽ được sử dụng.

Nếu máy khách chỉ ra một Kích thước Khung hình cũng như ROI, và máy chủ hiểu ROI được quy định, thì giá trị của trường yêu cầu Kích thước Khung hình quyết định độ phân giải hình ảnh tại đó ROI được yêu cầu.

C.4.13 Lớp (layers)

layers = “layers” “=” UINT

Trường này có thể được sử dụng để hạn chế số lượng các lớp chất lượng dòng mã thuộc về yêu cầu Cửa sổ hiển thị. Mặc định, tất cả các lớp có sẵn được quan tâm. Giá trị xác định số lượng các lớp chất lượng ban đầu được quan tâm. Các máy chủ không nên cố gắng tăng thêm bất kỳ ngăn dữ liệu phân khu ảnh vượt ra ngoài ranh giới lớp có liên quan. Các máy chủ không nên cố gắng tăng thêm bất kỳ ngăn dữ liệu khối ảnh vượt ra ngoài điểm mà tại đó tất cả các nội dung còn lại nằm ngoài ranh giới lớp có liên quan. Do thứ tự của dữ liệu trong một khối ảnh, nó có thể là cần thiết cho máy chủ để trả về dữ liệu vượt ra ngoài ranh giới của lớp yêu cầu chỉ đối với các yêu cầu dòng JPT.

C.4.14 Biến đổi đa thành phần (MCT) Giá trị Độ phân giải

mctres = “mctres” “=” UINT

Trường này chỉ ra mức phân giải biến đổi đa thành phần mong muốn. Trường này là chỉ được áp dụng nếu cho tất cả các khối ảnh thành phần, áp dụng chính xác một trong những biến đổi đa thành phần này cho khối ảnh thành phần (và lặp lại trên kết quả các thành phần kế tiếp để tạo ra các thành phần ảnh tạo thành) là một biến đổi sóng con đa thành phần. Không thể sử dụng cách khác. Nếu trường này là không xuất hiện, nó sẽ được giả định rằng mong muốn biểu diễn độ phân giải đầy đủ trên các dữ liệu ảnh. Số mức phân giải đầy đủ nhiều hơn một so với số mức biến đổi sóng con NL trong biến đổi đa thành phần, cho trước bởi Tmcci (xem Bảng A.39 trong tiêu chuẩn ISO / IEC 15444-2). Đối với độ phân giải đầy đủ, trường này được đặt là 1. Đối với một nửa độ phân giải, trường này được được đặt là 2, với độ phân giải một phần tư, trường này được đặt là 3,…Nếu giá trị của mctres vượt quá NL + 1 đối với một khối ảnh hoặc dòng mã, thì độ phân giải thấp nhất có sẵn trong đó khối ảnh hoặc dòng mã sẽ được truyền đi. Giá trị giống nhau của mctres được áp dụng đồng thời cho tất cả các biến đổi sóng con đa thành phần được tìm thấy trong dòng mã.

Cách sử dụng của trường mctres kết hợp với trường yêu cầu Khung hình, Vùng hoặc Độ lệch đối với Dữ liệu chiều thay đổi với ba hoặc nhiều hơn ba đối số theo các dòng mã quy định tại tiêu chuẩn ISO / IEC 15444-2 không được khuyến khích và máy chủ không được dự kiến xử lý chúng.

C.5 Các trường yêu cầu dữ liệu đặc tả

C.5.1 Dữ liệu đặc tả được yêu cầu hoàn toàn bởi các yêu cầu Cửa sổ hiển thị

Các trường yêu cầu Dòng mã và trường yêu cầu Ngữ cảnh Dòng mã xác định một hoặc nhiều dòng mã có liên quan đến yêu cầu Cửa sổ hiển thị. Thậm chí nếu không xuất hiện các trường yêu cầu này, Cửa sổ hiển thị được kết hợp với ít nhất một dòng mã, như đã đề cập trong Điều C.4.6. Hơn nữa, như đã nêu trong Điều C.4.2, ngay cả khi bỏ qua các trường yêu cầu Kích thước Khung hình, thì yêu cầu Cửa sổ hiển thị vẫn bao gồm ít nhất là tiêu đề dòng mã chính cho mỗi dòng mã yêu cầu. Ngoại lệ duy nhất là khi dữ liệu đặc tả được quy định trong một trường yêu cầu Dữ liệu đặc tả (xem C.5.2). Ngoại trừ trong trường hợp này, máy khách cũng được yêu cầu hoàn toàn bởi các khung dữ liệu đặc tả có thể được yêu cầu từ các định dạng tập tin, nếu có, để sử dụng các hình ảnh đại diện bởi các các dòng mã yêu cầu. Để đảm bảo khả năng tương tác giữa các thành phần máy khách và máy chủ, điều này xác định một tập tối thiểu của các dữ liệu đặc tả mà máy chủ sẽ coi như mặc nhiên được yêu cầu cùng với Cửa sổ hiển thị.

CHÚ THÍCH: Danh sách các khung quy định tại Điều này là không đầy đủ. Cần bổ sung các khung để giải mã các Cửa sổ hiển thị yêu cầu trong địa chỉ logic một cách chính xác

Đối với các tập tin JP2 và JPX, các yếu tố dữ liệu đặc tả dưới đây được coi là yêu cầu thuộc Cửa sổ hiển thị:

a) Toàn bộ nội dung của ngăn dữ liệu đặc tả 0.

b) Toàn bộ nội dung của các khung sau đây, bất cứ khi nào chúng được tìm thấy ở mức cao nhất của tập tin:

1) Dấu hiệu trang JP2 (“JP”):

2) Kiểu tập tin (“ftyp”);

3) Yêu cầu Trình đọc file (“rreq”);

4) Hợp thành (“comp”).

c) Tất cả các tiêu đề khung phụ kế tiếp từ mỗi siêu khung sau:

1) khung Tiêu đề JP2 bất kỳ (“jp2h”);

2) khung Tiêu đề Dòng mã bất kỳ (“jpch”) kết hợp với một yêu cầu dòng mã

3) khung Tiêu đề Lớp Hợp thành (“jplh”) kết hợp với một lớp hợp thành JPX được yêu cầu thông qua các trường yêu cầu Ngữ cảnh Dòng mã.

d) Toàn bộ nội dung của các khung sau đây, bất cứ khi nào các khung được tìm thấy trong một trong những siêu khung được đề cập ở trên:

1) Tiêu đề Ảnh (“ihdr”);

2) Bit trên Thành phần ảnh (“bpcc”);

3) Bảng màu (“pclr”);

4) Ánh xạ Thành phần ảnh (“cmap”):

5) Định nghĩa Kênh (“cdef’);

6) Độ phân giải (“res”);

7) Đăng ký Dòng mã (“creg”);

8) Mờ đục (“opct”).

e) Đối với các tập tin JP2, các tập tin tương thích JP2 và các tập tin JPX, một hoặc nhiều khung Mô tả Không gian màu (“colr”) kết hợp với mỗi dòng mã hoặc JPX hợp thành yêu cầu thông qua các trường yêu cầu Ngữ cảnh Dòng mã, như sau:

1) Nếu máy chủ có thể quyết định chính xác các khung được chọn, máy chủ sẽ chỉ gửi khung, thậm chí nếu nó có nghĩa là không gửi khung đầu tiên đối với các tập tin tương thích JP2 hoặc JP2 (ví dụ nếu khung thứ hai là ICC Bất kỳ và không gian màu xác định rằng máy khách muốn ICC Bất kỳ). Nếu máy chủ không có khả năng quyết định chính xác khung được chọn, nó sẽ gửi toàn bộ khung Mô tả Không gian màu đầu tiên.

2) Đối với tất cả các khung không được gửi, máy chủ sẽ gửi một phần nội dung khung vì vậy máy khách có thể quyết định xem nó sau này muốn yêu cầu đặc tính không gian màu khác.

• Đối với các khung liệt kê, máy chủ sẽ gửi ít nhất là 7 byte đầu tiên của nội dung khung (đến tối thiểu là trường EnumCS).

• Đối với khung không gian màu được xác định bởi nhà cung cấp; máy chủ sẽ gửi ít nhất là 19 byte đầu tiên của nội dung khung (đến tối thiểu là trường VCLR).

• Đối với khung không gian màu ICC Bị hạn chế và Bất kỳ, máy chủ sẽ gửi ít nhất là 3 byte đầu tiên của nội dung khung (tối thiểu là trường METH, APPROX và PREC).

Các máy chủ được yêu cầu phải trả về một tiền tố ban đầu của mỗi ngăn dữ liệu đặc tả, trong đó chứa bất kỳ dữ liệu đặc tả nào được đề cập ở trên, mở rộng từ byte đầu tiên của ngăn dữ liệu đặc tả và tiếp tục đến cuối của tất cả các dữ liệu đặc tả yêu cầu từ ngăn dữ liệu đặc tả. Kết quả là, tổng số dữ liệu đặc tả thực tế trả về của máy chủ có thể phụ thuộc vào các phân chia địa chỉ logic thành các ngăn dữ liệu đặc tả. Thảo luận về những vấn đề này có thể được tìm thấy trong Điều A.3.6.2.

Đối với các tập tin MJ2, các yếu tố dữ liệu đặc tả dưới đây được coi là yêu cầu thuộc Cửa sổ hiển thị:

– Ký hiệu trang JP2 (“JP“)

– Loại tập tin (“ftyp”)

– “Mvhd”

– Đối với các rãnh ghi có liên quan đến yêu cầu Cửa sổ hiển thị:

• “tkhd”

• edts [0]. Chỉ có trường TBox là hữu ích, và các dấu hiệu giữ chỗ mà không cung cấp truy cập cho các nội dung ban đầu của khung.

• “mdhd”

• “hdlr”

• “vmhd” nếu xuất hiện trong tập tin MJ2 ban đầu.

• “stsd”

• “stts”

• hoặc:

– Một khung Chờ cho “stco” hoặc “stco64” (tùy thuộc vào sự xuất hiện của chúng trong tập tin MJ2 ban đầu) chỉ ra rằng nội dung của khung được cung cấp bởi một hoặc nhiều dòng mã tăng dần;

– Hoặc toàn bộ các khung “stsc”, “stsz” và “stco” hoặc “stco64”.

C.5.2 Yêu cầu dữ liệu đặc tả (metareq)

C.5.2.1 Mô tả

Trường này xác định những gì mong muốn dữ liệu đặc tả đáp ứng các yêu cầu, ngoài ra yêu cầu dữ liệu đặc tả bất kỳ cho máy khách để giải mã hoặc giải thích các dữ liệu hình ảnh được yêu cầu theo quy định của Điều C.5.1. Mục đích của yêu cầu này cho phép máy khách yêu cầu các phần nội dung được lựa chọn và cách bố trí của các dữ liệu đặc tả được mã hóa trong định dạng tập tin JP2 và tập tin JPX mã máy chủ đã không chọn để truyền tải theo Điều C.5.1.

Chuỗi giá trị trong trường yêu cầu này là một danh sách các yêu cầu độc lập; tuy nhiên, các máy chủ có thể xử lý các yêu cầu theo nhóm, và có thể có sự chồng chéo giữa các yêu cầu. Nó đủ để máy chủ gửi dữ liệu yêu cầu chỉ một lần.

Cách để các máy chủ quyết định chia nhỏ dòng đầu tiên vào trong các ngăn không liên quan để xác định địa chỉ yêu cầu ngoại trừ trường root-bin có thể được sử dụng để hạn chế yêu cầu đối với các phần của cấu trúc tập tin, khi máy khách xác định được cách bố trí. Khi một yêu cầu được giới hạn trong một ngăn cụ thể, cách để ngăn được chia thành nhiều ngăn không liên quan đến máy khách và cách đánh địa chỉ dữ liệu trong yêu cầu.

Lưu ý, dữ liệu mà một máy chủ trả về với một yêu cầu ở trên phụ thuộc vào cách bố trí do sự phân chia các địa chỉ logic vào các ngăn dữ liệu đặc tả có thể buộc các máy chủ để trả về dữ liệu bổ sung, bao gồm các nội dung hoặc tiêu đề của dữ liệu, các khung có khả năng không được yêu cầu. Tất cả máy chủ phải đảm bảo rằng chứa tối thiểu một yêu cầu dữ liệu, và dữ liệu được trả về đủ để cho phép máy khách phân tích nó. Ví dụ các dữ liệu bổ sung được trả về phải được đưa ra trong Điều C.5.2.7 dưới đây. Các văn bản sau đây sử dụng các từ “yêu cầu” đề chỉ ra đó dữ liệu được mong muốn của máy khách, mà có thể là một tập con của các dữ liệu thực sự được trả về bởi các máy chủ vì các lý do chỉ ra trong Điều C.5.2.7.

Để minh họa tốt hơn, các ví dụ trong các điều khoản nhỏ sau đây đều tham khảo các đoạn dưới đây của một tập tin JPX, xem tiêu chuẩn ISO / IEC 15444-2 đối với định nghĩa của khung được sử dụng ở đây. Các nhãn ở phía bên tay phải đã được thêm vào để tham khảo:

Nội dung	Nhãn
Tiêu đề khung kết hợp (‘asoc’)	A
Tiêu đề khung thống kê số lượng (‘nlst’)	B
Nội dung khung thống kê số lượng	C
Tiêu đề khung kết hợp (‘asoc’)	D
Tiêu đề khung mô tả ROI (roid’)	E
Nội dung khung mô tả ROI	F
Tiêu đề khung kết hợp (‘asoc’)	G
Tiêu đề khung nhãn (‘lbl\040’)	H
Nội dung khung nhãn	I
Tiêu đề khung XML (‘xml\040’)	J
Nội dung khung XML	K

Cấu trúc khung con của các ví dụ trên được chỉ ra bởi dòng thụt vào, ví dụ như, các nhãn H, K thiết lập các nội dung cho siêu khung tại nhãn G.

C.5.2.2 root-bin

Mỗi yêu cầu liên quan đến các ngăn dữ liệu quy định bởi giá trị root-bin của nó. Nếu một giá trị root-bin không được xác định, đáy là ngăn dữ liệu đặc tả 0. Các yêu cầu chỉ liên quan đến dữ liệu trong hoặc tham chiếu đến ngăn dữ liệu cụ thể.

VÍ DỤ:

Nếu máy chủ quyết định đặt các nội dung của khung liên kết ‘A’ trong ví dụ trên vào một ngăn riêng biệt với id ngăn # 3, tiêu đề khung kết hợp ‘A’ sẽ được mã hóa trong một khung Chờ, và các phần tử ‘B’ đến ‘K’ sẽ đưa vào ngăn # 3. Trong trường hợp đó, một trường root-bin của 3 sẽ vẫn quét các phần tử ‘B’ đến ‘K‘. Cụ thể, metareq = [roid] R3 sẽ yêu cầu các phần tử ‘E’ và ‘F’ từ máy chủ và không có dữ liệu khác bên ngoài ví dụ này (xem C.5.2.3 và C.5.2.7 cho các dữ liệu bổ sung bên ngoài yêu cầu có khả năng trả về bởi máy chủ).

Một cách bố trí thay thế có thể bao gồm các phần tử ‘B’ đến ‘G’ trong ngăn # 3 như trên, nhưng ngoài ra phần tử ‘H’ đến ‘K’ đưa vào ngăn riêng # 4. Vì vậy, “G” sẽ được biểu diễn bởi một khung Chờ trong ngăn # 3 và ‘H’ đến ‘K’ là một phần của ngăn # 4. Một trường root-bin của 3 vẫn sẽ quét các phần tử ‘H’ đến ‘K’ vì chúng được tham chiếu bởi một khung Chờ trong ngăn # 3 và cách để ngăn # 3 được chia thành nhiều ngăn không liên quan đến yêu cầu. Như vậy, mặc dù đáp ứng máy chủ sẽ là khác nhau, nhưng các phần tử được xác định bởi yêu cầu là như nhau.

Một trường root-bin của 0 không áp đặt hạn chế trên yêu cầu của từng phần tử, khung hoặc siêu khung, là cách để có thể truy cập từ các ngăn dữ liệu đặc tả # 0. Hoàn toàn không liên quan đến việc khung Chờ được sử dụng hay không. Vì vậy, metareq = [roid] sẽ yêu cầu tất cả các khung mô tả ROI từ máy chủ, và do đó cũng bao gồm các Điều ‘E’ và ‘F’ cùng với tất cả các khung mô tả ROI có sẵn khác.

C.5.2.3 max-depth

Nếu một giá trị max-depth được xác định, thì chỉ có các khung chứa dưới đáy của ngăn dữ liệu đặc tả, và nó không lớn hơn mức max-depth trong phân cấp tập tin bên dưới yêu cầu khung. Nếu max-depth không xác định, thì không có giới hạn về chiều sâu trong phân cấp tập tin đối với yêu cầu này.

VÍ DỤ: Nếu phần tử ‘B’ đến ‘K‘ đưa các nội dung vào ngăn dữ liệu đặc tả # 3 như trong ví dụ cho Điều C.5.2.1, trường root-bin được thiết lập là 3 và max-depth được thiết lập là 0, sau đó yêu cầu được giới hạn từ phần tử ‘B’ đến ‘D’. Nếu max-depth được thiết lập là 1, yêu cầu được giới hạn từ Điều ‘B’ đến ‘G’,

Yêu cầu metareq = [roid] R3D0 sẽ không yêu cầu bất kỳ dữ liệu từ máy chủ bởi vì chỉ có khung mô tả ROI trong ngăn xác định là một trong những mức thấp nhất để bắt đầu ngăn # 3. Yêu cầu metareq = [asoc] R3D0 sẽ yêu cầu bắt đầu khung kết hợp từ nhãn ‘D’ và nội dung của nó, các phần tử ‘E’ đến ‘K’. Yêu cầu này được nhận diện với metareq = [asoc] R3D3 bởi vì khung này là một phần của bắt đầu khung tại nhãn ‘D’ và do đó bao gồm trong các yêu cầu cũ.

C.5.2.4 req-box-prop

Phần req-box-prop của yêu cầu chỉ ra một danh sách các loại khung được quan tâm đối với máy khách. Chuỗi đặc biệt “*” có thể được thay thế cho các loại khung, trong trường hợp ám chỉ tất cả các loại khung. Như vậy, trường này giới hạn các yêu cầu chỉ áp dụng cho các loại khung cụ thể (hoặc các loại) được liệt kê và chỉ dẫn bởi các máy chủ để cung cấp các tiêu đề khung và nội dung khung cho tất cả các khung kết hợp trong tất cả các hạn chế bổ sung.

Nội dung của một siêu khung được xác định bởi phân cấp khung phụ hoàn chỉnh của nó. Điều này có nghĩa rằng trong trường hợp các siêu khung phù hợp với loại khung, yêu cầu phân cấp khung phụ hoàn chỉnh của siêu khung kết hợp, không phụ thuộc vào trường max-depth.

VÍ DỤ:

Xét lại các ví dụ về cách bố trí trong Điều C.5.2. Thì, một req-box-prop của loại ‘asoc’ sẽ bao gồm tất cả các phần tử ‘A’ đến ‘K’ trong yêu cầu vì chúng đưa ra nội dung của khung phù hợp với quy định tại nhãn ‘A’. Lưu ý rằng, một khi khung kết hợp ở nhãn ‘A’ đã được xác định phù hợp với yêu cầu, giới hạn chiều sâu không hạn chế việc cung cấp các nội dung của nó. Một req-box-prop của loại ‘lbl \ 040’ sẽ chỉ có phần tử ‘H’ và ‘I’, cùng với tất cả các khung nhãn khác, miễn là chúng phù hợp với các thông số kỹ thuật được yêu cầu, ví dụ, được chứa trong dưới đáy ngăn dữ liệu giải quyết vấn đề vượt quá giới hạn chiều sâu.

Yêu cầu metareq=[* ] R3D0 chỉ dẫn các máy chủ trả về toàn bộ nội dung của các khung tìm thấy trong nội dung của ngăn 3, và do đó yêu cầu các phần tử ‘B’ đến ‘K‘. Trong khi đã quy định giới hạn về độ sâu mong muốn, các máy chủ sẽ bỏ qua giới hạn đó vì phần tử ‘E’ đến ‘K’ là một phần của bắt đầu khung tại nhãn ‘D’ và không áp dụng những hạn chế khác.

C.5.2.5 limit

Thuộc tính giới hạn tùy chọn theo trường req-box-prop hạn chế hơn nữa các loại yêu cầu, và có bao nhiêu byte trong nội dung khung xác định bởi trường req-box-prop mà máy khách quan tâm đến. Các tham số giới hạn có dạng của một dấu hai chấm kế đến hoặc là một số nguyên không dấu (giá trị giới hạn) hoặc là các ký tự “r”. Các giá trị giới hạn tương tự áp dụng cho tất cả các khung phù hợp với req-box-prop mà nó là một thuộc tính. Nếu nó không được đưa ra, máy khách được yêu cầu toàn bộ các khung phù hợp.

Nếu trường giới hạn là một số nguyên n lớn hơn không, thì máy chủ được yêu cầu trả về tiêu đề khung không giới hạn và chỉ có n byte đầu tiên của nội dung khung thuộc các khung phù hợp. Số byte được xác định ở đây để đếm dữ liệu khi nó xuất hiện trong các tập tin ban đầu trước khi nó được chia vào các ngăn.

Hơn nữa, nếu req-box-prop phù hợp với siêu khung bất kỳ, nội dung của siêu khung phải được hiểu là chuỗi đầy đủ và không giới hạn của các tiêu đề khung và nội dung khung chứa trong siêu khung đó, và giới hạn byte đó cũng đếm các tiêu đề khung của tất cả các khung chứa bên trong siêu khung phù hợp. Do đó nó có thể xảy ra các trường giới hạn chỉ dẫn các máy chủ cung cấp chỉ một phần của tiêu đề khung mặc dù nó luôn bao gồm tiêu đề đầy đủ của các khung kết hợp. Tuy nhiên, sử dụng trường giới hạn theo cách này là nhàm chán và nên tránh sử dụng.

Nếu trường giới hạn bằng không, chỉ yêu cầu các tiêu đề khung của các khung phù hợp.

Nếu giá trị giới hạn là “r”, thì máy chủ được yêu cầu để cung cấp các dữ liệu tối thiểu cần thiết để tái tạo lại tiêu đề khung của tất cả các khung kết hợp, cũng như các dữ liệu tối thiểu để tái tạo lại tiêu đề khung của tất cả các khung phụ của nó lên đến chiều sâu tối đa quy định, bất kể kiểu khung của chúng. Lưu ý rằng, là một ngoại lệ, max-depth không áp dụng cho các giá trị giới hạn “r” để hạn chế nội dung của các siêu khung tạo ra loại yêu cầu này liên quan đến việc giải thích của max-depth.

VÍ DỤ:

xét lại các ví dụ về cách bố trí trong Điều C.5.2 trên với các phần tử ‘B’ đến ‘K’ trong ngăn dữ liệu # 3 và yêu cầu dữ liệu đặc tả metareq=[asoc:8]R3D1. Bằng cách đó, máy khách yêu cầu tiêu đề khung và tám byte đầu tiên của mỗi khung liên kết được tìm thấy trong ngăn # 3 không thấp hơn một mức so với ngăn # 3. Trong ví dụ gần đây, điều này yêu cầu phần tử ‘D’, tám byte từ phần tử ‘E‘, cụ thể là một phần của khung phụ đầu tiên của ‘D’ phù hợp với giới hạn do nó thiết lập các nội dung của ‘D’, phần tử ‘G’ chính xác là dưới một mức phần tử so với phần từ ‘B’ đầu tiên của ngăn, và tám byte của nội dung khung chứa trong bắt đầu siêu khung tại ‘G‘, đó là tám byte đầu tiên của tiêu đề khung ‘H’. Nên các tiêu đề khung ‘E’ và ‘H’ điền vào trong tám byte này, chúng có thể được cắt ngắn. Đây là lý do tại sao không khuyến khích sử dụng các trường giới hạn số trên các siêu khung.

Xét các yêu cầu metareq=[roid:1] R3D1. Điều này sẽ yêu cầu tiêu đề khung của khung mô tả ROI tại nhãn ‘E’ dưới một mức so với bắt đầu của ngăn, và ngoài ra byte đầu tiên của nội dung của nó tại điểm ‘F’, là số lượng các vùng ảnh mã hóa trong khung (xem tiêu chuẩn ISO / IEC 15444-2). Nếu ví dụ có một khung mô tả ROI ở mức sâu hơn, nó sẽ không được yêu cầu ở đây do giới hạn chiều sâu.

Yêu cầu metareq=[asoc] R3D0 không chứa một giới hạn, và do đó yêu cầu tìm thấy các nội dung hoàn chỉnh của khung liên kết bất kỳ ở cấp khung của ngăn dữ liệu đặc tả # 3. Mặc dù khung liên kết tại nhãn ‘G’ nằm ngoài giới hạn độ sâu, nhưng nó vẫn được yêu cầu bởi vì nó được chứa trong khung liên kết bắt đầu tại điểm “D“, và do đó phần tử ‘D’ đến ‘K’ được truyền đi hoàn toàn.

Các giới hạn “r” ảnh hưởng đến yêu cầu cho một bộ khung của một phần phân cấp khung bởi vì nó chỉ cung cấp các dữ liệu tối thiểu, cu thể là các tiêu đề khung, để tái tạo lại cấu trúc của các khung. Yêu cầu metareq=[asoc:r]R3D1 yêu cầu các phần tử tại nhãn ‘D’, ‘E’ và ‘G’, nhưng không phải là “H” và “J” bởi vì chúng nằm ngoài giới hạn độ sâu. Phần tử ‘A‘ không phải là một phần của ngăn # 3 trong thiết lập ví dụ, và do đó không yêu cầu.

Sự khác biệt giữa giới hạn “0” và giới hạn “r” là nó chỉ cung cấp tiêu đề khung của tất cả các khung phù hợp, nhưng không nhất thiết phụ thuộc các khung phụ của chúng. Các giới hạn “r”, mở rộng yêu cầu đến các tiêu đề khung của các cấu trúc phụ của các khung phù hợp với đến độ sâu giới hạn.

C.5.2.6 metareq-qualifier

Các “metareq-qualifier” có dạng của một “/” theo sau bởi một hoặc nhiều cờ “g”, “s”, “w” và “a”. Mỗi cờ xác định một ngữ cảnh mà từ đó khung phù hợp với yêu cầu được rút ra. Như vậy, “metareq-qualifier” xác định thêm một ràng buộc cho các khung bên cạnh box-type. Việc giải thích cho từng ngữ cảnh này được cung cấp trong Bảng C.2. Nếu có nhiều hơn một cờ được cung cấp, các sự kết hợp của các ngữ cảnh tương ứng sẽ được thực hiện.

Các ngữ cảnh “g”, “s” và “w” loại trừ lẫn nhau, nhưng sự kết hợp của chúng nói chung là nhỏ hơn so với catch-call ngữ cảnh “a”. Đó là theo quyết định của máy chủ để quyết định khung rơi vào ngữ cảnh đó, và không có phân loại các loại khung được định nghĩa trong tiêu chuẩn này.

C.5.2.7 priority

Nếu cờ “priority” được quy định, thì máy khách được yêu cầu rằng các dữ liệu thu thập bởi các yêu cầu của dữ liệu đặc tả đã được truyền đi với ưu tiên cao hơn (ví dụ, upfront) so với các dữ liệu hình ảnh được mô tả bởi các trường khác của cùng một yêu cầu.

C.5.2.8 metadata-only

Nếu “metadata-only” được quy định tại phần cuối của trường yêu cầu các dữ liệu đặc tả, máy khách được yêu cầu đáp ứng của máy chủ bao gồm dữ liệu đặc tả duy nhất, không có bất kỳ dữ liệu hình ảnh hoặc các tiêu đề dòng mã nào, bất kể trường yêu cầu Cửa sổ hiển thị như Kích thước Khung hình đã được sử dụng. Đối với kiểu trả về dòng JPP và dòng JPT, điều này có nghĩa rằng các bản tin JPIP bị trả về sẽ là bản tin ngăn dữ liệu đặc tả. Trường này cũng vô hiệu hóa các yêu cầu của dữ liệu đặc tả xác định bởi Điều C.5.1.

C.5.2.9 Các gợi ý của ràng buộc cách bố trí

Không phụ thuộc vào thông số kỹ thuật khung được cung cấp thông qua các trường Yêu cầu Dữ liệu đặc tả, máy chủ có thể gửi dữ liệu khác, hoặc vì nó đã xác định rằng các dữ liệu khác là cần thiết cho máy khách để giải mã hoặc giải thích các dữ liệu hình ảnh được yêu cầu, hoặc vì các máy chủ trước đó đã phân chia địa chỉ logic vào ngăn dữ liệu sử dụng các tiêu chí khác nhau, và dữ liệu bổ sung phải được gửi để cung cấp một cái nhìn nhất quán và có ý nghĩa về các ngăn dữ liệu đặc tả đối với địa chỉ logic này.

Để chuyển các dữ liệu có khả năng phân tích cú pháp cho một máy khách, tất cả các dữ liệu từ bắt đầu của ngăn lên đến byte cuối cùng cần thiết để đáp ứng các yêu cầu đã được biết đến bởi các máy khách, và do đó phải được cung cấp để truyền đi nó chưa có sẵn trong bộ nhớ đệm của máy khách. Ngoài ra, nên di chuyển bất kỳ dữ liệu phù hợp với yêu cầu vào ngăn bổ sung bằng khung Chờ, khung Chờ hoàn chỉnh và các byte của ngăn tham chiếu bởi khung giữ nằm trong yêu cầu. Số lượng byte, được sử dụng cho các thuộc tính giới hạn, luôn luôn được tìm thấy trong các dòng ban đầu và không bị phá vỡ bởi các máy chủ. Điều này có nghĩa rằng số byte thực sự được truyền lại cho máy khách có thể khác số lượng byte ngụ ý bởi byte-limit, bởi vì không phải chỉ có khung giữa chỗ được truyền đi, mà còn có các dữ liệu ở phía trước của byte yêu cầu trong ngăn, các byte được đặt có thể phải được bao gồm để làm cho dòng kết quả có thể phân tích được.

Không liên quan đến các thông số kỹ thuật khung được cung cấp thông qua các trường yêu cầu metareq, máy chủ có thể gửi dữ liệu khác, hoặc vì nó đã xác định rằng các dữ liệu khác là cần thiết cho máy khách để giải mã.

VÍ DỤ:

Xét lại các dữ liệu như được tìm thấy ở đoạn đầu Điều C.5.2 và giả định các máy chủ đã quyết định đưa tất cả các dữ liệu vào ngăn dữ liệu đặc tả # 3 mà không sử dụng bất kỳ (bổ sung) khung Chờ. Cũng giả định rằng bộ nhớ đệm của máy khách hiện đang trống. Sau đó, các dữ liệu đặc tả yêu cầu metareq-[xml\040:r]R3 chỉ được yêu cầu tiêu đề khung của khung XML tại nhãn ‘J‘. Tuy nhiên, kể từ khi ngăn không được chia thành nhiều ngăn, tất cả các byte trước phần tử ‘J‘ cũng được yêu cầu bởi máy khách để phân tích dữ liệu này thành công và để xác định các dữ liệu được truyền như là một tiêu đề khung, và do đó các máy chủ là cần thiết gửi tất cả các dữ liệu từ phần tử ‘B’ đến ‘J’.

Như ví dụ trên cho thấy, không sử dụng các giữ chỗ có thể không có hiệu quả đáng kể đối với một số yêu cầu. Cách bố trí thay thế dưới đây ở phía máy chủ cung cấp một tiếp cận hiệu quả hơn với cùng một dữ liệu:

Các khung kết hợp tại ‘D’ và ‘G’ được chia thành các ngăn riêng biệt với các id ngăn # 4 và # 5, tương ứng. Sau đó, đối với các yêu cầu giống nhau, máy chủ sẽ phải truyền khung Chờ cho phần tử ‘D’ vào ngăn # 3, khung Chờ cho phần từ ‘G’ vào ngăn # 4 và khung tiêu đề yêu cầu ‘J’ hiện tại nằm ở đầu của ngăn # 5. Lưu ý rằng các yêu cầu tự động liên quan đến ngăn # 4 và # 5, do chúng được tham chiếu bởi các khung Chờ trong ngăn # 3 và # 4 tương ứng. Tùy thuộc vào kích thước của các khung còn lại, cách bố trí này có thể đem hiệu quả đáng kể hơn.

C.5.2.10 Các xem xét cụ thể đối với các khung tham chiếu chéo

Nếu khung tham chiếu chéo bất kỳ được xác định bởi một yêu cầu dữ liệu đặc tả, máy chủ cũng bao gồm các đáp ứng dữ liệu đặc tả bổ sung như nó có thể được yêu cầu cho máy khách để xác định ngăn dữ liệu đặc tả, nếu có, trong đó có các nội dung byte tập tin gốc mà tham chiếu bởi như khung tham chiếu chéo.

CHÚ THÍCH: Nếu một khung tham chiếu chéo có một giữ chỗ tương đương dòng, chính khung Chờ cung cấp định danh của một ngăn dữ liệu đặc tả, trong đó có các nội dung tham chiếu chéo gốc. Nếu không, các máy chủ được yêu cầu gửi tối thiểu một tiêu đề khung (hoặc khung Chờ tương ứng) cho mỗi khung trong các tập tin ban đầu, trong đó có dữ liệu tham chiếu bởi khung tham chiếu chéo.

C.6 Các trường yêu cầu giới hạn dữ liệu

C.6.1 Độ dài Đáp ứng Tối đa (len)

len = “len” “=” UINT

Trường này chỉ ra một giới hạn về số lượng dữ liệu, theo đơn vị byte, mà máy khách yêu cầu từ máy chủ. Đối với các kiểu trả về hình ảnh JPP và JPT, giới hạn bao gồm tải dữ liệu và các tiêu đề VBAS. Bản tin EOR (tiêu đề và nội dung, xem Phụ lục D) không đóng góp vào giới hạn.

Nếu trường len không xuất hiện, máy chủ sẽ gửi dữ liệu hình ảnh cho máy khách cho đến khi một điểm mà tất cả các dữ liệu có liên quan được gửi đi, đạt được giới hạn chất lượng (xem C.6.2), hoặc đáp ứng bị gián đoạn bởi sự xuất hiện một yêu cầu mới mà không bao gồm một trường yêu cầu đợi với một giá trị “yes” (xem C.7.2). Các máy khách nên sử dụng len = 0 nếu nó chỉ đòi hỏi tiêu đề đáp ứng và không có thông tin chính (xem Phụ lục F). Tuy nhiên, các giao thức truyền tải yêu cầu khung của đáp ứng cần thiết một bản tin EOR (xem phụ lục H).

C.6.2 Chất lượng (quality)

quality = “quality” “=” (1*2DIGIT / “100”) ; 0 to 100

Trường này có thể được sử dụng để hạn chế truyền tải dữ liệu đến một mức chất lượng (trong khoảng 0 đối với chất lượng thấp nhất và 100 đối với chất lượng cao nhất) kết hợp với hình ảnh. Giới hạn chất lượng rất khó xây dựng một cách đáng tin cậy, và máy chủ có thể bỏ qua yêu cầu này bằng cách đáp ứng với giá trị “-1” (xem D.2.16). Tuy nhiên, nó rất hữu ích cho phép máy khách cung cấp một số dấu hiệu cho thấy chất lượng hình ảnh tối đa có thể được quan tâm. Hệ số chất lượng có thể gần đúng với chất lượng thường được sử dụng để kiểm soát nén JPEG. Các máy khách có thể mong đợi rằng kích thước dữ liệu trả về là đơn điệu không giảm với chất lượng được tăng lên, tức là, tăng giá trị chất lượng nói chung tương ứng với tăng kích thước dữ liệu trả về.

CHÚ THÍCH: Nếu một máy chủ hỗ trợ yêu cầu này và hai máy khách khác nhau có những yêu cầu giống hệt với cùng một địa chỉ có giá trị chất lượng như nhau, ví dụ, “chất lượng = 80”, máy chủ cần phải có một phương thức nhất quán trong việc thực hiện trả về dữ liệu từ các ngăn dữ liệu.

C.7 Các trường yêu cầu kiểm soát máy chủ

C.7.1 Căn chỉnh (align)

align = “align” “=” (“yes” / “no”)

Trường này xác định xem liệu đáp ứng máy chủ có thực hiện căn chỉnh trên “các ranh giới tự nhiên” không. Giá trị mặc định là “không”. Nếu máy chủ hỗ căn chỉnh đáp ứng và giá trị là “có”, bất kỳ bản tin dòng JPT hoặc dòng JPP gửi đến để đáp ứng với yêu cầu này mà vượt quá bất kỳ ranh giới tự nhiên sẽ bị chấm dứt tại bất kỳ ranh giới tự nhiên tiếp theo. Máy chủ không hỗ trợ liên kết dữ liệu nhưng nhận được một yêu cầu liên kết với các giá trị “có” sẽ cho biết điều này bởi Đáp ứng Căn chỉnh quy định tại Điều D.2.24.

Các ranh giới tự nhiên cho từng loại ngăn dữ liệu được liệt kê trong Bảng C.3. Một bản tin được cho là vượt quá ranh giới tự nhiên nếu nó bao gồm các byte cuối cùng trước khi đến ranh giới và các byte đầu tiên sau ranh giới.

CHÚ THÍCH: Ví dụ, một ngăn dữ liệu phân khu ảnh đi qua ranh giới tự nhiên nếu nó bao gồm các byte cuối cũng của một gói và byte đầu tiên của gói tiếp theo. Lưu ý rằng các bản tin đáp ứng căn chỉnh không thực sự cần thiết để chấm dứt tại một ranh giới tự nhiên, trừ khi chúng vượt qua một ranh giới. Điều này có nghĩa rằng đáp ứng có thể bao gồm các gói từng phần từ các phân khu ảnh, trong đó có thể là cần thiết nếu giới hạn byte phổ biến ngăn cản việc cung cấp các gói hoàn chỉnh.

Bảng C.3 – Các ranh giới căn chỉnh dựa trên các kiểu ngăn

Kiểu ngăn	Ranh giới tự nhiên
Ngăn dữ liệu phân khu ảnh	Kết thúc một gói (một ranh giới cho từng lớp chất lượng)
Ngăn dữ liệu khối ảnh	Kết thúc một phần khối ảnh (một ranh giới cho từng phần khối ảnh)
Ngăn dữ liệu tiêu đề khối ảnh	Kết thúc ngăn (chỉ có một ranh giới)
Ngăn dữ liệu tiêu đề chính	Kết thúc ngăn (chỉ có một ranh giới)
Ngăn dữ liệu đặc tả	Kết thúc một khung tại mức cao nhất của ngăn dữ liệu (một ranh giới cho từng khung)

C.7.2 Đợi (wait)

wait = “wait” “=” (“yes” / “no”)

Trường này được sử dụng để cho biết liệu các máy chủ có phải hoàn thành một đáp ứng với các yêu cầu trước đó không. Nếu giá trị của trường này là “có”, máy chủ sẽ hoàn toàn đáp ứng yêu cầu trước đó về trên cùng một tài nguyên kênh xác định thông qua các trường ID Kênh trước khi bắt đầu đáp ứng yêu cầu này.

Nếu giá trị của trường này là “không”, máy chủ có thể chấm dứt việc xử lý yêu cầu bất kỳ trước đó trên cùng một tài nguyên kênh (xác định thông qua các trường ID Kênh), trước khi hoàn thành và có thể bắt đầu để đáp ứng yêu cầu mới này. Trong ngữ cảnh này, “graceful termination” ngụ ý rằng ít nhất máy chủ sẽ phải hoàn thành các bản tin hiện tại.

Giá trị mặc định của trường này là “không”.

CHÚ THÍCH: Không nên kết hợp của “wait = yes” with “cclose=*”. Nếu gặp phải tình trạng này, một trong hai ứng dụng có thể được quyết định ưu tiên.

C.7.3 Kiểu Trả về Ảnh (type)

Trường này được dùng để chỉ ra kiểu (hoặc các kiểu) của dữ liệu đáp ứng yêu cầu. Một máy chủ không muốn cung cấp bất cứ các kiểu trả về yêu cầu sẽ phát đi một đáp ứng lỗi.

Giá trị của trường yêu cầu Kiểu Trả về Ảnh phải là một kiểu phương tiện truyền thông (được định nghĩa trong RFC 2046) hoặc một trong các kiểu trả về hình ảnh dành riêng được quy định tại Bảng C.4.

Bảng C.4 – Các kiểu trả về ảnh hợp lệ

Kiểu	Giải thích
“jpp-stream”	Một dòng JPP theo quy định tại Phụ lục A. “jpp-stream” tùy chọn có thể được theo sau bởi “;ptype=ext”, trong trường hợp này lại kiểu trả về yêu cầu, trong đó tất cả các tiêu đề bản tin ngăn dữ liệu phân khu ảnh có dạng mở rộng (xem A.2.2)
“jpt-stream”	Một dòng JPT theo quy định tại Phụ lục A.” jpt-stream ” tùy chọn có thể được theo sau bởi “;ttype=ext”, trong trường hợp này lại kiểu trả về yêu cầu, trong đó tất cả các tiêu đề bản tin ngăn dữ liệu khối ảnh có dạng mở rộng, (xem A.2.2)
“raw”	Các máy khách được yêu cầu toàn bộ chuỗi các byte trong địa chỉ logic sẽ được gửi đi không thay đổi.
Các giá trị khác	Dự trữ cho ISO sử dụng

Nếu trường yêu cầu kiểu được bỏ qua, kiểu trả về phải được xác định bởi một phương pháp khác.

Trong một phiên, một yêu cầu có liên quan đến một trường yêu cầu ID Kênh, giá trị của tham số trả về phải được duy trì trong đáp ứng kế tiếp cho các yêu cầu dữ liệu hình ảnh hoặc dữ liệu đặc tả tương ứng với cùng các địa chỉ logic.

CHÚ THÍCH 1: Các kiểu phương tiện truyền thông ảnh (ví dụ, jp2, jpeg, tiff, png), nếu có, có thể được cung cấp bởi một máy chủ như là một dịch vụ chuyển mã cho chức năng JPIP.

CHÚ THÍCH 2: Đối với các kiểu trả về dòng mã thô, dữ liệu đáp ứng nên bao gồm các thực thể yêu cầu đầy đủ. Vì vậy, một vài trường yêu cầu máy khách khác có thể sẽ không có ý nghĩa và bị bỏ qua bởi máy chủ.

C.7.4 Tốc độ Chuyển tiếp (drate)

drate = “drate” “=” rate-factor

rate-factor = UFLOAT

Trường này được sử dụng để xác định tốc độ chuyển tiếp của các dòng mã khác nhau. Nếu trường này được cung cấp, máy chủ sẽ cung cấp dữ liệu thuộc các dòng mã khác nhau trong Cửa sổ hiển thị sau một lập lịch chuỗi tạm thời. Các dòng mã thuộc Cửa sổ hiển thị là tất cả những xác định thông qua các trường yêu cầu Dòng mã và trường yêu cầu Ngữ cảnh Dòng mã, có thể lấy mẫu phụ phù hợp với các trường yêu cầu Tốc độ Lấy mẫu.

Để cung cấp ý nghĩa cho trường yêu cầu này, thông tin định thời sẽ được liên kết với các dòng mã khác nhau trong Cửa sổ hiển thị. Nếu các dòng mã thuộc về một tập tin MJ2, các thông tin định thời được cung cấp bởi tập tin đó. Các tập tin MJ2 cung cấp một ánh xạ giữa mỗi dòng mã và thời gian phát lại danh nghĩa, được xác định ở đây là “thời gian nguồn.”

Nếu các dòng mã không có thông tin định thời nguồn, nhưng trường yêu cầu Tốc độ Lấy mẫu xuất hiện, các máy chủ sẽ giả định rằng các dòng mã trong Cửa sổ hiển thị có thời điểm nguồn được phân cách bởi các giá trị nghịch đảo trong trường yêu cầu Tốc độ Lấy mẫu.

Nếu các dòng mã không có thông tin định thời nguồn, và các trường yêu cầu Tốc độ Lấy mẫu không xuất hiện, máy chủ sẽ giả định rằng các dòng mã trong Cửa sổ hiển thị có thời điểm nguồn được cách nhau đúng một giây.

Trường yêu cầu Tốc độ Chuyển tiếp cung cấp hệ số tỷ lệ giữa tốc độ chuyển tiếp và tốc độ nguồn. Nếu hệ số tốc độ là 1, máy chủ nên cố gắng cung cấp các dòng mã cho máy khách với tốc độ đề nghị tại thời điểm nguồn của chúng, lưu ý rằng những thời điểm nguồn có thể không nhất thiết phải đều nhau. Tổng quát hơn, nếu hệ số tốc độ là F, máy chủ nên cố gắng để cung cấp các dòng mã cho máy khách với tốc độ F nhanh hơn so với tốc độ được đề nghị tại thời điểm nguồn của chúng.

Nếu máy chủ không thể chuyển tiếp tất cả dữ liệu liên quan cho mỗi dòng mã với tốc độ yêu cầu (ví dụ, do hạn chế về băng thông), chỉ cần cung cấp một phần dữ liệu cho mỗi dòng mã, để tránh vi phạm tốc độ chuyển tiếp yêu cầu. Phần dữ liệu của mỗi dòng mã mà không được chuyển tiếp có thể phụ thuộc vào giá trị view-window-pref cung cấp trong một trường yêu cầu Tham chiếu Máy khách (xem C.10.2). Nếu tham chiếu là “luỹ tiến” hoặc không có tham chiếu như vậy, các máy chủ nên cố gắng cung cấp đồng nhất, chất lượng hình ảnh tối đa qua Cửa sổ hiển thị, chịu sự hạn chế tốc độ chuyển tiếp. Nếu giá trị view-window-pref của “fullwindow” được cung cấp, máy chủ có thể cắt bỏ các đại diện liên quan đến mỗi dòng mã theo một cách khác. Trong mọi trường hợp, hành vi này sẽ tương tự như kết quả từ các máy khách gửi đi một loạt các yêu cầu cho mỗi dòng mã liên quan lần lượt, với tốc độ chuyển tiếp.

Nếu máy chủ có thể cung cấp tất cả dữ liệu liên quan cho mỗi dòng mã, tại tốc độ yêu cầu, nó không nên dùng đến các kết nối yêu cầu đảm bảo tốc độ chuyển tiếp không bị vượt quá.

Nếu trường này không được cung cấp và nếu giá trị view-window-pref của “fullwindow” chưa được xác định, các máy chủ nên cố gắng sắp xếp trình tự các dữ liệu có liên quan theo một cách nào đó để dần dần tăng chất lượng của tất cả các dòng mã thống nhất.

C.7.5 Gửi đi

Nếu trường yêu cầu này xuất hiện, các máy chủ được yêu cầu cung cấp dữ liệu đáp ứng cho yêu cầu này là các gói UDP đến host đã cung cấp (tên hoặc chuỗi ký tự IP), sử dụng số cổng cung cấp, với băng thông chuyển tiếp tối đa mbw, và các byte tối đa bpc trong mỗi khúc dữ liệu, bao gồm tiêu đề khúc dữ liệu 8-byte. Băng thông có thể được tính theo bit / giây, kilobit / giây, megabit / giây, gigabit / giây hoặc terabit / giây; đối với định nghĩa “mbw”, xem 10.2.4. Giá trị bpc sẽ không nhỏ hơn 32 và không lớn hơn 4096.

Trường yêu cầu này chỉ có thể được sử dụng để định hướng đáp ứng dữ liệu liên quan đến lớp truyền tải “http-UDP” được thiết lập. Máy chủ sẽ bỏ qua các trường yêu cầu nếu các loại truyền tải kết hợp với yêu cầu không phải là “http-UDP“. Nếu không, dữ liệu đáp ứng được đóng khung vào các khúc dữ liệu và được chuyển tiếp qua các gói UDP theo cách thức được mô tả trong Phụ lục K. Hơn nữa, trong trường hợp này, máy khách sẽ không gửi gói bao nhận để đáp ứng với các khúc dữ liệu chuyển đi này, hoặc máy chủ nên đợi chúng.

Ảnh hưởng của trường yêu cầu này là không ổn định; nó chỉ áp dụng cho các dữ liệu liên quan đến đáp ứng của yêu cầu được tìm thấy.

CHÚ THÍCH 1: Một yêu cầu được gắn liền với loại truyền tải “http-UDP” theo một trong hai trường hợp có thể có: a) yêu cầu chứa trường yêu cầu kênh mới và máy chủ cấp yêu cầu với một kênh mới sử dụng truyền tải “http-UDP”, như được chỉ ra bởi tiêu đề đáp ứng JPIP-cnew; hoặc b) yêu cầu chỉ định một ID Kênh đã được cấp cho một kênh bằng cách sử dụng truyền tải “http UDP” và không có kênh JPIP mới được cấp bởi các máy chủ để đáp ứng với yêu cầu này.

CHÚ THÍCH 2: Do đáp ứng dữ liệu gửi đến địa chỉ được xác định bởi một trường yêu cầu SendTo không được thừa nhận một cách rõ ràng, máy khách nên chú ý đặc biệt đến các trường yêu cầu Bỏ qua và Mảng chắn, có thể được sử dụng để thực hiện truyền thông tin cậy. Ngoài ra, vì máy chủ không nhận được thông tin báo nhận để ước lượng điều kiện kênh, chẳng hạn như băng thông và khả năng mất gói, trách nhiệm của máy khách cần thiết thực hiện bất cứ điều gì để ước lượng và cung cấp một băng thông chuyển tiếp và kích thước khúc dữ liệu thích hợp.

C.7.6 Bỏ qua

Trường yêu cầu này cho phép máy khách thông báo một cách rõ ràng cho các máy chủ về sự vắng mặt của một hoặc nhiều khúc dữ liệu có thể đã được gửi để đáp ứng yêu cầu trước đó. Mỗi lần xuất hiện thông báo chunk-range cho của một hoặc nhiều khúc dữ liệu của máy chủ, nên xem xét không phải đã đi đến máy khách. Các máy chủ sẽ không xem xét bất kỳ dữ liệu liên quan đến bản tin JPIP chứa trong các khúc dữ liệu xác định nhận được hoặc lưu đệm trên máy khách, với mục đích đáp ứng yêu cầu này hoặc bất kỳ yêu cầu tiếp theo về vấn đề này hoặc bất kỳ kênh JPIP khác, ngoại trừ trong trường hợp mà máy chủ nhận được, hoặc đã nhận được bản tin báo nhận rõ ràng của các khúc dữ liệu thông qua gói báo nhận.

Nếu yêu cầu không xác định một ID Kênh đã được cấp cho một kênh bằng cách sử dụng truyền tải HTTP-UDP, máy khách sẽ không bao gồm bất kỳ trường yêu cầu Bỏ qua nào và máy chủ sẽ bỏ qua trường yêu cầu bất kỳ như vậy mà nó gặp.

CHÚ THÍCH: Các trường yêu cầu Bỏ qua có thể sử dụng bất kể trường yêu cầu SendTo có mặt trong cùng một yêu cầu.

Các giá trị chunk-range xác định khúc dữ liệu thông qua 16 bit thấp của yêu cầu ID và số thứ tự khúc dữ liệu; cả hai giá trị được tìm thấy trong các tiêu đề khúc dữ liệu có liên quan, như mô tả trong Phụ lục K. Các thành phần ID yêu cầu được xác định bởi chunk-qid và phù hợp với nội dung của trường ID yêu cầu trong tiêu đề khúc dữ liệu mà máy khách không muốn thừa nhận; không có chunk-range sẽ có một giá trị chunk-qid bên ngoài phạm vi 0-65535.

Trường yêu cầu Bỏ qua chỉ áp dụng cho khúc dữ liệu đã được truyền hoặc sẽ được truyền để đáp ứng với yêu cầu trước đó trong cùng một kênh. Để tránh nhầm lẫn, các máy chủ sẽ bỏ qua bất kỳ trường yêu cầu Bỏ qua là một phần của yêu cầu đầu tiên trong một kênh JPIP mới – tức là, yêu cầu, trong đó xuất hiện trường yêu cầu Kênh Mới. Ngoài ra, trường yêu cầu Bỏ qua không áp dụng cho khúc dữ liệu thuộc các yêu cầu đã được loại bỏ khi xuất hiện trường yêu cầu Mảng chắn trong yêu cầu trước đó của kênh.

CHÚ THÍCH 1: Có thể có một số khúc dữ liệu bị ảnh hưởng bởi trường yêu cầu Bỏ qua chưa được truyền tới các máy chủ trong khoảng thời gian yêu cầu. Trong trường hợp này, máy chủ thường sẽ bỏ qua các khúc dữ liệu ngay lập tức, mà lần đầu không truyền cho chúng. Nếu hành vi này không là mong muốn của máy khách, máy khách nên tránh bỏ qua khúc dữ liệu trước khi ít nhất một khúc dữ liệu phía sau trong cùng một yêu cầu hoặc khúc dữ liệu từ một yêu cầu phía sau được nhận.

CHÚ THÍCH 2: Như đã giải thích trong Phụ lục B, tiêu chuẩn này không yêu cầu máy chủ duy trì một bản ghi đầy đủ các dữ liệu mà nó đã gửi để đáp ứng với yêu cầu máy khách; nó cũng không đòi hỏi máy chủ loại trừ các dữ liệu đó từ đáp ứng của nó với các yêu cầu trong tương lai. Điều này có nghĩa rằng một máy chủ có thể, theo quyết định của mình, lựa chọn để xóa bất kỳ bản ghi mô tả các khúc dữ liệu được truyền tại thời điểm bất kỳ. Tuy nhiên, nếu máy chủ không duy trì một bản ghi đã được gửi cho máy khách, với mục đích tránh truyền dư thừa trong tương lai, nó cần phải theo dõi các nội dung của khúc dữ liệu mà nó vẫn chưa nhận được thông tin báo nhận thông qua gói báo nhận hoặc trường yêu cầu bỏ qua, để nó có thể đáp ứng một cách chính xác các yêu cầu bỏ qua trong tương lai. Một máy chủ có thể chọn để xóa phần bản ghi của mình bất cứ lúc nào để giảm bớt gánh nặng của việc theo dõi các khúc dữ liệu không báo nhận. Ngoài ra, máy khách có thể sử dụng các trường yêu cầu Mảng chắn để thông báo cho máy chủ rằng nó sẽ không bao giờ bỏ qua các khúc dữ liệu được gửi để đáp ứng với một phạm vi nhất định các yêu cầu, để các máy chủ không cần phải theo dõi các khúc dữ liệu không báo nhận thuộc phạm vi đó.

C.7.7 Mảng chắn

Trường yêu cầu này được cung cấp để kích hoạt các máy khách thông báo cho máy chủ các yêu cầu mà khúc dữ liệu đáp ứng không bị bỏ qua thông qua bất kỳ yêu cầu tiếp theo. Ảnh hưởng của trường yêu cầu Mảng chắn vẫn tồn tại trong kênh JPIP liên quan. Cụ thể, tác dụng của bất kỳ trường yêu cầu Bỏ qua trong bất kỳ yêu cầu tiếp theo được giới hạn khúc dữ liệu gán với yêu cầu liên quan có request-id Q đó lớn hơn Qb, trong đó Qb là giá trị lớn nhất của barrier-qid quy định tại điều này hoặc bất kỳ yêu cầu trước đó trong cùng một kênh JPIP.

Nếu yêu cầu không xác định channel-id được cấp cho một kênh bằng cách sử dụng truyền tải “http-udp”, máy khách sẽ không bao gồm bất kỳ trường yêu cầu Bỏ qua nào và máy chủ sẽ bỏ qua bất kỳ trường yêu cầu như vậy mà nó gặp.

CHÚ THÍCH 1: Các trường yêu cầu Mảng chắn chỉ ảnh hưởng đến việc giải thích trường yêu cầu Bỏ qua được tìm thấy trong các yêu cầu tiếp theo. Ví dụ, “barrier=3&abandon=3:4-7” có nghĩa là máy khách được phép bỏ khúc dữ liệu 4 đến 7 từ yêu cầu với request-id 3, nhưng nó sẽ không bỏ qua bất kỳ khúc dữ liệu từ yêu cầu đó trong tương lai.

CHÚ THÍCH 2: Các giá trị chunk-qld được cung cấp thông qua chunk-range trong một yêu cầu Bỏ qua đối chiếu với bất kỳ yêu cầu mà request-id có cùng 16 bit trọng số thấp như chunk-qid. Mặt khác, giá trị barrier-qid cung cấp đầy đủ theo request-id, không chỉ 16 bit trọng số thấp.

C.7.8 Định giờ Đợi

Trường yêu cầu này cho phép máy khách đề nghị những điểm mới nhất mà nó muốn máy chủ bắt đầu đáp ứng các yêu cầu hiện tại, thực hiện chặn yêu cầu chưa hoàn thành trước đó, nếu có, trong cùng một kênh JPIP.

Nếu không có yêu cầu trước đó trong kênh JPIP trường yêu cầu này sẽ được bỏ qua bởi các máy chủ và yêu cầu được coi là không chứa twait với mục đích mô tả tiếp theo. Nếu yêu cầu trước đó trong các kênh JPIP không có trường yêu cầu twait, thời gian chặn mới nhất thu được bằng cách thêm max-wait-usec tính theo micro giây vào thời điểm mà tại đó các máy chủ bắt đầu phục vụ cho yêu cầu trước đó. Nếu có một hoặc nhiều hơn yêu cầu ngay trước đó trong kênh JPIP chứa trường yêu cầu twait, thời gian chặn mới nhất thu được bằng cách thêm các giá trị max-wait-usec của tất cả các yêu cầu, tính theo micro giây, vào thời điểm mà tại đó máy chủ bắt đầu phục vụ các yêu cầu gần nhất trong các kênh không chứa trường yêu cầu twait.

Máy khách sẽ không phát các yêu cầu có chứa cả twait và các trường yêu cầu Đợi.

CHÚ THÍCH: Trong các ứng dụng bao gồm các hoạt ảnh, máy khách thấy nó hữu ích để gửi một loạt các yêu cầu Định giờ Chờ, để các máy chủ có khả năng tối ưu hóa số lần phục vụ thực tế để dành riêng cho mỗi yêu cầu quá hạn, tùy thuộc vào số lần chặn mới nhất tương ứng của chúng.

C.8 Các trường yêu cầu quản lý bộ nhớ đệm

C.8.1 Mô hình (model)

C.8.1.1 Tổng quát

Trường này có thể được sử dụng trong các truyền thông theo phiên hoặc các yêu cầu phi trạng thái. Một yêu cầu truyền thông theo phiên là bất kỳ yêu cầu bao gồm một trường ID Kênh, do các kênh được kết hợp với một phiên quản lý bởi máy chủ. Các trường “model” chứa một hoặc nhiều nhãn mô tả ngăn, mỗi nhãn trong số đó xác định một ngăn dữ liệu, hoặc một loạt các ngăn dữ liệu, về những dấu hiệu thông tin bộ nhớ đệm. Đối với các yêu cầu trong một phiên, thông tin bộ nhớ đệm này phục vụ để cập nhật mô hình của máy chủ về bộ nhớ đệm của máy khách. Chỉ có một mô hình bộ nhớ đệm cho mỗi địa chỉ logic liên quan đến phiên. Đối với một yêu cầu phi trạng thái, mô hình của máy chủ về bộ của nhớ đệm của máy khách là trống tại thời điểm bắt đầu yêu cầu, nhưng được cập nhật bởi trường “model” (nếu có) trước khi máy chủ đề ra đáp ứng của nó. Mọi thông tin mô hình bộ nhớ đệm được xóa bỏ khi máy chủ kết thúc việc xử lý yêu cầu phi trạng thái.

Hai dạng được cung cấp cho các giá trị nhãn mô tả ngăn để tạo thuận lợi cho việc trao đổi thông tin mô hình bộ nhớ đệm hiệu quả. Chúng được gọi là dạng “tường minh” và dạng “ẩn” và được mô tả trong các điều khoản nhỏ dưới đây. Các máy khách có thể đưa ra các yêu cầu sử dụng một trong hai dạng và có thể kết hợp hai dạng nhãn mô tả ngăn trong một trường yêu cầu “model” duy nhất nếu muốn.

Nếu một nhãn mô tả ngăn là được đặt trước bởi biểu tượng “-“, nó được cho là bớt đi. Nếu không, nó được cho là thêm vào. Các thông báo bớt đi nhãn mô tả ngăn cho máy chủ để dữ liệu liên quan được loại bỏ thông tin bộ nhớ đệm của máy khách khỏi mô hình của máy chủ. Các yếu tố được loại bỏ khỏi mô hình bộ nhớ đệm để các máy chủ sẽ không giả định rằng máy khách đã có những yếu tố này. Giá trị nhãn mô tả ngăn được xử lý theo thứ tự.

Một nhãn mô tả ngăn thêm vào (không được đặt trước bởi biểu tượng “-“) thông báo cho các máy chủ dữ liệu đã có trong bộ nhớ đệm của máy khách. Các máy chủ có thể thêm thông tin này cho mô hình bộ nhớ đệm của nó và có thể giả định rằng máy khách đã có dữ liệu đó.

Các trường “model” có thể tham chiếu các ngăn dữ liệu mà không liên quan đến Cửa sổ hiển thị quan tâm được xác định bởi các trường yêu cầu khác (Kích thước Khung hình, Kích thước Vùng, Độ lệch…). Khi đó, các thao tác mô hình bộ nhớ đệm có thể không ảnh hưởng đến đáp ứng của yêu cầu hiện tại, tuy nhiên có thể ảnh hưởng đến đáp ứng của yêu cầu trong tương lai (trừ khi là yêu cầu phi trạng thái).

Bất cứ đâu trong danh sách phần tử dữ liệu mô hình bao gồm một hạn định dòng mã, tất cả các yếu tố dữ liệu mô hình tiếp theo sẽ được thêm vào hoặc bớt đi (nếu thích hợp) từ tất cả các dòng mã có định danh được liệt kê bởi hạn định dòng mã. Hạn định dòng mã có thể được xen kẽ trong suốt danh sách để dần dần làm thay đổi tập dòng mã bị ảnh hưởng bởi các yếu tố dữ liệu mô hình tiếp theo. Bất kỳ yếu tố dữ liệu mô hình mà không được đặt trước bởi một hạn định dòng mã áp dụng cho dòng mã yêu cầu đầu tiên thông qua một trường yêu cầu Dòng mã. Nếu không có trường yêu cầu dòng mã, giá trị yếu tố dữ liệu mà không được đặt trước bởi một hạn định dòng mã sẽ đề cập đến dòng mã 0, bất kể có hay không trường yêu cầu Ngữ cảnh Dòng mã. Nếu cuối cùng id dòng mã cuối cùng không xuất hiện, mà xuất hiện dấu gạch ngang hạn định dòng, thì điều này có nghĩa là chứa id dòng mã đầu tiên và tất cả dòng mã sau đó.

Yêu cầu trong một phiên không bao gồm hạn định dòng mã bất kỳ có sự tham khảo nhiều hơn một dòng mã duy nhất.

CHÚ THÍCH 1: Các máy chủ nên cố gắng khai thác báo cáo thao tác mô hình bộ nhớ đệm thêm vào, nhưng tự do bỏ qua một số hoặc tất cả chúng có thể ảnh hưởng đến việc truyền tải. Máy khách cần phải nhận thức rằng các máy chủ có thể bỏ qua thao tác báo cáo mô hình bộ nhớ đệm thêm vào đề cập đến ngăn dữ liệu thuộc các dòng mã đó sẽ không được phục vụ bởi các yêu cầu hiện tại. Để loại bỏ sự không chắc chắn như vậy trong đó liên quan đến nhiều dòng mã, các trường yêu cầu “mset” có thể được sử dụng để xác định tập các dòng mã đang được mô hình hóa.

CHÚ THÍCH 2: Thao tác trên mô hình bộ nhớ đệm của máy chủ theo phiên thường ảnh hưởng đến đáp ứng của cả yêu cầu hiện tại lẫn các yêu cầu trong tương lai. Hơn nữa, tất cả các kênh trong một phiên có liên quan đến một địa chỉ logic duy nhất chia sẻ cùng mô hình bộ nhớ đệm. Như vậy, trường “model” trong các yêu cầu đến sử dụng một kênh (trường ID Kênh) có thể ảnh hưởng đến đáp ứng yêu cầu đến sử dụng một kênh khác. Điều quan trọng cần lưu ý là yêu cầu sử dụng các kênh khác nhau JPIP (khác giá trị ID Kênh) có thể đến không đồng bộ với máy chủ, nếu các kênh TCP riêng được sử dụng để vận chuyển các yêu cầu hoặc trực tiếp từ máy khách hoặc gián tiếp tại một proxy trung gian. Máy khách nên có hành động cần thiết để đảm bảo rằng hướng dẫn thao tác mô hình bộ nhớ đệm của chúng vẫn còn có ý nghĩa trong trường hợp này.

C.8.1.2 Dạng tường minh

Các giá trị mô tả ngăn dạng tường minh đề cập đến các ngăn dữ liệu sau đây: M (ngăn dữ liệu đặc tả), Hm (ngăn dữ liệu tiêu đề chính), H (ngăn dữ liệu tiêu đề khối ảnh), P (ngăn dữ liệu phân khu) hoặc T (ngăn dữ liệu khối ảnh). Mô tả ngăn dạng tường minh xác định các ngăn dữ liệu liên quan trong các dòng mã có liên quan, bằng cách sử dụng một định danh giá trị nguyên duy nhất, hoặc ký tự đại diện “*”. Trường hợp ngoại lệ duy nhất là ngăn dữ liệu tiêu đề chính dòng mã, chứa mô tả ngăn “Hm”. Đối với tất cả các lớp ngăn dữ liệu khác, định danh duy nhất giống với giá trị truyền tải bởi định danh lớp trong của tiêu đề bản tin dòng JPP hoặc dòng JPT (xem Phụ lục A).

Ký tự đại diện, “*”, chỉ được sử dụng trong các yêu cầu phi trạng thái. Khi nó được sử dụng, mô tả ngăn đề cập đồng thời đến tất cả các ngăn dữ liệu của lớp có liên quan (dữ liệu đặc tả, phân khu, tiêu đề khối ảnh hoặc khối ảnh), liên quan đến Cửa sổ hiển thị.

Mỗi mô tả ngăn được hạn định bởi số lượng byte. Một mô tả ngăn thêm vào được hạn định bởi số lượng byte B, chỉ ra rằng máy khách đã có ít nhất B byte đầu tiên trong ngăn dữ liệu chỉ định được lưu đệm; máy chủ có thể thêm B byte đầu tiên của ngăn dữ liệu vào mô hình bộ nhớ đệm. Một mô tả ngăn bớt đi được hạn định bởi số lượng byte B, chỉ ra rằng máy khách có tối đa B byte đầu tiên trong ngăn dữ liệu được chỉ định; máy chủ sẽ loại bỏ bất kỳ byte nào trong B byte đầu tiên của ngăn dữ liệu khỏi mô hình bộ nhớ đệm.

VÍ DỤ 1: Một mô tả ngăn bớt đi được hạn định chẳng hạn như “-P23:10″ có nghĩa là máy chủ nên loại bỏ 10 byte đầu tiên của ngăn dữ liệu phân khu 23 khỏi mô hình bộ nhớ đệm của nó. Điều này không có nghĩa là máy khách có 10 byte đầu tiên của ngăn dữ liệu phân khu 23 trong bộ nhớ đệm và máy chủ không nên giả định bằng cách thêm các byte vào mô hình bộ nhớ đệm nếu chúng không xuất hiện.

Các mô tả ngăn phân khu các thể dự phòng hạn định bởi số lượng lớp. Một mô tả ngăn thêm vào được hạn định bởi số lượng lớp L, chỉ ra rằng máy khách đã có ít nhất L lớp đầu tiên (L gói đầu tiên) trong phân khu chỉ định; máy chủ có thể thêm các byte tương ứng trong các lớp này vào mô hình bộ nhớ đệm. Một mô tả ngăn phân khu bớt đi được hạn định bởi số lượng lớp L, chỉ ra rằng máy khách có tối đa L lớp (L gói tin) đầu tiên trong phân khu chỉ định; máy chủ sẽ loại bỏ các byte tương ứng trong các lớp kế tiếp của phân khu khỏi mô hình bộ nhớ đệm.

Một mô tả ngăn phân khu không có hạn định number-of-bytes hoặc number-of-layers là ngăn dữ liệu dạng tường minh đầy đủ.

VÍ DỤ 2: “model=M0,Hm,H7:20,P3” có nghĩa là máy khách có ít nhất tất cả: ngăn dữ liệu đặc tả 0, các tiêu đề chính dòng mã, 20 byte đầu tiên của tiêu đề khối ảnh 7, và phân khu 3 được lưu đệm.

VÍ DỤ 3: “model=P3:256,P5:L2,-P6:20” có nghĩa là máy khách có ít nhất: 256 byte đầu tiên của phân khu 3 và hai lớp đầu tiên (gói) của phân khu 5, nhưng (nhiều nhất) không có bất cứ điều gì vượt ra ngoài byte thứ 20 của phân khu 6 (hoặc là nó có thể không có 20 byte đầu tiên).

VÍ DỤ 4: “model=M*,-M5,-H*,-P*:L3“ có nghĩa là máy khách có (hoặc đang chuẩn bị để cho phép các máy chủ tin rằng nó có) tất cả các ngăn dữ liệu đặc tả trừ ngăn dữ liệu đặc tả 5, không có ngăn dữ liệu tiêu đề khối ảnh có liên quan đến Cửa sổ hiển thị và nhiều nhất là 3 lớp đầu tiên của phân khu bất kỳ có liên quan đến Cửa sổ hiển thị. Lưu ý, các ký hiệu sử dụng ở đây được cho phép chỉ khi “model” tuyên bố xuất hiện trong một yêu cầu phi trạng thái.

VÍ DỤ 5: “model=[30-200],Hm,H*,M*,P0,[0-29],-Hm,-H*,-M*,-P*” có nghĩa là máy khách có tất cả các tiêu đề và dữ liệu đặc tả, cộng với ngăn dữ liệu phân khu 0 từ dòng mã từ 30 đến 200, nhưng nó đã loại bỏ tất cả tiêu đề, dữ liệu đặc tả và ngăn dữ liệu đặc tả phân khu từ 30 dòng mã đầu tiên.

C.8.1.3 Dạng ẩn

Các mô tả ngăn dạng ẩn là chỉ áp dụng đối với các yêu cầu dòng JPP. Các giá trị mô tả ngăn dạng ẩn đề cập đến các ngăn dữ liệu sau đây: t (khối ảnh chứa các phân khu), c (thành phần ảnh chứa các phân khu), r (mức phân giải của khối ảnh thành phần chứa các phân khu) hoặc p (vị trí của phân khu trong độ phân giải khối ảnh thành phần). Mô tả ngăn dạng ẩn được sử dụng để xác định các ngăn dữ liệu phân khu thông qua các chỉ số. Tất cả các chỉ số bắt đầu từ 0. Chỉ số mức phân giải 0, r0, đề cập đến mức phân giải thấp nhất (băng con LL) của khối ảnh thành phần. Chỉ số vị trí, p, chạy từ trái sang phải và từ trên xuống của quá trình lũy tiến độ phân giải khối ảnh thành phần, theo kiểu quét dòng, được mô tả trong tiêu chuẩn ISO / IEC 15444 1.

Trong yêu cầu phi trạng thái, bất kỳ hoặc tất cả các khối ảnh, thành phần ảnh, mức phân giải hoặc vị trí đặc tả của ngăn dạng ẩn có thể được thay thế với nhiều chỉ số hoặc ký tự đại diện “*”. Trong cả hai trường hợp, các mô tả ngăn được mở rộng để bao gồm tất cả các giá trị của dãy chỉ số liên quan đến Cửa sổ hiển thị. Không sử dụng các tùy chọn này cho các yêu cầu trong một phiên.

Trong yêu cầu phi trạng thái, bất kỳ hoặc tất cả các chỉ số khối ảnh, thành phần ảnh, mức phân giải hoặc vị trí có thể được thay thế bằng một loạt duy nhất của các chỉ số. Giá trị first-index-pos trong index-range-spec đưa ra chỉ số đầu tiên trong dãy. Giá trị last-index-pos đưa ra chỉ số cuối cùng trong dãy và sẽ là lớn hơn hoặc bằng giá trị first-index-pos. Giá trị last-index-pos không thể không lấy. Nếu một loạt các chỉ số khối ảnh (“t”) được đưa ra, phạm vi đề cập đến một mảng khối ảnh hình chữ nhật mà góc trái trên có giá trị first-index-pos, và có góc dưới bên phải có giá trị last-index-pos. Tương tự, nếu một loạt các chỉ số vị trí (“p”) được đưa ra, phạm vi đề cập đến một mảng hình chữ nhật của vị trí phân khu, các góc trái bên dưới và góc phải bên trên chỉ ra giá trị first-index-pos và last-index-pos, tương ứng. Đối với các ký tự đại diện, phạm vi không được sử dụng trong các yêu cầu trong một phiên.

Mô tả ngăn phân khu dạng ẩn có thể bị hạn định bởi số lượng lớp, mà cú pháp và giải thích là giống hệt với lớp được hạn định bởi mô tả phân khu tường minh.

VÍ DỤ 1: “model=t0c2r3p4:L5” chỉ ra rằng máy khách có 5 khung đầu tiên của phân khu 5 theo thứ tự, ở mức phân giải thứ tư, trong thành phần ảnh thứ ba, của khối ảnh 0.

VÍ DỤ 2: “model=t10r0,t*r1:L4” có nghĩa là máy khách có tất cả các lớp của chỉ số khối ảnh 10 ở mức phân giải 0, và 4 lớp đầu tiên của tất cả các khối ảnh có liên quan đến Cửa sổ hiển thị ở mức phân giải 1. Lưu ý các ký tự đại diện chỉ thích hợp cho các yêu cầu phi trạng thái.

VÍ DỤ 3: “model=t0-10:L2” chỉ ra rằng máy khách có 2 lớp đầu tiên từ khối ảnh 0 đến 10. Lưu ý rằng phạm vi chỉ thích hợp cho các yêu cầu phi trạng thái.

VÍ DỤ 4: “model=t*r0-2:L4″ chỉ ra rằng máy khách có 4 lớp đầu tiên từ mức phân giải 0 đến 2 của tất cả các khối ảnh liên quan đến Cửa sổ hiển thị. Lưu ý rằng các ký tự đại diện và phạm vi là chỉ thích hợp cho các yêu cầu phi trạng thái.

C.8.2 Tóm tắt các tùy chọn mô tả bộ nhớ đệm (Tham khảo)

Bảng C.5 – Tóm tắt các tùy chọn mô tả bộ nhớ đệm

Dạng	Ký tự đại diện		Index-range	number-of-layers (ví dụ, “:L3″)	number-of-bytes (ví dụ, “:256”)
Dạng	Không trạng thái	Truyền thông theo phiên	Index-range	number-of-layers (ví dụ, “:L3″)	number-of-bytes (ví dụ, “:256”)
Dạng tường minh	Cho phép	Không cho phép	Không cho phép	Cho phép	Cho phép
Dạng ần	Cho phép	Không cho phép	Cho phép đối với phi trạng thái	Cho phép	Không cho phép

C.8.3 Mô hình phần khối ảnh liên quan đến các dòng JPT (tpmodel)

Trường này có thể được sử dụng để chỉ ra các phần khối ảnh cụ thể mà máy khách muốn thêm vào hoặc bớt đi khỏi mô hình bộ nhớ đệm của máy chủ. Cũng giống như các trường “model”, nó có thể được sử dụng trong cả yêu cầu truyền thông theo phiên và yêu cầu phi trạng thái. Trong trường hợp yêu cầu phi trạng thái, mô hình bộ nhớ đệm là rỗng tại thời điểm bắt đầu yêu cầu và không tiếp tục giữa các yêu cầu, nhưng nó vẫn cung cấp một cơ chế hữu ích để xác định các yếu tố hình ảnh đã có trong bộ nhớ đệm của máy khách.

Nếu một mô tả phần khối ảnh được đặt trước bởi ký tự “-“, nó được coi là bớt đi. Nếu không thì nó là thêm vào. Một mô tả phần khối ảnh thêm vào chỉ ra rằng máy khách đã sẵn sàng chỉ ra phần khối ảnh hoặc một loạt các phần khối ảnh trong bộ nhớ đệm; máy chủ có thể thêm các yếu tố này vào mô hình bộ nhớ đệm. Một mô tả phần khối ảnh bớt đi chỉ ra rằng máy khách không chỉ ra phần khối ảnh hoặc một loạt phần khối ảnh trong bộ nhớ đệm; máy chủ sẽ loại bỏ các yếu tố này khỏi từ mô hình bộ nhớ đệm.

Giá trị đầu tiên của phần khối ảnh là chỉ số khối ảnh (bắt đầu từ 0); giá trị thứ hai là số thứ tự phần (bất đầu từ 0) trong khối ảnh. Một tp-range được coi là độc lập bao gồm các khối ảnh từ khối ảnh đầu tiên tới khối ảnh thứ hai và các phần khối ảnh từ phần khối ảnh đầu tiên đến phần khối ảnh thứ hai. Vì vậy 4,0-5,1 bao gồm các phần khối ảnh 4.0, 4.1, 5.0, và 5.1, chứ khống phải 4.2 hay 5.2.

Các trường “tpmodel” và “model” cùng xuất hiện trong một yêu cầu duy nhất. Trong trường hợp này, máy chủ phải phản ánh những tác động của trường “model” trên mô hình bộ nhớ đệm của nó trước khi xử lý các trường “tpmodel”.

Giá trị Hạn định dòng mã có thể được xen kẽ giữa danh sách các tpmodel-element để làm thay đổi tập các dòng mã mà tpmodel-element tiếp theo áp dụng, thực hiện đúng các nguyên tắc tương tự như đối với trường yêu cầu “model”.

CHÚ THÍCH: Không giống như trường yêu cầu “model”, phạm vi của các phần khối ảnh và phạm vi của các dòng mã (trong Hạn định dòng mã) đều được cho phép trong trường yêu cầu “tpmodel”, bất kể là xuất hiện trong yêu cầu truyền thông theo phiên hoặc phi trạng thái.

VÍ DỤ 1: “tpmodel=4.0,4.1,5.0-6.2″ chỉ ra rằng máy khách đã có hai phần khối ảnh đầu tiên của khối ảnh 4, và 3 phần khối ảnh của khối ảnh 5 và 6 trong bộ nhớ đệm.

VÍ DỤ 2: “tpmodel=-4.0-6.254” chỉ ra rằng máy khách không có phần khối ảnh nào trong khối ảnh 4, 5 hoặc 6 trong bộ nhớ đệm.

Ví dụ 3: “tpmodel=3,0,[131-133],4.0,[100],-0,0-65.534,254″ chỉ ra rằng máy khách có phần khối ảnh 0 của khối ảnh 3 từ dòng mã 0 tham chiếu trong yêu cầu, cộng với phần khối ảnh 0 của khối ảnh 4 từ dòng mã 131 đến 133, và nó được phép xóa tất cả các phần khối ảnh khỏi bộ nhớ đệm của dòng mã 100.

C.8.4 Trường Nhu cầu đối với yêu cầu phi trạng thái (need)

Trường này có thể chỉ xuất hiện trong các yêu cầu phi trạng thái nghĩa là không bao gồm trường yêu cầu ID Kênh. Nó có cú pháp tương tự như trường yêu cầu mô hình, ngoại trừ mô tả ngăn sẽ không được đặt trước bởi một biểu tượng “-“. Trường yêu cầu “need” sẽ không xuất hiện trong cùng một yêu cầu như là trường yêu cầu “model” hoặc “tpmodel“.

Trường yêu cầu “need” chỉ ra tập các ngăn dữ liệu (hoặc ngăn dữ liệu thỏa mãn) là mối quan tâm chính của máy khách. Các máy chủ không cần gửi thông tin không phải mối quan tâm chính. Bất kể tập các ngăn dữ liệu quan tâm chính lớn đến mức nào, máy chủ chỉ cần gửi thông tin có liên quan đến trường yêu cầu Cửa sổ hiển thị hoặc trường yêu cầu dữ liệu đặc tả.

Hiệu quả của trường “need” theo yêu cầu của máy chủ có thể được giải thích bằng cách sử dụng khái niệm về mô hình bộ nhớ đệm tạm thời. Mô hình bộ nhớ đệm tạm thời được khởi tạo (trống) ngay lập tức trước khi yêu cầu được xử lý và loại bỏ sau khi đáp ứng được tạo ra. Nếu một trường “need” xuất hiện trong yêu cầu, thì có thể tất cả các ngăn dữ liệu được thêm vào các mô hình bộ nhớ đệm, sau đó tất cả các yếu tố tham chiếu bởi mô tả ngăn trong trường “need” được loại bỏ khỏi mô hình bộ nhớ đệm. Sau đó các máy chủ xử lý yêu cầu Cửa sổ hiển thị, sử dụng mô hình bộ nhớ đệm này để xác định các yếu tố mà không cần phải gửi cho máy khách.

Hạn định dòng mã có thể được xen kẽ giữa danh sách các mô tả ngăn để làm thay đổi tập các dòng mã mà tiếp mô tả ngăn tiếp theo được áp dụng, thực hiện đúng các nguyên tắc tương tự như đối với trường yêu cầu “model” và “tpmodel”.

VÍ DỤ 1: “need=M1,H0:20,P0” có nghĩa là máy khách cần tất cả ngăn dữ liệu đặc tả 1, dữ liệu từ byte thứ 20 của ngăn dữ liệu tiêu đề khối ảnh 0 và tất cả các ngăn dữ liệu phân khu 0.

VÍ DỤ 2: “need=P1:256,P5:L2” có nghĩa là máy khách cần dữ liệu ngoài byte thứ 256 (hoặc từ byte 256) của ngăn dữ liệu phân khu 1 và lớp ngoài lớp thứ 2 của ngăn dữ liệu phân khu 5.

VÍ DỤ 3: “need=H*,P*:L3″ có nghĩa là máy khách cần tất cả ngăn dữ liệu tiêu đề có liên quan đến Cửa sổ hiển thị và các lớp ngoài lớp thứ 3 của tất cả các ngăn dữ liệu phân khúc có liên quan đến Cửa sổ hiển thị.

VÍ DỤ 4: “need=t10r0,t*r1:L4″ có nghĩa là máy khách cần tất cả các lớp của chỉ số khối ảnh 10 ở mức phân giải 0, và các lớp ngoài lớp thứ 4 của tất cả các khối ảnh có liên quan đến Cửa sổ hiển thị ở mức phân giải 1.

VÍ DỤ 5: “need=t*r0-2:L4″ có nghĩa là máy khách cần tất cả các lớp từ lớp 4 của tất cả các ngăn dữ liệu ở mức phân giải 0 đến 2 (0,1 và 2) trong tất cả các khối ảnh và thành phần ảnh liên quan đến yêu cầu Cửa sổ hiển thị.

VÍ DỤ 6: “need=[120-131],r0,[140;143-145],r0-1″ có nghĩa là máy khách cần mức phân giải 0 của các dòng mã 120 đến 131, và mức phân giải 0 và 1 của các dòng mã 140 và 143 đến 145.

C.8.5 Trường Nhu cầu phần khối ảnh đối với yêu cầu phi trạng thái (tpneed)

Trường này chỉ xuất hiện trong các yêu cầu phi trạng thái, nghĩa không bao gồm trường yêu cầu ID Kênh. Nó có cú pháp tương tự như các trường yêu cầu tpmodel, ngoại trừ mô tả phần khối ảnh sẽ không được đặt trước bởi biểu tượng “-“. Các trường yêu cầu “tpneed” sẽ không xuất hiện trong cùng một yêu cầu như hoặc trường yêu cầu “model” và “tpmodel”.

Trường yêu cầu “tpneed” chỉ ra tập các phần khối ảnh là quan tâm chính của máy khách. Các máy chủ không cần gửi thông tin không phải là quan tâm chính. Bất kể tập các phần khối ảnh quan tâm chính lớn đến mức nào, máy chủ chỉ cần gửi thông tin có liên quan đến các trường yêu cầu Cửa sổ hiển thị hoặc trường yêu cầu dữ liệu đặc tả.

Hiệu quả của trường “tpneed” theo yêu cầu của máy chủ có thể được giải thích bằng cách sử dụng khái niệm về một mô hình bộ nhớ đệm tạm thời. Mô hình bộ nhớ đệm tạm thời được khởi tạo (trống) ngay lập tức trước khi yêu cầu được xử lý và loại bỏ sau khi đáp ứng được tạo ra. Nếu trường “tpneed” xuất hiện trong yêu cầu, tất cả có thể phần khối ảnh và ngăn dữ liệu được thêm vào mô hình bộ nhớ đệm, sau đó tất cả các yếu tố tham chiếu bởi mô tả ngăn trong trường “need” và tất cả phần khối ảnh trong trường “tpneed” bị loại bỏ khỏi mô hình bộ nhớ đệm. Máy chủ xử lý yêu cầu Cửa sổ hiển thị, sử dụng mô hình bộ nhớ đệm này để xác định các yếu tố mà không cần phải gửi cho máy khách.

Hạn định dòng mã có thể được xen kẽ giữa danh sách các phần khối ảnh để làm thay đổi tập các dòng mã mà phần khối ảnh tiếp theo áp dụng, thực hiện đúng các nguyên tắc tương tự như đối với trường yêu cầu “model” và “tpmodel”.

C.8.6 Tập mô hình đối với yêu cầu trong phiên (mset)

mset = “mset” “=” 1#sampled-range

Trường này phục vụ hai mục đích. Trong trường hợp đầu tiên, nó thông báo cho máy chủ tập các dòng mã mà máy khách sẵn sàng để lưu đệm dữ liệu cung cấp bởi các máy chủ. Trong trường hợp thứ hai, nó cung cấp một cơ chế cho phép máy khách học các dòng mã mà máy chủ được chuẩn bị để mô hình hóa bộ nhớ đệm của máy khách. Cụ thể, nếu tập các chỉ số dòng mã cung cấp trong yêu cầu “mset” khác nhau bằng bất kỳ cách nào từ tập các dòng mã qua đó các máy chủ hiện hành chuẩn bị cung cấp mô hình bộ nhớ đệm, máy chủ sẽ cung cấp một tiêu đề đáp ứng Tập Mô hình, như đã thảo luận trong Điều D.2.18.

Chuỗi tham số của trường yêu cầu “mset” bao gồm một danh sách dấu phẩy tách của một loạt các chỉ số dòng mã, có thể là mẫu phụ, theo sau các quy ước được phác thảo khi kết nối với trường yêu cầu Dòng mã trong Điều C.4.6.

Ngoài những dòng mã đề cập trong yêu cầu “mset”, máy chủ cũng có thể cung cấp một mô hình bộ nhớ đệm cho tất cả dòng mã liên quan đến đáp ứng của yêu cầu hiện tại. Đây là tập các dòng mã xác định theo yêu cầu của máy khách (xem trường yêu cầu Ngữ cảnh Dòng mã và Dòng mã trong Điều C.4.7), trừ khi máy chủ chỉ ra một tập các dòng mã bị giảm thông qua tiêu đề đáp ứng Dòng mã (xem D.2.9). Nếu không cung cấp trường yêu cầu “mset”, máy khách không nên cho rằng máy chủ cung cấp một mô hình bộ nhớ đệm cho dòng mã bất kỳ không liên quan đến đáp ứng của nó. Tuy nhiên, nó có thể mô hình hóa dòng mã khác. Nếu một trường yêu cầu “mset” được xác định, máy chủ sẽ loại bỏ bất kỳ thông tin mô hình bộ nhớ đệm cho tất cả các dòng mã khác được quy định hoặc trong các yêu cầu “mset”, hoặc trong tập các dữ liệu liên quan đến dòng mã đáp ứng của nó. Hơn nữa, ảnh hưởng của thao tác mô hình bộ nhớ đệm bất kỳ thông qua trường yêu cầu “model” hoặc “tpmodel” sẽ được giới hạn đến những dòng mã.

Các máy chủ có thể, theo quyết định của mình, giảm số lượng dòng mã trong “mset”, trong trường hợp này, nó sẽ cung cấp tiêu đề đáp ứng “mset” xác định tập các dòng mã thực tế đang được mô hình hóa. Tập dòng mã được mô hình này phải bao gồm ít nhất tất cả dòng mã liên quan đến dữ liệu đáp ứng của máy chủ (những yêu cầu theo yêu cầu của máy khách, hoặc xác định bởi tiêu đề đáp ứng Dòng mã của máy chủ, nếu có). Trong trường hợp này, các báo cáo này áp dụng cho các dòng mã chứa trong “mset” xác định bởi máy chủ. Các máy chủ có thể không xác định tập các dòng mã lớn hơn so các tập được đề cập trong “mset” theo yêu cầu của máy khách, kết hợp với những dòng mã được gán cho dữ liệu đáp ứng của máy chủ.

Lưu ý rằng các máy chủ có thể thay đổi “mset” của nó theo từng yêu cầu, vì vậy máy khách cần phải theo dõi và hạn chế “mset” của máy chủ có thể lựa chọn để bao gồm trường yêu cầu “mset” với mọi yêu cầu.

C.9 Các tham số yêu cầu Tải lên

C.9.1 Tải lên (upload)

upload = “upload” “=” upload-type

upload-type = image-return-type

Trường này chỉ ra rằng máy khách được tải hình ảnh hoặc dữ liệu đặc tả mới lên máy chủ. Giá trị của upload-type có thể là giá trị image-return-type bất kỳ được sử dụng cho loại trường yêu cầu. Xem Phụ lục E để biết thông tin về việc tải lên dữ liệu.

C.10 Các trường yêu cầu tham chiếu và năng lực của máy khách

C.10.1 Năng lực máy khách (cap)

Trường này xác định năng lực của máy khách. Đối với các yêu cầu truyền thông theo phiên (trong đó bao gồm trường yêu cầu ID Kênh), các trường năng lực bất kỳ được truyền bởi máy khách chỉ ảnh hưởng đến các kênh gán với các yêu cầu, và được cân nhắc liên tục. Năng lực không cần được truyền lại bởi máy khách cho các yêu cầu tiếp theo trên cùng một kênh.

Khi một kênh mới được tạo ra từ một kênh hiện có, năng lực máy khách của nó được kế thừa. Đối với yêu cầu phi trạng thái, và các yêu cầu đã phát đi trong một kênh thì năng lực đó không bao giờ được xác định hoặc kế thừa, năng lực máy khách có thể được xác định hoặc dự đoán bằng các cách khác nhau. Các khả năng liến kết với kênh có thể được thay đổi bằng cách chứa trường yêu cầu Năng lực Máy khách trong yêu cầu.

Nếu trường yêu cầu Năng lực Máy khách xác định một hoặc một số các tùy chọn processing- capability, máy chủ sẽ giả định rằng máy khách không có bất kỳ tùy chọn processing-capability được đề cập. Nếu không cung cấp các tùy chọn processing-capability trong trường yêu cầu Năng lực Máy khách, máy chủ sẽ tiếp tục sử dụng bất cứ điều gì mà nó biết trước đó nó để cân nhắc năng lực xử lý. Các tùy chọn processing-capability, theo quy định của tiêu chuẩn này được mô tả trong Bảng C.6.

Bảng C.6 – Năng lực hợp lệ của các yếu tố processing-capabilitie

Năng lực	Ý nghĩa
compatibility-capability	Các máy khách hỗ trợ tất cả các tập tin có compability-code trong danh sách tương thích trong khung Loại Tập tin. Ví dụ, để chỉ ra rằng máy khách hỗ trợ tất cả các tập tin JP2, máy khách sẽ truyền “cc.jp2_” trong trường yêu cầu Năng lực. Giá trị compability-code của “jp2c” sẽ được sử dụng để chỉ ra hỗ trợ đối với các dòng mã JPEG 2000 thô.
vendor-capability	Các máy khách hỗ trợ năng lực nhà cung cấp được xác định bởi mã nhà cung cấp. Mã nhà cung cấp sẽ là một chuỗi xác định tên miền ngược của các nhà cung cấp xác định tính năng này, theo sau là tên tính năng nhà cung cấp. Ví dụ, nếu example.com xác định tính năng gọi là “distance”, thì giá trị mã nhà cung cấp cho tính năng này sẽ là “com.example.distance”. Mã nhà cung cấp xác định một giá trị tùy chọn, được quy định bởi nhà cung cấp tính năng đặc biệt.

Nếu cung cấp tham số depth-capability, nó chỉ ra độ sâu bit mẫu tối đa (độ chính xác) mà tại đó máy khách có thể khai thác hình ảnh giải nén. Nếu máy khách hỗ trợ độ sâu bít khác nhau cho các thành phần ảnh khác nhau, thì trường này quy định cụ thể độ sâu bit của các thành phần ảnh mà máy khách có năng lực độ sâu bit lớn nhất.

CHÚ THÍCH 1: Nếu một máy khách hỗ trợ 12 bit cho độ sáng và 8 bit cho độ màu sắc, thì giá trị depth-capability là 12.

CHÚ THÍCH 2: Máy khách có khả năng xử lý chỉ có N bit cho mỗi mẫu sẽ vẫn có thể xử lý các dòng mã có nhãn SIZ chỉ ra độ sâu bit lớn hơn N. Tuy nhiên, cờ này có thể được sử dụng bởi các máy chủ xác định cách thích hợp để gửi dữ liệu hình ảnh được yêu cầu.

Nếu một tham số config-capability được cung cấp, nó sẽ nằm trong khoảng 0 đến 255, biểu diễn bởi một từ 8-bit có các bit riêng được hiểu như là những cờ cấu hình. Việc giải thích những cờ cấu hình được đưa ra trong Bảng C.7.

Bảng C.7 – Các giá trị hợp pháp của các tham số config-capability

Giá trị	Ý nghĩa
1xxx yyyy	Các máy khách có khả năng xử lý dữ liệu ảnh màu.
0xxx yyyy	Các máy khách không có khả năng xử lý dữ liệu ảnh màu và mong muốn các máy chủ truyền tải vùng ảnh bất kỳ dưới dạng đa mức xám.
x1xx yyyy	Các máy khách có thiết bị trỏ tương tác cho người dùng cuối
x0xx yyyy	Các máy khách không có thiết bị trỏ tương tác cho người dùng cuối
xx1x yyyy	Các máy khách có bàn phím tương tác cho người dùng cuối
xx0x yyyy	Các máy khách không có bàn phím tương tác cho người dùng cuối
xxx1 yyyy	Các máy khách có năng lực đầu ra âm thanh
xxx0 yyyy	Các máy khách không có năng lực đầu ra âm thanh
Giá trị khác	Dành riêng cho ISO sử dụng

Giá trị bit của “x” trong Bảng C.7 chỉ ra rằng giá trị quy định bao gồm các bit được thiết lập hoặc là “1” hoặc là “0”. Các bit chỉ thị “y” không được sử dụng trong tiêu chuẩn này và được thiết lập là 0 bởi máy khách và bỏ qua tại máy chủ.

C.10.2 Tham chiếu máy khách (pref)

C. 10.2.1 Tổng quát

Trường này xác định tham chiếu của máy khách đối với hành vi máy chủ. Đối với yêu cầu truyền thông theo phiên (trong đó bao gồm trường yêu cầu ID Kênh), các trường tham chiếu bất kỳ được truyền đi bởi máy khách sẽ chỉ ảnh hưởng đến các kênh gán với các yêu cầu, và sẽ được cân nhắc liên tục. Tham chiếu không cần phải được truyền lại bởi máy khách cho các yêu cầu tiếp theo trên cùng một kênh. Mỗi tham chiếu sẽ được thực hiện không quá một lần trong trường yêu cầu tham chiếu đơn.

Khi một kênh mới được tạo ra từ kênh hiện có, tham chiếu của nó được kế thừa. Đối với yêu cầu phi trạng thái, và các yêu cầu phát đi trong một kênh thì tham chiếu không bao giờ được xác định hoặc kế thừa, tham chiếu máy khách có thể được quyết định hoặc dự đoán bằng các phương pháp khác nhau. Nếu máy khách mong muốn thay đổi tham chiếu của nó, nó sẽ gửi lại toàn bộ related-pref-set bị ảnh hưởng.

Trừ khi có quy định khác, mỗi related-pref-set ghi rõ danh sách sắp xếp các tham chiếu riêng, từ tham chiếu tối đa đến tham chiếu tối thiểu. Nếu có thể, máy chủ phải tôn trọng tham chiếu máy khách được xác định trong trường yêu cầu này. Nếu related-pref-set theo sau bổ ngữ “/ r” (bắt buộc), máy chủ hoặc là hỗ trợ một trong những tham chiếu được liệt kê trong related-pref-set, hoặc nó sẽ phản ứng với một lỗi. Trong trường hợp cuối cùng, máy chủ sẽ trả về một tiêu đề đáp ứng tham chiếu Không có sẵn trong related-pref-set bất kỳ không hỗ trợ bổ ngữ “/ r”. Xem D.2.23 để biết thêm chi tiết về các tiêu đề đáp ứng tham chiếu Không có sẵn. Hỗ trợ cách tham chiếu có nghĩa là các máy chủ cung cấp chức năng ảnh hưởng đến hành vi của nó phù hợp với tham chiếu. Các địa chỉ này đề cập đến chức năng của máy chủ hơn là các thông số cụ thể được thiết lập bởi các khía cạnh khác của yêu cầu.

Ví dụ, xem xét các yêu cầu Tham chiếu Máy khách như sau:

pref=fullwindow/r, color-ricc:2;color-icc

Yêu cầu tham chiếu này cần máy chủ trả về yêu cầu Cửa sổ hiển thị hoàn chỉnh, bất kể Cửa sổ yêu cầu lớn đến mức nào (xem C.10.2.2 đối với thảo luận về tham chiếu “fullwindow”). Do bổ ngữ “/ r” đã được sử dụng, máy chủ phải trả về đáp ứng lỗi trừ khi nó có thể hỗ trợ tham chiếu này. Ngoài ra, máy khách muốn sử dụng các hồ sơ ICC Hạn chế chứ không phải là hồ sơ ICC tùy ý, cung cấp hồ sơ ICC Hạn chế tối thiểu là “exceptional quality”. Xem C.10.2.3 đối với thảo luận về tham chiếu không gian màu.

Một máy chủ sẽ bỏ qua bất kỳ giá trị related-pref-set mà nó không hiểu và không theo sau “/r”. Nếu giá trị không hiểu theo sau “/r“, thì máy chủ sẽ trả về tiêu đề đáp ứng tham chiếu Không có sẵn, chỉ ra tham chiếu không có khả năng thực hiện.

Giá trị của thẻ khác được dành riêng cho ISO sử dụng.

C.10.2.2 Tham chiếu xử lý Cửa sổ hiển thị

view-window-pref = “fullwindow” / “progressive”

Tiêu chuẩn này có hai tùy chọn để xác định hành vi của các máy chủ trong trường hợp yêu cầu không thể được phục vụ một cách chính xác như đã nêu. Hai lựa chọn được quy định tại Bảng C.8.

Bảng C.8 – Các mong muốn xử lý view-window

Lựa chọn	Ý nghĩa
“fullwindow”	Các máy chủ sẽ thực hiện các thông số yêu cầu Cửa sổ hiện thị được phép gửi dữ liệu theo thứ tự tùy ý. Trong trường hợp máy chủ không thay đổi tham số yêu cầu Cửa sổ hiện thị, thì cửa sổ hiển thị sửa đổi phải đáp ứng hoàn toàn tập dữ liệu tối thiểu, Cửa sổ hiển thị sửa đổi được đồng nhất với tập dữ liệu tối thiểu cần thiết để đáp ứng các yêu cầu Cửa sổ hiển thị ban đầu.
“progressive”	Các máy chủ có thể thay đổi các tham số yêu cầu Cửa sổ hiển thị để giữ lại các đặc tính lũy tiến của dữ liệu đáp ứng. Trong trường hợp máy chủ không thay đổi tham số yêu cầu Cửa sổ hiển thị. Cửa sổ hiển thị sửa đổi thì cửa sổ hiển thị sửa đổi phải đáp ứng hoàn toàn tập dữ liệu tối thiểu, Cửa sổ hiển thị sửa đổi là tập con của tập dữ liệu tối thiểu cần thiết để đáp ứng yêu cầu Cửa sổ hiển thị ban đầu.

Nếu cả “fullwindow” lẫn “progressive” đều không được quy định trong trường yêu cầu Tham chiếu Máy khách, máy chủ sẽ kết luận tham chiếu máy khách là “progressive”.

Máy chủ sẽ bỏ qua bất kỳ giá trị related-pref-set mà nó không hiểu và không theo sau “/r“. Nếu giá trị không hiểu theo sau “/r“, thì máy chủ sẽ trở về tiêu đề đáp ứng tham chiếu Không có sẵn, chỉ ra tham chiếu không có khả năng thực hiện.

Giá trị của thẻ khác được dành riêng cho ISO sử dụng.

CHÚ THÍCH: Giải thích cho việc chuyển tiếp “progressive” có thể bi ảnh hưởng bởi sự hiện diện của một trường yêu cầu Tốc độ Chuyển tiếp, như trong Điều C.7.4. Các trường view-window-pref field cung cấp các kế hoạch cho máy chủ hoạt động bởi các ràng buộc về nguồn để thỏa mãn yêu cầu không vượt quá các nguồn tài nguyên này. Chế độ “progressive” cho phép các máy chủ thu nhỏ cửa sổ gốc để cung cấp lũy tiến đồng đều qua Cửa sổ hiển thị, trong khi chế độ “fullwindow” cho phép máy chủ sắp xếp lại dữ liệu tùy ý theo thứ tự để cung cấp cửa sổ đầy đủ.

C.10.2.3 Tham chiếu phương pháp không gian màu

Tiêu chuẩn này xác định bốn tùy chọn chỉ ra các dạng dữ liệu đặc tả không gian màu nên được trả về bởi máy chủ. Một tập tin JPEG 2000 có thể chứa nhiều đặc tả không gian màu cho một dòng mã đơn hoặc lớp hợp thành. Điều này cho phép trình ghi tập tin cung cấp đặc tả không gian màu tối ưu trong khi vẫn cung cấp các giải pháp tương thích.

Tuy nhiên, không phải tất cả các trình đọc hỗ trợ tất cả các phương pháp không gian màu, và các dữ liệu được cung cấp cho một số phương pháp không gian màu có kích thước có nghĩa. Trong những trường hợp này, máy chủ chỉ cần gửi dữ liệu đặc tả không gian màu mà máy khách mong muốn.

Nếu trường yêu cầu Tham chiếu Máy khách không chứa bất kỳ tham chiếu phương pháp không gian màu hoặc máy chủ không hỗ trợ trường này nhưng có thể khôi phục lại Năng lực máy khách, thì các phương pháp không gian màu hỗ trợ được xác định theo các thông tin trong trường Năng lực, và không xác định tham chiếu.

Mỗi tham chiếu phương pháp không gian màu bao gồm hai phần: phương pháp không gian màu đặc biệt, và giới hạn tùy chọn theo tham chiếu đó. Giá trị hợp lệ của phương pháp không gian màu được quy định tại Bảng C.9.

Bảng C.9 – Tham chiếu máy khách phương pháp không gian màu

Phương pháp	Ý nghĩa
“color-enum”	Máy khách muốn sử dụng Phương pháp Liệt kê đặc tả không gian màu
“color-ricc”	Máy khách muốn sử dụng các Phương pháp ICC Hạn chế đặc tả không gian màu
“color-icc”	Máy khách muốn sử dụng Phương pháp ICC bất kỳ đặc tả không gian màu
“color-vend”	Máy khách muốn sử dụng Phương pháp Nhà cung cấp đặc tả không gian màu

Các giá trị meth-limit tùy chọn quy định cụ thể giới hạn về giá trị APPROX đối với phương pháp không gian màu đặc biệt. Khi sử dụng tham chiếu để lựa chọn đặc tả không gian màu, máy chủ sẽ xem xét một đặc tả phương pháp không gian màu với giá trị APPROX của meth-limit hoặc nhỏ hơn nếu giá trị APPROX thực tế là 1 (chính xác). Điều này cho phép máy khách xác định thời điểm mà độ trung thực màu sắc không quan trọng đối với một phương pháp không gian màu đặc biệt, đối với các ứng dụng hiện tại. Ví dụ, một ứng dụng page-layout là chỉ quan tâm đến việc sắp xếp các dữ liệu hình ảnh với các yếu tố khác trên trang đó mà không quan tâm về độ trung thực màu sắc và thiết lập meth-limit là 4, có nghĩa là độ chính xác của phương pháp không gian màu là không quan trọng. Một ứng dụng hiển thị hình ảnh trên một màn hình chất lượng thấp có thể thiết lập meth-limit là 3, để chỉ ra rằng miễn là màu sắc chính xác là hợp lý, nó sẽ được thỏa mãn. Các ký tự của trường này được giải thích như là một số nguyên thập phân không dấu. Giá trị cho phép được xác định bởi định nghĩa của trường APPROX trong Bảng M.24 của tiêu chuẩn ISO / IEC 15.444-2, và phần mở rộng, sửa đổi cho tiêu chuẩn đó. Nếu tùy chọn giá trị meth-limit không được cung cấp, giá trị mặc định là giá trị lớn nhất được định nghĩa trong tiêu chuẩn.

Khi lựa chọn khung Đặc tả Không gian màu để truyền tải đến máy khách, máy chủ sẽ sử dụng các thuật toán sau đây, như thể hiện trong Hình C.3.

Hình C.3 – Thủ tục lựa chọn khung Đặc tả Không gian màu

Đối với mỗi khung Đặc tả Không gian màu sử dụng một phương pháp được hỗ trợ bởi các máy khách, trong đó:

– spec[] là một mảng chứa tất cả các khung Đặc tả Không gian màu từ các địa chỉ logic cho trước.

– spec[i].APPROX là giá trị của trường APPROX cho khung Đặc tả Không gian màu thứ i xuất hiện trong địa chỉ logic.

– spec[i].METH là giá trị của trường, METH cho khung Đặc tả Không gian màu thứ i xuất hiện trong địa chỉ logic.

– spec[i].PREC là giá trị của trường PREC cho khung Đặc tả Không gian màu thứ i xuất hiện trong địa chỉ logic.

– limit[] là một mảng chứa các giá trị meth-limit quy định trong trường yêu cầu, lập chỉ mục của các giá trị hợp lệ của trường METH trong cho khung Đặc tả Không gian màu.

– priority[] là một mảng các giá trị ưu tiên tính toán cho mỗi khung Đặc tả Không gian màu xuất hiện trong địa chỉ logic cho trước. priority[i] tương ứng để spec[i].

Nếu máy chủ biết máy khách không hỗ trợ một khung khung Đặc tả Không gian màu đặc biệt, thì máy Chủ sẽ bỏ qua khung cho các mục đích lựa chọn tham chiếu khung Đặc tả Không gian màu. Khi giá trị priority[] đã được tính toán cho mỗi khung khung Đặc tả Không gian màu, máy chủ sẽ chọn khung với giá trrị ưu tiên thấp nhất. Trong trường hợp nhiều khung có một giá trị ưu tiên bằng giá trị tối thiểu cho địa chỉ logic này, máy chủ sẽ lựa chọn phương pháp không gian màu sử dụng theo thứ tự ưu tiên sau đây:

1) Phương pháp liệt kê;

2) Phương pháp nhà cung cấp;

3) Phương pháp ICC Hạn chế;

4) Phương pháp ICC bất kỳ.

Không phụ thuộc vào mong muốn của máy khách cho các Đặc tả Không gian màu, máy chủ có thể trở về nhiều khung Đặc tả Không gian màu hơn so với khung màu đơn theo quy định của thuật toán này, tùy thuộc vào sự phân chia của một tập tin vào ngăn dữ liệu đặc tả.

C.10.2.4 Băng thông Tối đa

Tham chiếu này này báo hiệu tốc độ tối đa mà máy khách muốn gửi dữ liệu trên một địa chỉ logic. Nếu giá trị mbw kết thúc bằng “K” thì giá trị tính theo kilobit / giây, trong đó 1 kilobit = 1024 bit. Nếu giá trị mbw kết thúc bằng “M” thì giá trị tính theo megabit / giây, trong đó 1 megabit = 1024² bit. Nếu giá trị mbw kết thúc bằng “G“, thì giá trị tính theo gigabit / giây, trong đó 1 gigabit = 1024³ bit. Nếu giá trị mbw kết thúc bằng chữ “T“, thì giá trị tính theo terabit / giây, trong đó 1 terabit = 1024⁴ bit. Nếu không, giá trị tính theo bit / giây. Hoặc tùy thuộc vào năng lực của máy chủ hoặc mạng có thể tiếp tục giới hạn băng thông tối đa có sẵn cho các dịch vụ JPIP.

C.10.2.5 Phân bổ băng thông

Tham chiếu này có thể được sử dụng để xác định các phần của băng thông có sẵn được phân bổ cho các kênh này. Giá trị của Slice phải lớn hơn 0. Các phần băng thông thu được bằng cách chia giá trị Slice mỗi kênh cho tổng của tất cả các giá trị Slice kênh. Nếu không quy định, giá trị Slice mặc định của kênh là 1.

Ví dụ, một giá trị Slice thấp có thể được sử dụng để yêu cầu một cửa sổ hiển thị “nền”, trong khi một Slice cao hơn có thể được sử dụng cho cửa sổ hiển thị “tiền cảnh”. Nếu phiên có các kênh có liên quan đến các địa chỉ logic khác nhau, giá trị Slice ảnh hưởng đến tỷ lệ băng thông có sẵn mà được gán cho những địa chỉ đó (hình ảnh).

C.10.2.6 Tham chiếu chờ

Tham chiếu này có thể được sử dụng để chỉ ra cách xử lý các khung Chờ. Trường hợp khung Chờ xuất hiện trong dữ liệu đặc tả trong dòng JPP hoặc dòng JPT, có thể có 3 cách biểu diễn nội dung khung khác: khung ban đầu; khung tương đương dòng; và dòng mã tăng dần (dấu hiệu thông qua chỉ số). Các khả năng này được giải thích trong Điều A.3.6 và A.4. Như đã giải thích trong Điều A.4, mặc định các máy khách muốn nhận dòng mã tăng dần, nếu có, nó không muốn nhận khung tương đương dòng, nếu có. Máy khách có dấu hiệu tham chiếu thay thế sử dụng cơ chế được mô tả ở đây. Giá trị hợp lệ của tham chiếu chờ được quy định trong Bảng C.10.

Bảng C.10 – Tham chiếu Chờ

Phương pháp	Ý nghĩa
“orig”	Máy khách muốn nhận được khung ban đầu, nếu có. Nếu bị lỗi, máy khách muốn nhận được khung tương đương dòng, nếu có.
“equiv”	Máy khách muốn nhận được khung tương đương dòng, nếu có. Nếu bị lỗi, máy khách muốn nhận được khung ban đầu, nếu có.
“incr”	Máy khách muốn nhận ngăn dữ liệu dòng mã tăng dần, nếu có. Nếu bị lỗi, máy khách muốn nhận được khung tương đương dòng, nếu có. Điều này tương tự như khuyến nghị mặc định được đề nghị.

Điều này không hợp lệ nếu cung cấp nhiều hơn một giá trị đối với tham chiếu Chờ

C.10.2.7 Trình tự dòng mã

Tham chiếu này có thể được sử dụng để chỉ ra cách máy khách muốn máy chủ cung cấp nhiều dòng mã được yêu cầu trong một yêu cầu duy nhất. Giá trị hợp lệ của các tham chiếu trình tự dòng mã được quy định trong Bảng C.11.

Bảng C.11 – Tham chiếu trình tự dòng mã

Phương pháp	Ý nghĩa
“sequential”	Máy khách muốn nhận được nhiều dòng mã trong một khung hình tuần tự (ví dụ, phục vụ cho nhiều khung hình trong tập tin Motion JPEG 2000 theo tuần tự).
“reverse-sequential”	Máy khách muốn nhận được nhiều dòng mã trong một khung tuần tự (ví dụ, nhiều khung hình trong tập tin Motion JPEG 2000), theo thứ tự ngược lại.
“interleaved”	Máy khách muốn nhận được nhiều dòng mã một cách xen kẽ (ví dụ, máy chủ xen kẽ nhiều lớp hợp thành vào tập tin JPX).

Điều này không hợp lệ nếu cung cấp nhiều hơn một giá trị đối với tham chiếu trình tự dòng mã.

C.10.2.8 Tham chiếu rút gọn

Tham chiếu này có thể được sử dụng để chỉ cách máy chủ sẽ ràng buộc đáp ứng của nó với yêu cầu tạo ra bởi máy khách, và cách để máy chủ chứa dữ liệu dư thừa (tức là, dữ liệu thuộc các đáp ứng không cần thiết đối với yêu cầu). Giá trị conciseness-preference cho phép được quy định trong Bảng C.12. Máy chủ có thể bỏ qua bổ ngữ “/r“ bất kỳ áp dụng cho tham chiếu này, và không được sử dụng nó do ý nghĩa của nó là không xác định.

Bảng C.12 – Tham chiếu rút gọn

“concise”	Máy chủ sẽ tạo ra đáp ứng ngắn nhất mà nó có khả năng đáp ứng các yêu cầu.
“loose”	Máy chủ có thể bao gồm dữ liệu mà nó cho là phù hợp với yêu cầu vượt ra ngoài dữ liệu cần thiết để đáp ứng các yêu cầu.

CHÚ THÍCH: Trong phạm vi mà cửa sổ hiển thị yêu cầu được sửa đổi phù hợp với tiêu đề đáp ứng (xem D.2), các định nghĩa trên đây được hiểu như cửa sổ hiển thị sửa đổi.

VÍ DỤ: Xét một máy khách thực hiện một loạt các yêu cầu mà cửa sổ hiển thị xuất hiện có quy tắc. Nếu conciseness-pref không được thiết lập là “concise”, thì máy chủ có thể bao gồm dữ liệu dự đoán có lợi trong tương lai cho máy khách. Một máy khách có thể sử dụng các thiết lập conciseness-pref là “concise” để ngăn cản các máy chủ sau một kế hoạch như vậy.

C.10.3 Độ nhạy tương phản (csf)

Trường này có thể được sử dụng để cung cấp thông tin liên quan đến độ nhạy tương phản. Trong khi những thông tin này có thể biểu diễn ảnh hưởng của cả độ nhạy thị giác và chức năng chuyển đổi điều chế trên thiết bị hiển thị, người ta dễ dàng mô tả khi xét về mặt chức năng chuyển đổi điều chế được giả định. Khi tái tạo ở kích thước khung hình xác định bởi trường yêu cầu Kích thước Khung hình, dữ liệu ảnh được giả định được truyền qua một thiết bị có chức năng biến đổi điều chế (MTF) là m (ω1, ω2), sau đó nó được xem bởi chủ thể là hệ thống thị giác của con người (HVS) có độ nhạy tương phản đồng nhất. MTF m (ω1, ω2) được mô tả thông qua tập các mẫu. Các mẫu tính bằng logarit theo radian, cùng một hoặc nhiều trục định hướng. Các máy chủ có thể suy ra các mẫu này sử dụng bất kỳ phương pháp nào nó thấy phù hợp, để khôi phục MTF, do đó có thể được sử dụng để điều chỉnh thứ tự trong dãy byte của ngăn dữ liệu được truyền thông đến máy khách thông qua các bản tin dòng JPP hoặc dòng JPT.

Mỗi csf-sample-line biểu diễn các mẫu MTF m (ω1, ω2) với ω1 = πdncosψ, ω2 = πdnsinψ, trong đó n là chỉ số mẫu; bắt đầu từ n = 0 cho mẫu csf–density đầu tiên trong csf-sample-line; ψ là hướng của dòng mẫu CSF, tính theo độ (mặc định là 0 nếu không có giá trị csf-angle), và d là mật độ lấy mẫu; không lớn hơn 1,0. Giá trị ω1 mô tả các tần số ngang tính theo radian, trong đó ω1 = π là tần số Nyquist theo phương ngang. Giá trị ω2 mô tả các tần số dọc tính theo radian, trong ω2 = π là tần số Nyquist theo phương dọc.

Các giá trị mẫu MTF chỉ liên quan với nhau; không có giải thích cụ thể cho các giá trị tuyệt đối của chúng.

C.10.4 Xử lý

handled = “handled”

Nếu trường yêu cầu này xuất hiện, máy chủ sẽ bao gồm tiêu đề đáp ứng JPIP-handled trong đáp ứng của nó, xác định các trường yêu cầu mà máy chủ chuẩn bị xử lý.

CHÚ THÍCH: Tiêu đề đáp ứng JPIP-handled được định nghĩa trong Điều D.2.26.

Phụ lục D

(Quy định)

Dấu hiệu đáp ứng của máy chủ

D.1 Cú pháp trả lời

D.1.1 Tổng quan

Phụ lục này mô tả tất cả các yếu tố có thể có trong một đáp ứng JPIP. Mỗi điều khoản nhỏ chủ yếu mô tả các mã trạng thái và mệnh đề lý do có liên quan, các tiêu đề đáp ứng và các giá trị có thể đối với tiêu đề này, các dữ liệu đáp ứng. Nói chung, đáp ứng sẽ bao gồm nhiều tiêu đề đáp ứng.

D.1.2 Cấu trúc Trả lời

Đáp ứng JPIP bao gồm các yếu tố sau:

– Mã trạng thái;

– Mệnh đề lý do;

– Tiêu đề đáp ứng JPIP;

– Dữ liệu đáp ứng.

Các yếu tố trong đáp ứng cần thực hiện theo các giao thức truyền tải được lựa chọn. Ví dụ, trong HTTP, mã trạng thái và mệnh đề lý do xuất hiện trong dòng trạng thái, các tiêu đề đáp ứng JPIP xuất hiện trong các tiêu đề đáp ứng HTTP và dữ liệu đáp ứng (nếu có) sẽ xuất hiện trong phần thân của thực thể HTTP.

Chuỗi mệnh đề lý do giải thích cho mã trạng thái. Các mã trạng thái sau đây đủ cho các ứng dụng JPIP.

D.1.3 Mã trạng thái và các cụm từ lý do

D.1.3.1 Tổng quát

Status-Code là mã kết quả nguyên có 3 chữ số để hiểu và đáp ứng các yêu cầu. Một tập con các mã trạng thái và mệnh đề lý do từ giao thức HTTP/1.1 được sử dụng. Các máy khách JPIP nên mong đợi các mã sau đây. Máy khách JPIP hoạt động trên giao thức HTTP có thể thấy các mã trạng thái khác.

D.1.3.2 200 (OK)

Các máy chủ nên sử dụng mã trạng thái này nếu chấp nhận xử lý yêu cầu Cửa sổ hiển thị, có thể có một vài thay đổi trong Cửa sổ hiển thị yêu cầu, được chỉ ra bởi tiêu đề bổ sung nằm trong trả lời.

D.1.3.3 202 (Đã chấp nhận)

Máy chủ nên phát hành mã trạng thái này nếu yêu cầu Cửa sổ hiện thị là chấp nhận được, nhưng yêu cầu Cửa sổ hiện thị tiếp theo nằm trong hàng đợi (do wait=no). Khi yêu cầu đầu tiên trở nên không thích hợp trước khi máy chủ có thể xử lý và bắt đầu truyền tải một đáp ứng, thì mã trạng thái 202 được sử dụng. Đây là sự xuất hiện phổ biến trong thực tế, do một người dùng tương tác có thể thay đổi vùng quan tâm của họ nhiều lần trước khi máy chủ kết thúc đáp ứng yêu cầu trước đó, hoặc trước khi máy chủ chuẩn bị để làm gián đoạn xử lý liên tục.

D.1.3.4 400 (Yêu cầu bị lỗi)

Máy chủ nên phát hành mã trạng thái này nếu yêu cầu có định dạng không chính xác, hoặc có chứa một trường không được công nhận trong chuỗi truy vấn.

D.1.3.5 404 (Không tìm thấy)

Mã trạng thái này cần được phát hành nếu máy chủ không thể xác định vị trí địa chỉ logic của yêu cầu liên quan, thông qua các “ trường yêu cầu “target”, trường yêu cầu “target-id” hoặc bất kỳ phương tiện khác như thành phần <resource> của một yêu cầu HTTP GET hoặc POST.

CHÚ THÍCH: Mã trạng thái này cũng cần được phát hành nếu trường yêu cầu “subtarget” đề cập đến một dãy byte không tồn tại hoặc không phù hợp trong tài nguyên yêu cầu.

D.1.3.6 415 (Loại phương tiện không được hỗ trợ)

Mã trạng thái này có thể được sử dụng nếu các loại ảnh duy nhất được xác định trong trường yêu cầu Kiểu Trả về Ảnh không thể được phục vụ.

D.1.3.7 501 (Không được triển khai)

Mã trạng thái này có thể được sử dụng nếu một phần của tiêu chuẩn này được yêu cầu bởi các yêu cầu không thể được phục vụ.

D.1.3.8 503 (Dịch vụ không khả dụng)

Mã trạng thái này nên được sử dụng nếu một ID Kênh chỉ ra trong trường yêu cầu ID Kênh không hợp lệ.

D.1.4 Ảnh hưởng của lỗi đến trạng thái máy chủ

Trong một sự kiện máy chủ phát hành mã lỗi khác nhau 200 và 202, nó sẽ không thay đổi trạng thái của nó bằng cách xử lý trường yêu cầu chứa trong yêu cầu tương ứng và không trả về dữ liệu đáp ứng. Tuy nhiên, máy chủ có trách nhiệm cập nhật các qid. Trong trường hợp các mã lỗi được tạo ra bởi client-preferences-request sử dụng bổ ngữ “/r” không được hỗ trợ bởi máy chủ, và máy chủ đang hoạt động trong một phiên, nó sẽ mong muốn rằng các máy chủ giữ phiên có sẵn cho các yêu cầu trong tương lai.

CHÚ THÍCH: Nếu máy chủ đang hoạt động trong một phiên, tùy chọn thay thế cho các máy chủ đầu tiên sẽ trả về một mã lỗi thì kết thúc phiên, ví dụ, trả về 503 cho tất cả các yêu cầu trong phiên này.

VÍ DỤ: Xét một máy khách phát hành yêu cầu không hợp lệ:

sau đó máy chủ báo cáo yêu cầu không hợp lệ này sẽ không xử lý yêu cầu đối với cửa sổ hiển thị, sẽ không thay đổi mô hình bộ nhớ đệm và sẽ không tạo ra một kênh mới. Nó sẽ hủy bỏ yêu cầu và trả về một mã lỗi.

VÍ DỤ: Xét một máy khách phát hành yêu cầu hợp lệ:

và máy chủ không thể thực hiện tham chiếu Cửa sổ hiển thị “fullwindow” cho kích thước cửa sổ yêu cầu, sau đó máy chủ sẽ không xử lý yêu cầu, sẽ không trả về bất kỳ dữ liệu cho các yêu cầu, và phát hành mã lỗi 501 bao gồm tiêu đề đáp ứng JPIP “JPIP-pref: fullwindow/r” mà không thay đổi trạng thái nội bộ của mình. Mặc dù, nó sẽ giữ phiên có sẵn cho các yêu cầu trong tương lai nếu có thể.

D.2 Các tiêu đề đáp ứng JPIP

D.2.1 Giới thiệu về tiêu đề đáp ứng JPIP

Trong việc đáp ứng yêu cầu máy khách, máy chủ có thể sửa đổi một số khía cạnh của yêu cầu. Nếu máy chủ thay đổi các yêu cầu, các tham số sửa đổi sẽ được xác định thông qua tiêu đề đáp ứng. Tên của mỗi tiêu đề đáp ứng xuất phát từ tên của trường yêu cầu có các tham số được sửa đổi, với tiền tố tên của trường yêu cầu với “JPIP-“. Trừ khi có quy định khác, nếu các tham số được xác định trong các đáp ứng tiêu đề ban đầu đã được quy định trong yêu cầu của máy khách, thì máy chủ sẽ trả lời cũng theo cách đó, ngoại trừ các đáp ứng không chứa các tiêu đề đáp ứng. Ngoài ra, tiêu đề đáp ứng JPIP có thể được gửi bởi các máy chủ để thông báo cho máy khách về các giá trị của trường yêu cầu không xác định để sử dụng trong các yêu cầu trong tương lai.

Đáp ứng JPIP-qid là một ngoại lệ trong đó nó được gửi bất cứ khi nào máy khách bao gồm một Yêu cầu ID trong yêu cầu, và sau đó giá trị của JPIP-qid phải luôn luôn giống như qid.

Tham số cho các tiêu đề đáp ứng bắt nguồn bởi các yếu tố BNF giống như tham số trong trường yêu cầu ban đầu, có cùng ý nghĩa và định dạng như các tham số cho các trường yêu cầu ban đầu.

Ngoại lệ duy nhất cho quy tắc này được tìm thấy trong kết nối với đáp ứng Kênh Mới và Chất lượng.

D.2.2 ID Địa chỉ (JPIP-tid)

Các máy chủ sẽ gửi đáp ứng tiêu đề này nếu định danh địa chỉ duy nhất của máy chủ khác với bất kỳ định danh nào được cung cấp trong trường yêu cầu ID Địa chỉ. Target-id là một chuỗi tùy ý được gán cho máy chủ, không quá 255 ký tự. Nếu trường yêu cầu ID Địa chỉ xác định một giá trị “0”, máy chủ có nghĩa vụ chứa đáp ứng tiêu đề ID Địa chỉ, chỉ ra target-id thực tế. Nếu máy chủ không thể gán định danh duy nhất cho địa chỉ logic yêu cầu, và do đó không thể đảm bảo tính toàn vẹn của nó giữa nhiều yêu cầu hoặc phiên, thì đáp ứng ID Địa chỉ quy định cụ thể giá trị bằng 0. Nếu máy chủ cung cấp một target-id khác với quy định trong yêu cầu, nó sẽ bỏ qua tất cả trường yêu cầu model, tpmodel, need và tpneed khi đáp ứng yêu cầu này.

D.2.3 Kênh Mới (JPIP-cnew)

Các máy chủ sẽ gửi đáp ứng tiêu đề này khi và chỉ khi, nó gán một kênh mới để đáp ứng cho trường yêu cầu Kênh Mới. Chuỗi giá trị bao gồm một danh sách dấu phẩy tách của cặp name=value, giá trị đầu tiên chỉ thẻ kênh-id của kênh mới.

Các thẻ transport-param sau đây được xác định theo tiêu chuẩn này (xem Bảng D.1).

Bảng D.1 – Giá trị hợp lệ của transport-param

Giá trị	Ý nghĩa
“transport”	Tham số này được gán cho một giá trị trong danh sách tên giao thức truyền tải chấp nhận được cung cấp trong trường yêu cầu Kênh Mới. Nấu nhiều tên giao thức truyền tải được cung cấp trong trường yêu cầu, thì đáp ứng tiêu đề phải xác định truyền tải thực tế sẽ được sử dụng các kênh.
“host”	Tham số này xác định tên hoặc địa chỉ IP của máy chủ đối với máy chủ JPIP quản lý kênh mới. Các tham số không cần trả về trừ khi máy chủ khác với yêu cầu đã thực sự được gửi.
“path”	Tham số này xác định các thành phần đường dẫn URL được sử dụng trong việc xây dựng các yêu cầu tương lai trên kênh này. Các tham số không cần trả về, trừ khi tên đường dẫn khác được sử dụng trong các yêu cầu thực sự được gửi.
“port”	Tham số này xác định số cổng (thập phân) mà tại đó các máy chủ JPIP quản lý kênh mới lắng nghe các yêu cầu. Các tham số không cần trả về nếu các máy chủ và số cổng giống với yêu cầu ban đầu được gửi. Các tham số cũng không cần trả về nếu các máy chủ khác với yêu cầu được gửi và sử dụng số cổng mặc định gán với giao thức truyền tải có liên quan.
“auxport”	Tham số này được sử dụng với giao thức truyền tải đòi hỏi một kênh vật lý thứ hai. Nếu truyền tải “http-tcp” hoặc “http-udp” được sử dụng, cổng bổ trợ được sử dụng để kết nối các kênh bổ trợ. Để biết thêm chi tiết, xem Phụ lục G và J. Các tham số không cần trả về nếu yêu cầu ban đầu liên quan đến một kênh đó cũng đã sử dụng một kênh bổ trợ, có số lượng cổng bổ trợ tương tự. Nếu không, các tham số cần được trả về nếu số cổng bổ trợ khác với giá trị mặc định gán giao thức truyền tải được lựa chọn.

D.2.4 ID Yêu cầu (JPIP-qid)

Các máy chủ sẽ gửi đáp ứng tiêu đề này nếu yêu cầu của máy khách bao gồm một ID Yêu cầu qid. Giá trị của JPIP-qid sẽ giống với qid. Các máy chủ không bao gồm tiêu đề đáp ứng ID Yêu cầu khi yêu cầu của máy khách tương ứng không bao gồm ID Yêu cầu.

CHÚ THÍCH: ID Yêu cầu, JPIP-qid của máy chủ, sẽ luôn đồng nhất với ID Yêu cầu của máy khách. Do đó, ID yêu cầu đặc biệt ở chỗ tiêu đề đáp ứng này được gửi khi máy khách đã sử dụng ID Yêu cầu, không phải khi máy chủ thay đổi giá trị.

D.2.5 Kích thước Khung hình (JPIP-fsiz)

Các máy chủ nên gửi tiêu đề đáp ứng này nếu kích thước khung hình mà đáp ứng dữ liệu phục vụ khác với yêu cầu thông qua các trường yêu cầu Kích thước Khung hình.

D.2.6 Kíh thước Vùng (JPIP-rsiz)

Các máy chủ sẽ gửi tiêu đề đáp ứng này nếu kích thước của vùng mà đáp ứng dữ liệu phục vụ khác với yêu cầu.

CHÚ THÍCH: Máy chủ chỉ được sửa đổi Cửa sổ hiển thị theo Bảng C.8, các mô tả về view-window-prefs, trong Điều C.10.2.2. Cụ thể, một máy chủ không được phép phóng to cửa sổ hiển thị yêu cầu. Tuy nhiên, nó có thể truyền dữ liệu bên ngoài cửa sổ hiển thị yêu cầu phù hợp với Bảng C.12, concisenes-pref, trong Điều C.10.2.8.

D.2.7 Độ lệch (JPIP-roff)

Các máy chủ nên gửi tiêu đề đáp ứng này nếu độ lệch của khu vực đối với đáp ứng dữ liệu phục vụ khác với yêu cầu đó.

D.2.8 Kích thước khung hình đối với dữ liệu chiều thay đổi (JPIP-fvsiz)

Các máy chủ sẽ gửi tiêu đề đáp ứng này nếu kích thước khung hình thực tế khác với các yêu cầu thông qua trường Kích thước Khung hình hoặc Kích thước Khung hình đối với dữ liệu chiều thay đổi. Máy chủ cần phải thay đổi kích thước khung hình bởi máy khách yêu cầu kích thước khung hình không tồn tại. Đây là theo quyết định của máy chủ hoặc trả về tiêu đề đáp ứng JPIP-fsiz hoặc JPIP-fvsiz trên các yêu cầu dữ liệu hai chiều, cả hai đáp ứng đều được coi là tương đương trong trường hợp này. Trong mọi trường hợp khác, chỉ tiêu đề đáp ứng JPIP-fvsiz được sử dụng.

D.2.9 Kích cỡ vùng đối với dữ liệu chiều thay đổi (JPIP-rvsiz)

Các máy chủ sẽ gửi tiêu đề đáp ứng này nếu kích thước của Cửa sổ hiển thị khác với yêu cầu thông qua trường Kích thước Vùng hoặc Kích thước Vùng đối với dữ liệu chiều thay đổi. Nếu dữ liệu hai chiều đã được yêu cầu, thì tùy theo quyết định của máy chủ để chọn một trong hai tiêu đề đáp ứng này, hoặc tiêu đề đáp ứng JPIP-rsiz, và cả hai đều được coi là tương đương với máy khách. Đối với tất cả các trường hợp khác, chỉ đáp ứng tiêu đề JPIP-rvsiz được sử dụng.

D.2.10 Độ lệch đối với dữ liệu chiều thay đổi (JPIP-rvoff)

Các máy chủ sẽ gửi tiêu đề đáp ứng này nếu độ lệch Cửa sổ hiển thị khác với yêu cầu thông qua trường Độ lệch hoặc Độ lệch đối với dữ liệu chiều thay đổi. Các máy chủ cần phải sửa đổi độ lệch nếu nó được thay đổi kích thước cửa sổ hiển thị yêu cầu. Đối với dữ liệu hai chiều, tùy theo quyết định của máy chủ để chọn một trong hai tiêu đề đáp ứng này, hoặc tiêu đề đáp ứng JPIP-rvoff, và máy khách sẽ xem xét cả hai tương đương nhau. Đối với tất cả các dữ liệu khác, tiêu đề đáp ứng JPIP-rvoff được sử dụng.

D.2.11 Thành phần ảnh (JPIP-comps)

Các máy chủ sẽ gửi tiêu đề này đáp ứng nếu thành phần ảnh mà nó sẽ phục vụ dữ liệu khác với yêu cầu thông qua trường yêu cầu Thành phần ảnh. Nó không có nghĩa vụ phải gửi tiêu đề đáp ứng này nếu thành phần hình ảnh được yêu cầu không tồn tại trong bất kỳ các dòng mã yêu cầu.

D.2.12 Dòng mã (JPIP-stream)

Các máy chủ sẽ gửi tiêu đề đáp ứng này để thông báo cho máy khách về các dòng mã hoặc các dòng mã mà nó sẽ phục vụ dữ liệu, trừ khi nó được phục vụ dữ liệu để đáp ứng tất cả yêu cầu các dòng mã trực tiếp thông qua trường yêu cầu Dòng mã bất kỳ và tất cả các dòng mã yêu cầu gián tiếp thông qua trường yêu cầu Ngữ cảnh Dòng mã bất kỳ. Các máy chủ nên sử dụng cú pháp prefixed-range để chỉ ra rằng các dòng mã mà dữ liệu đang được phục vụ đáp ứng tới một trường yêu cầu Ngữ cảnh Dòng mã đã được biên dịch. Trong trường hợp này, giá trị ctxt-id phải nhận biết được context-range cụ thể từ trường yêu cầu Ngữ cảnh Dòng mã đã được biên dịch ra các dòng mã có liên quan. Hơn nữa, giá trị ctxt-elt sẽ xác định các yếu tố context-range cụ thể trong context-range xác định bởi ctxt-id, được biên dịch ra các dòng mã có liên quan.

Giá trị 0 của ctxt-id có nghĩa là context-range đầu tiên trong trường yêu cầu Ngữ cảnh Dòng mã được tạo ra từ dãy các dòng mã với theo sau tiền tố. Tương tự như vậy, giá trị 1 của ctxt-id có nghĩa là context-range thứ hai trong yêu cầu Ngữ cảnh Dòng mã được tạo ra ngay sau dòng mã trước…

Giá trị 0 của ctxt-elt có nghĩa là ngữ cảnh đầu tiên trong context-range có liên quan là được tạo ra dãy các dòng mã theo sau tiền tố.

VÍ DỤ:

Máy khách yêu cầu:

Máy chủ đáp ứng:

Điều này có nghĩa là máy chủ được đáp ứng với các dữ liệu thu được từ:

1) Các ứng dụng trực tiếp của Cửa sổ hiển thị tại dòng mã 0 (theo yêu cầu thông qua “stream=0″);

2) Biên dịch của Cửa sổ hiển thị tại lớp hợp thành JPX 4, theo chỉ dẫn hợp thành 0 trong tập chỉ dẫn thành 0, vì nó áp dụng cho dòng mã 1;

3) Biên dịch của Cửa sổ hiển thị tại lớp hợp thành JPX 9, theo chỉ dẫn hợp thành 3 trong tập chỉ dẫn hợp thành 1, vì nó áp dụng cho dòng mã 0; và

4) Biên dịch của Cửa sổ hiển thị tại lớp hợp thành JPX 10, theo chỉ dẫn hợp thành 3 trong tập chỉ dẫn hợp thành 1, vì nó áp dụng cho dòng mã 0

D.2.13 Ngữ cảnh Dòng mã (JPIP-context)

Các máy chủ nên gửi tiêu đề đáp ứng này nếu nó có thể xử lý bất kỳ giá trị context-range cung cấp thông qua trường yêu cầu Ngữ cảnh Dòng mã. Các tiêu đề mô tả context-range được xử lý, cùng với các chỉ số của tất cả các dòng mã được liên kết với context-range. Các máy chủ có thể bỏ qua một vài giá trị context-range mà ban đầu được cung cấp trong trường yêu cầu Ngữ cảnh Dòng mã, nếu không được xử lý. Các máy chủ cũng có thể thay đổi giá trị context-range ban đầu được cung cấp trong trường yêu cầu Ngữ cảnh Dòng mã. Có hai loại thay đổi được:

a) các máy chủ có thể hạn chế tập các yếu tố hình ảnh (ví dụ, lớp hợp thành) được yêu cầu ban đầu;

b) các máy chủ có thể giảm thay đổi các biến đổi hình học mà nó có khả năng hỗ trợ (ví dụ, thay đổi “track” hay “movie” trong chuỗi mj2t-context).

D.2.14 ROI (JPIP-roi)

Để đáp ứng yêu cầu máy khách cho ROI, máy chủ quy định thông qua các tiêu đề đáp ứng ROI của phần mở rộng ROI thực tế được phục vụ. Nếu máy chủ không thể thực hiện đầy đủ yêu cầu ROI, thì nó phải trả lời với tiêu đề đáp ứng ROI dạng đơn giản: “JPIP-roi:roi=no-roi“. Ngoài ROI, máy chủ cũng quy định thông qua tiêu đề đáp ứng Kích thước Khung hình, Kích thước Vùng và Độ lệch vùng ảnh mà nó phục vụ như là một dự phòng.

Nếu máy chủ có thể phục vụ ROI, nhưng đối với một số lý do cần phải thay đổi kích thước các phần ảnh trả về, nó sẽ gửi các tiêu đề đáp ứng ROI mô tả ROI và tiêu đề đáp ứng Kích thước Khung hình, Kích thước Vùng và Độ lệch mô tả một phần của ROI được trả về.

D.2.15 Lớp (JPIP-layers)

Các máy chủ sẽ gửi tiêu đề đáp ứng này nếu số lượng các lớp mà nó sẽ phục vụ nhỏ hơn giá trị quy định bởi trường yêu cầu Lớp. Do cửa sổ hiển thị điển hình được phục vụ theo kiểu lũy tiên chất lượng, máy chủ không có nghĩa vụ (và thực sự không thể) xác định số lượng các lớp được mở rộng ra bởi các đáp ứng dữ liệu mà nó cung cấp. Tuy nhiên, nếu số lượng yêu cầu của lớp vượt quá số lượng các lớp có sẵn từ dòng mã bất kỳ trong Cửa sổ hiển thị, máy chủ tối thiểu cũng phải xác định số lượng tối đa các lớp có sẵn. Máy chủ bất kỳ chấp nhận một trường yêu cầu Căn chỉnh (xem C.7.1) sẽ cung cấp một đáp ứng lớp JPIP nếu số lượng lớp mà nó sẽ phục vụ nhỏ hơn giá trị quy định bởi trường yêu cầu lớp.

D.2.16 Tốc độ Lấy mẫu (JPIP-srate)

Các máy chủ sẽ gửi tiêu đề đáp ứng này nếu tốc độ lấy mẫu trung bình của dòng mã gửi cho máy khách dự kiến sẽ khác với yêu cầu thông qua trường yêu cầu Tốc độ Lấy mẫu và tốc độ lấy mẫu được biết. Nếu các dòng mã gốc không chứa thông tin định thời, thì tiêu đề đáp ứng này không được gửi đi.

D.2.17 Yêu cầu Dữ liệu đặc tả (JPIP-metareq)

Các máy chủ sẽ gửi tiêu đề đáp ứng này nếu nó thay đổi các giá trị max-depth, limit, metareq- qualifier hoặc priority được cung cấp trong trường yêu cầu dữ liệu đặc tả yêu cầu.

D.2.18 Độ dài đáp ứng tối đa (JPIP-len)

Các máy chủ sẽ gửi tiêu đề đáp ứng này nếu quy định giới hạn byte trong trường yêu cầu Độ dài đáp ứng tối đa quá nhỏ để cho phép đáp ứng không rỗng trừ khi giới hạn byte bằng không. Nếu trả về, JPIP-len sẽ là một giá trị thông báo cho máy khách có độ dài đáp ứng tối đa thích hợp, len, đối với các yêu cầu tiếp theo. Nếu len = 0, máy chủ cần đáp ứng các yêu cầu với tiêu đề đáp ứng và không có dữ liệu đáp ứng.

D.2.19 Chất lượng (JPIP-quality)

Các máy chủ có thể gửi tiêu đề đáp ứng này để thông báo cho máy khách về giá trị chất lượng được gán với dữ liệu ảnh trả về một khi yêu cầu này được hoàn thành. Nếu yêu cầu bị gián đoạn bởi một yêu cầu khác (không phải “wait=yes“)), giá trị chất lượng này có thể không chính xác. Giá trị chất lượng chỉ đề cập đến yêu cầu Cửa sổ hiển thị, và có cách giải thích tương tự như các trường yêu cầu chất lượng. Nếu máy chủ bỏ qua yêu cầu của máy khách thì một giá trị “-1” sẽ được trả về.

D.2.20 Kiểu trả về ảnh (JPIP-type)

Các máy chủ nên chứa tiêu đề đáp ứng này, trừ khi có một cơ chế khác xác định các kiểu phụ MIME của dữ liệu ảnh trả về. Ví dụ về các cơ chế khác bao gồm:

– Tiêu đề HTTP “Content-Type:”,

– Đáp ứng các yêu cầu có liên quan đến phiên mà đã báo hiệu kiểu trả về ảnh.

D.2.21 Tập mô hình (JPIP-mset)

Các máy chủ nên chứa tiêu đề đáp ứng này nếu yêu cầu của máy khách bao gồm trường yêu cầu Tập Mô hình, và tập các dòng mã được xác định bởi trường yêu cầu Tập Mô hình của máy khách khác với tập của các dòng mã mà máy chủ thực sự sẵn sàng để duy trì thông tin mô hình bộ nhớ đệm. Tập các dòng mã mà máy chủ duy trì thông tin mô hình bộ nhớ đệm bao gồm tất cả các dòng mã được kết hợp với dữ liệu đáp ứng của máy chủ (hoặc những thứ được xác định trong yêu cầu của máy khách, hoặc những thứ xác định bởi tiêu đề đáp ứng dòng mã của máy chủ, nếu có). Ngoài những dòng mã, “mset” của máy chủ có thể không lớn hơn tập dòng mã được xác định bởi trường yêu cầu Tập Mô hình của máy khách.

D.2.22 Năng lực cần thiết (JPIP-cap)

Tiêu đề đáp ứng này quy định rằng các máy khách sẽ hỗ trợ một tính năng đặc biệt để giải thích địa chỉ logic một cách phù hợp. Năng lực hợp lệ cũng tương tự như đối tượng quy định cho trường yêu cầu Năng lực tại Bảng C.6.

D.2.23 Tham chiếu không có sẵn (JPIP-pref)

Tiêu đề đáp ứng này được cung cấp khi và chỉ khi trường yêu cầu Tham chiếu Máy khách chứa trong related-pref-set với bổ ngữ “/r” (cần thiết), mà máy chủ sẵn sàng để hỗ trợ. Trong trường hợp này, một giá trị lỗi cũng nên được trả về đối với mã trạng thái đáp ứng. Chuỗi giá trị bao gồm một hoặc nhiều related-pref-sets mà có thể không được hỗ trợ, lặp lại các dạng giống nhau như cách chúng xuất hiện trong yêu cầu Tham chiếu Máy khách, ngoại trừ các tham số tính toán chỉ cần được biểu diễn đủ chính xác để tránh sự nhập nhằng trong việc xác định các tham chiếu không được hỗ trợ.

Mặc dù mong muốn, nhưng nó không cần thiết để tiêu đề đáp ứng này liệt kê tất cả các yêu cầu related-pref-sets không được hỗ trợ. Vì vậy, nó cho phép cho một máy chủ để đi vào trường yêu cầu Tham chiếu Máy khách chỉ đến khi nó gặp related-pref-sets quy định “/r” và không hỗ trợ. Xem C.10.2.1 để biết thêm thông tin về khi tiêu đề đáp ứng này là được sử dụng.

Bảng D.2 – Định nghĩa các mã lý do

Mã lý do	Lý do	Giải thích
1	Image done	Máy chủ đã chuyển toàn bộ thông tin hình ảnh có sẵn (không chỉ là thông tin liên quan đến cửa sổ hiển thị yêu cầu) cho máy khách. Mã lý do này có ý nghĩa đặc biệt đối với các yêu cầu truyền thông theo phiên. Đối với một yêu cầu truyền thông theo phiên, mã lý do này có nghĩa là máy khách đã nhận được tất cả dữ liệu có thể được gửi để đáp ứng bất kỳ yêu cầu truyền thông theo phiên gán với địa chỉ logic này. Với ngoại lệ có thể có các yêu cầu trong đó bao gồm trường yêu cầu quản lý bộ nhớ đệm, bất kỳ yêu cầu truyền thông theo phiên tiếp theo sẽ được đáp lại không có đáp ứng dữ liệu và nhãn EOR R = 1.
2	Window done	Máy chủ đã chuyển toàn bộ thông tin có liên quan đến yêu cầu cửa sổ hiển thị. Mã lý do này có một ý nghĩa đặc biệt đối với các yêu cầu truyền thông theo phiên. Đối với một yêu cầu truyền thông theo phiên, mã lý do này có nghĩa là máy khách đã nhận được tất cả dữ liệu có thể được gửi để đáp ứng với yêu cầu này và dữ liệu đáp ứng không chỉ giới hạn bởi data-limit-field bất kỳ (len hay quality) trong yêu cầu, hoặc bằng cách xử lý các yêu cầu tiếp theo. Với ngoại lệ có thể có các yêu cầu trong đó bao gồm trường yêu cầu quản lý bộ nhớ đệm, bất kỳ sự lặp lại tiếp theo của các yêu cầu sẽ được đáp lại không có dữ liệu đáp ứng và nhãn EOR R = 2.
3	Window change	Máy chủ đang kết thúc đáp ứng của nó để phục vụ một yêu cầu mới không xác định Wait=yes.
4	Byte limit reached	Máy chủ đang kết thúc đáp ứng của nó bởi giới hạn byte quy định trong một trường yêu cầu Độ dài Đáp ứng Tối đa đã đạt ngưỡng.
5	Quality limit reached	Máy chủ đang kết thúc đáp ứng của nó do giới hạn chất lượng quy định trong một trường yêu cầu Chất lượng đã đạt ngưỡng.
6	Session limit reached	Máy chủ đang kết thúc đáp ứng của nó bởi một số giới hạn về nguồn tài nguyên phiên, ví dụ, giới hạn thời gian, đã đạt ngưỡng. Không có yêu cầu được phát hành sử dụng một ID Kênh kết hợp với phiên đó.
7	Response limit reached	Máy chủ đang kết thúc đáp ứng của nó bởi một số giới hạn, ví dụ như, giới hạn thời gian, đã đạt ngưỡng. Nếu yêu cầu được đưa ra trong một phiên, yêu cầu vẫn có thể được phát hành bằng cách sử dụng ID Kênh liên quan đến phiên đó.
0xFF	Non-specified reason	Máy chủ đang kết thúc đáp ứng của nó vì một lý do không được quy định.
Giá trị khác		Dành riêng cho ISO sử dụng

D.2.24 Căn chỉnh (JPIP-align)

Tiêu đề đáp ứng này nên được cung cấp nếu đảm bảo sự liên kết máy chủ khác với yêu cầu của máy khách. (Xem C.7.1.)

D.2.25 Địa chỉ phụ (JPIP-subtarget)

Tiêu đề đáp ứng này nên được cung cấp nếu địa chỉ phụ được xác định bởi các máy chủ khác với yêu cầu của máy khách. (Xem C.2.3.)

D.2.26 Yêu cầu xử lý (handled)

Các máy chủ bao gồm tiêu đề đáp ứng này trong đáp ứng của nó với một yêu cầu có chứa các trường yêu cầu xử lý. Tiêu đề đáp ứng xử lý JPIP này xác định các yêu cầu mà máy chủ có thể xử lý một cách chính xác, phù hợp với tiêu chuẩn này. Mỗi trường yêu cầu có thể là bất kỳ một trường yêu cầu được đề cập trong Điều C.1.2, nhưng cũng có thể bao gồm các thẻ mà một số máy khách có thể không nhận ra; máy khách sẽ bỏ qua bất kỳ trường yêu cầu mà chúng không hiểu.

Một partially-handled-req có thể được sử dụng để hỗ trợ một phần cho trường yêu cầu. Nếu trường yêu cầu có liên quan có một tập hữu hạn các chuỗi tham số hoàn chỉnh theo sau ký tự “=” (ví dụ, “yes” hoặc “no”), các handled-req-option có thể là một trong những giá trị đó. Bảng D.3 mô tả các giá trị bổ sung cho các handled-req-option được xác định bởi tiêu chuẩn này để sử dụng với các trường theo yêu cầu cụ thể. Các máy chủ có thể bao gồm các thẻ cho handled-req-option mà một số máy khách có thể không nhận ra. Máy khách phải bỏ qua partially-handled-req bất kỳ có trường yêu cầu hoặc handled-req-option mà chúng không hiểu.

Bảng D.3 – Các giá trị handled-req-option bổ sung cho trường yêu cầu đặc biệt

request-field	handled-req-option	Ý nghĩa
Cnew	transport-name	Máy chủ xử lý một cách chính xác các trường yêu cầu kênh mới (new-channel) có chứa các loại truyền tải xác định.
Context	“jplx”, “mj2t”, “jpmp”, “jpxf“	Máy chủ xử lý một cách chính xác trường yêu cầu Ngữ cảnh Dòng mã cho các giá trị context-range bắt đầu với thẻ handled-req-option.

D.3 Dữ liệu đáp ứng

Đối với bất kỳ loại nào khác kiểu trả về ảnh dòng JPP hoặc dòng JPT, bao gồm dòng mã thô, dữ liệu đáp ứng nên bao gồm các thực thể yêu cầu đầy đủ. Đối với kiểu trả về ảnh dòng JPP hoặc JPT, dữ liệu đáp ứng bao gồm một chuỗi các bản tin được quy định tại Phụ lục A, kết thúc bằng bản tin EOR (End Of Response) đơn. Bản tin EOR không được quy định tại Phụ lục A và không phải là một phần chính thức của kiểu phương tiện truyền thông dòng JPP hoặc dòng JPT.

Bản tin EOR bao gồm tiêu đề và phần thân. Tiêu đề bản tin EOR bao gồm định byte đơn, 0x00, theo sau là một mã lý do byte đơn, R, và tiếp theo là một số đếm VBAS byte đơn, chỉ ra số lượng các byte trong phần thân của bản tin EOR. Tiêu chuẩn này không quy định giải thích nội dung của phần thân bản tin EOR.

Phần thân và tiêu đề của bản tin EOR chỉ đơn thuần là bản tin không góp phần vào việc hạn chế số lượng byte gán cho trường yêu cầu Độ dài Đáp ứng Tối đa được định nghĩa trong C.6.1.

Chú thích: Bản tin EOR nghĩa là máy chủ đã cung cấp tất cả các nội dung thích hợp của ngăn dữ liệu có liên quan cho một yêu cầu máy khách. Đây không nhất thiết là toàn bộ nội dung của các ngăn dữ liệu này. Đáp ứng kết thúc khi đạt đến một ngưỡng giới hạn cụ thể. Nếu không xác định giới hạn, thì bản tin EOR có nghĩa là tất cả các nội dung của ngăn dữ liệu liên quan sẽ được phục vụ.

The EOR message, header and body, is the only message which does not contribute to the byte count restriction associated with the Maximum Response Length request field as defined in C.6.1.

Các mã lý do hiện tại được xác định (xem Bảng D.2).

Phụ lục E

(Quy định)

Tải ảnh lên máy chủ

E.1 Tổng quan

Dự đoán rằng các ảnh sẽ được đặt trên một máy chủ bằng nhiều cách khác nhau nằm ngoài phạm vi của tiêu chuẩn này. Mục đích của phụ lục này là mô tả một cơ chế cho phép các phần của một ảnh được tải lên máy chủ.

E.2 Yêu cầu tải lên

E.2.1 Cấu trúc yêu cầu

Một yêu cầu tải lên bao gồm một hoặc nhiều trường yêu cầu quy định tại Phụ lục C, và phần thân của yêu cầu.

E.2.2 Trường yêu cầu tải lên

Các trường yêu cầu khi tải lên phải chứa trường yêu cầu Tải lên. Các trường yêu cầu Địa chỉ, Địa chỉ phụ và ID Địa chỉ (xem C.2.2, C.2.3 và C.2.4) cũng có thể được sử dụng. Đối với việc tải lên kiểu phương tiện truyền thông ảnh hoàn chỉnh, các trường yêu cầu Kích thước Khung hình, Độ lệch và Kích thước Vùng (xem C.4.2, C.4.3, và C.4.4) được sử dụng để chỉ ra vị trí của phần tải lên trong toàn bộ ảnh. Đối với việc tải lên dòng JPT và dòng JPP, số lượng ngăn dữ liệu (số lượng khối ảnh và phân khu ảnh) cùng với các tiêu đề chính chỉ ra vị trí của dữ liệu được mã hóa và không cần thiết trường yêu cầu Cửa sổ hiển thị

E.2.3 Phần thân của yêu cầu Tải lên

E.2.3.1 Tổng quát

Phần thân của yêu cầu tải lên bao gồm một trong các loại ảnh được hỗ trợ: dòng JPP, dòng JPT, hoặc kiểu phương tiện truyền thông ảnh hoàn chỉnh. Phần thân chứa dữ liệu máy khách được yêu cầu để xử lý tại máy chủ. Tiêu chuẩn này không hỗ trợ tải lên dữ liệu ảnh thô.

E.2.3.2 Dòng JPT

Phần thân của yêu cầu chứa tất cả các ngăn dữ liệu máy khách muốn máy chủ thay thế (ngăn dữ liệu tiêu đề, ngăn dữ liệu đặc tả và ngăn dữ liệu khối ảnh). Nếu máy khách không tải lên ngăn dữ liệu tiêu đề chính, thì ngăn dữ liệu khối ảnh sẽ được mã hóa một cách tương thích với các tiêu đề chính hiện tại.

E.2.3.3 Dòng JPP

Phần thân của yêu cầu chứa tất cả ngăn dữ liệu máy khách muốn máy chủ thay thế (ngăn dữ liệu tiêu đề, ngăn dữ liệu tiêu đề khối ảnh, ngăn dữ liệu đặc tả và ngăn dữ liệu phân khu ảnh). Nếu máy khách không tải lên ngăn dữ liệu tiêu đề chính hoặc ngăn dữ liệu tiêu đề khối ảnh, thì phân khu sẽ được mã hóa một cách cách tương thích với các tiêu đề chính và tiêu đề khối ảnh hiện tại

E.2.3.4 Tải lên ảnh hoàn chỉnh

Phần thân của yêu cầu chứa kiểu phương tiện truyền thông ảnh hoàn chỉnh đại diện cho những mẫu máy khách muốn thay đổi.

Trong trường hợp tải lên ảnh hoàn chỉnh, yêu cầu có thể bao gồm các trường yêu cầu Kích cỡ Khung hình, Kích thước Vùng và Độ lệch. Trường yêu cầu Kích cỡ Khung hình sẽ là kích thước lưới tọa độ tham chiếu của ảnh. Trong trường hợp tải lên ảnh hoàn chỉnh, nén không cần thực hiện một cách tương thích với địa chỉ logic trên máy chủ. Nếu kích thước của ảnh tải lên vượt quá phạm vi trong trường yêu cầu Kích thước Vùng, máy chủ nên thay đổi hạn chế phạm vi theo quy định trong trường yêu cầu Kích thước Vùng

E.3 Đáp ứng máy chủ

E.3.1 Tổng quát

Các máy chủ đáp ứng yêu cầu tải lên với mã trạng thái và mệnh đề lý do từ Phụ lục D. Các mã và mệnh đề lý do trả về hữu ích đối với việc tải lên hình ảnh được thể hiện trong các Điều dưới đây.

E.3.2 201 (Đã tạo)

Các máy chủ nên sử dụng mã trạng thái này, nếu sau khi nhận được yêu cầu tải lên, một nguồn tài nguyên mới được xác định trên máy chủ. Các máy chủ có trách nhiệm hoàn thành việc tạo ra trước khi trả về yêu cầu này. Nếu xảy ra trễ, máy chủ sẽ trả về 202 (Đã chấp nhận) thay vì 201 (Đã tạo).

Các máy chủ bao gồm một tiêu đề đáp ứng với một trường ID Địa chỉ mới cho các nguồn tài nguyên được cập nhật.

Không cần trả về phần thân.

E.3.3 202 (Đã chấp nhận)

Các máy chủ nên sử dụng mã trạng thái này nếu việc tải lên tạo ra một nguồn tài nguyên mới nhưng máy chủ vẫn chưa sẵn sàng để phục vụ. Các máy chủ cũng có thể sử dụng mã trạng thái này cho một bản cập nhật của tài nguyên hiện hành.

E.3.4 400 (Yêu cầu bị lỗi)

Máy chủ phát hành mã trạng thái này nếu yêu cầu có định dạng không chính xác, hoặc nếu truy vấn chứa các trường yêu cầu không tương thích với quá trình tải lên hoặc có chứa một trường không được công nhận trong chuỗi truy vấn.

E.3 5 404 (Không tìm thấy)

Mã trạng thái này cần được phát hành nếu máy chủ không thể dung hòa các tài nguyên yêu cầu với một ID Địa chỉ được phát hành.

E.3.6 415 (Loại phương tiện không được hỗ trợ)

Mã trạng thái này có thể được phát hành để chỉ ra rằng hỗ trợ việc tải lên, nhưng chỉ tải lên các loại đặc biệt (ví dụ, ảnh hoàn chỉnh, dòng JPT, hoặc dòng JPP) đi kèm với yêu cầu không được hỗ trợ.

E.3.7 501 (Không được triển khai)

Trạng thái này có thể được sử dụng nếu máy chủ không hỗ trợ tải lên hoặc không hỗ trợ lựa chọn đặc biệt cho tải lên.

E.4 Gộp dữ liệu trên máy chủ

E.4.1 Cập nhật ảnh

Sau khi nhận được các dữ liệu tải lên, các máy chủ có thể tạo ra một phiên bản mới cho địa chỉ logic và cung cấp các phiên bản mới cho các máy khách truy cập vào URL mới hoặc URL cũ. Tuy nhiên, các máy chủ không được sử dụng các trường yêu cầu ID Địa chỉ cũ để cung cấp quyền truy cập vào bất kỳ dữ liệu bị gộp hoặc cập nhật.

Nếu máy khách chứa trường yêu cầu ID Địa chỉ trong yêu cầu tải lên và địa chỉ ID không phù hợp với địa chỉ ID hiện tại của máy chủ đối với các nguồn tài nguyên, máy chủ không nên cập nhật các hình ảnh. Việc không phù hợp này có thể cho thấy máy khách đã chỉnh sửa một phiên bản trước của hình ảnh được sửa đổi. Máy chủ có thể từ chối hoặc chấp nhận việc tải lên không chứa trường yêu cầu ID Địa chỉ. Đây là một cách để chặn nhiều sửa đổi đồng thời trên cùng một địa chỉ của các máy khách khác nhau. Các máy chủ cung cấp khả năng chỉnh sửa để khắc phục các vấn đề như khóa địa chỉ bằng một số phương tiện khác.

Máy khách JPIP có thể tải lên một phần của ảnh mới bằng cách xác định địa chỉ ID là 0, hoặc sử dụng một URL mới, hoặc địa mà máy chủ không có. Các máy chủ nên phát hành một địa chỉ ID cho việc tải lên. Một máy khách có thể tiếp tục tải lên một phần bổ sung của ảnh mới bằng cách sử dụng địa chỉ ID trả về từ máy chủ trong phiên tải lên trước đó.

E.4.2 Dòng JPT

Máy chủ chấp nhận dữ liệu ngăn dữ liệu khối ảnh đầu tiên phải loại bỏ tất cả các dữ liệu cũ cho các khối ảnh tải lên, và bao gồm các dữ liệu mới thêm vào dòng mã. Cập nhật không thể tạo ra kết quả bằng việc thay đổi về số lượng hoặc kích thước hoặc vị trí của khối ảnh: cấu trúc của ảnh không thể thay đổi khi tải lên. Đặc biệt, một máy chủ không nên chấp nhận tải lên ngăn dữ liệu khối ảnh của dòng mã chứa đoạn nhãn PPM trong tiêu đề chính, trừ khi máy khách cung cấp một tiêu đề chính mới khi tải lên. Bất kỳ đoạn nhãn PLM hoặc TLM sẽ bị xóa hoặc cập nhật. Ngăn dữ liệu tiêu đề chính dòng JPT sẽ tải lên các ảnh mới.

Cách hình thành các dòng mã phần khối ảnh từ ngăn dữ liệu khối ảnh không được xác định. Các máy khách không cần thiết phải cung cấp tất cả các phần khối ảnh, và cũng không cần phần khối ảnh cuối để hoàn thành. Các máy chủ có trách nhiệm cập nhật tiêu đề chính và các phần bất kỳ của định dạng tập tin bị ảnh hưởng (ví dụ như chiều dài của khung Dòng mã).

Khi gộp dữ liệu, số lượng hoặc kích thước của khối ảnh không bị thay đổi và dữ liệu không bị thay thế bởi quá trình tải lên có nghĩa tương tự như ban đầu lúc trước khi tải lên.

E.4.3 Dòng JPP

Máy chủ chấp nhận bản tin ngăn dữ liệu phân khu ảnh đầu tiên sẽ loại bỏ các ngăn dữ liệu phân khu ảnh cũ tương ứng đối với các phân khu ảnh được tải lên, và bao gồm các dữ liệu ngăn dữ liệu phân khu ảnh mới. Thay đổi không thể được thực hiện đối với tiêu đề mà kết quả của thay đổi về số lượng phân khu ảnh, hoặc ý nghĩa của định danh phân khu ảnh, hoặc vị trí hoặc kích thước của mỗi phân khu ảnh trong Độ phân giải thành phần khối ảnh. Các ngăn dữ liệu tiêu đề khối ảnh dòng JPP và ngăn dữ liệu tiêu đề chính sẽ tải lên các ảnh mới.

Các hình thành gói phân khu ảnh từ ngăn dữ liệu phân khu ảnh không được xác định. Các máy khách không cần cung cấp tất cả các gói của phân khu ảnh, hoặc thậm chí gói hoàn chỉnh được cung cấp cuối cùng.

Khi gộp dữ liệu, số lượng hoặc kích thước của phân khu ảnh không bị thay đổi và dữ liệu không bị thay thế bởi quá trình tải lên sẽ có nghĩa tương tự như ban đầu lúc trước khi tải lên.

E.4.4 Ngăn dữ liệu đặc tả dòng JPP và dòng JPT

Ngăn dữ liệu đặc tả có thể được tải lên, thay thế nội dung trong ngăn dữ liệu đặc tả đang tồn tại. Do máy chủ kiểm soát việc phân bổ dữ liệu đặc tả vào ngăn dữ liệu đặc tả, nên máy khách cũng thực hiện theo cấu trúc ngăn dữ liệu đặc tả của máy chủ. Máy khách sẽ không thay đổi các khung Chờ trong ngăn dữ liệu đặc tả, ngoại trừ việc hoàn toàn loại bỏ khung Chờ. Khi tải lên toàn bộ ngăn dữ liệu đặc tả, máy khách có thể thêm dữ liệu đặc tả mới bằng cách thêm vào phần cuối của ngăn dữ liệu đặc tả cũ, hoặc bằng cách chèn dữ liệu đặc tả mới giữa các khung trong ngăn dữ liệu đặc tả cũ. Máy chủ quản lý khung Chờ và cấu trúc ngăn dữ liệu đặc tả. Điều này bao gồm cập nhật tất cả khung chờ chỉ đến tới khung dữ liệu đặc tả bị hỏng bất kỳ đã được thay đổi hoặc bị ảnh hưởng bởi sự thay đổi. Các máy chủ sẽ xóa khung dữ liệu đặc tả bất kỳ được trỏ đến bởi một khung Chờ mà máy khách đã loại bỏ. Các máy chủ có thể tái cấu trúc dữ liệu đặc tả sau khi tải lên được chấp nhận, nhưng phải trước khi các nguồn tài nguyên mới được tạo ra. Nếu không sử dụng được phần còn lại trong tập tin sau khi tải lên, các khung Free được sử dụng để điền vào những phần đó.

E.4.5 Tải lên ảnh hoàn chỉnh

Trong trường hợp chấp nhận tải lên của một ảnh hoàn chỉnh, các máy chủ cần giải nén (nếu cần) các ảnh phụ tải lên, giải nén một số phần của ảnh đầy đủ trên máy chủ, thay thế các điểm ảnh trong (không nén) miền không gian và nén lại tất cả các khối ảnh hoặc phân khu bị ảnh hưởng bởi các hoạt động cập nhật.

CHÚ THÍCH: Công nghệ này đòi hỏi phải tính toán nhiều hơn trên máy chủ. Tuy nhiên, nó loại bỏ khả năng r các máy khách sẽ sử dụng dữ liệu ảnh nén một cách không tương thích (ví dụ, sai số của mức biến đổi sóng con).

Phụ lục F

(Quy định)

Sử dụng JPIP trên HTTP

F.1 Tổng quan

Phụ lục này quy định phương pháp để sử dụng JPIP với HTTP cho cả các yêu cầu và đáp ứng. Các tham số yêu cầu JPIP trong Phụ lục C được đóng gói trong các cấu trúc yêu cầu HTTP hợp lệ. Các đáp ứng máy chủ (bao gồm cả mã trạng thái, tiêu đề, bản tin và mã đáp ứng) trong Phụ lục D được đóng gói trong các đáp ứng HTTP hợp lệ. Mọi yêu cầu và đáp ứng được mã hóa theo quy định của tiêu chuẩn HTTP.

Lưu ý rằng các đoạn văn bản và các ví dụ trong phụ lục này mô tả việc sử dụng JPIP trên nền HTTP. Điều này cũng được sử dụng đối với HTTP bảo mật (hay HTTPS).

F.2 Các yêu cầu

F.2.1 Giới thiệu các yêu cầu

Phụ lục C xác định các trường yêu cầu. Khi truyền tải qua HTTP, yêu cầu JPIP có thể xuất hiện như là một chuỗi truy vấn trong yêu cầu HTTP “GET” hoặc là phần thân của yêu cầu HTTP “POST”. Bởi vì một số hệ thống HTTP giới hạn độ dài của chuỗi truy vấn được cung cấp trong một yêu cầu, nên yêu cầu “GET”, “POST’ được ưu tiên cho các yêu cầu JPIP đầy đủ.

CHÚ THÍCH 1: Yêu cầu HTTP được định nghĩa trong phần 5 của RFC 2616 như sau:

CHÚ THÍCH 2: Các HTTP Request-Line và Request-URI được định nghĩa:

CHÚ THÍCH 3: RFC 2396 định nghĩa:

F.2.2 Yêu cầu GET

Yêu cầu JPIP có thể được cung cấp cho một máy chủ như là yêu cầu HTTP. Đối với yêu cầu “GET” giới hạn yêu cầu HTTP như đây:

– “Method” sẽ là “GET”.

– “query” bằng không hoặc jpip-request-field được phân tách bởi “&”

Một ví dụ về yêu cầu JPIP đóng gói trong yêu cầu HTTP “GET”:

Một ví dụ tương đương sử dụng một absoluteURI thay vì một abs_path:

CHÚ THÍCH: Tiêu chuẩn này áp đặt không hạn chế các thành phần lập lịch của absoluteURI.

F.2.3 Yêu cầu POST

Yêu cầu JPIP có thể được cung cấp cho một máy chủ đóng gói trong một yêu cầu HTTP “POST”. Đối với yêu cầu “POST” các yêu cầu HTTP được giới hạn theo cách sau đây:

– “Method” sẽ là “POST”.

– “entity-body” bằng không hoặc jpip-request-field được phân tách bởi “&”.

– Dòng tiêu đề “Content-type:” nên bao gồm như “entity-header” và có giá trị “application / x– www-form-urlencoded”.

Một ví dụ về yêu cầu JPIP đóng gói trong yêu cầu HTTP “POST” là:

F.2.4 Yêu cầu tải lên

Một yêu cầu tải lên là một yêu cầu HTTP hợp lệ bị hạn chế như sau:

– “Method” sẽ là “POST”.

– URL phải chứa query-field tải lên.

– Content-type sẽ là loại ảnh của phần thân: image/jpt-stream, image/jpp-stream, hoặc một kiểu phương tiện truyền thông ảnh hoàn chỉnh.

Một ví dụ về yêu cầu JPIP tải lên là:

F.3 Thiết lập phiên

Một HTTP (hoặc HTTPS) truyền thông theo phiên được thiết lập bằng cách sử dụng các trường yêu cầu Kênh Mới với giá trị của “http” (hoặc “https”), tức là, “cnew = http” (hoặc “cnew = https”) như là một phần được yêu cầu. Yêu cầu này thường được cung cấp bởi HTTP (hay HTTPS). Yêu cầu có thể chứa yêu cầu Cửa sổ hiển thị trở thành yêu cầu đầu tiên trong kênh mới. Đáp ứng của yêu cầu này sẽ được trả về trên cùng một kết nối với yêu cầu được thực hiện.

Máy khách có thể mở một kết nối HTTP (hay HTTPS) và phát đi một yêu cầu bao gồm tiêu đề HTTP (hay HTTPS) “Connection: keep-alive”. Điều này rất hữu ích cho các phiên hiệu quả, nhưng nó không phải là cần thiết và cũng không đủ để có một phiên. Một kết nối HTTP (hay HTTPS) có thể được sử dụng cho lưu lượng đối với các địa chỉ khác nhau, các kênh khác nhau, hoặc thậm chí lưu lượng không phải JPIP, ví dụ: yêu cầu đối với tập tin HTML. Yêu cầu JPIP là một phần của phiên có thể đến trên kết nối HTTP (hay HTTPS) khác hơn so với kết nối HTTP (hay HTTPS) được sử dụng để yêu cầu và phát hành các kênh mới, mặc dù không khuyến khích điều này.

F.4 Đáp ứng

F.4.1 Tổng quan

Mỗi thành phần của đáp ứng trong Phụ lục D có thể được đóng gói như là một phần của đáp ứng HTTP hợp lệ.

CHÚ THÍCH: Đáp ứng HTTP được định nghĩa trong phần 6 của RFC 2616 là:

Các đáp ứng JPIP truyền tải trên HTTP sẽ là các đáp ứng HTTP hợp lệ, với những hạn chế thêm vào một số phần của đáp ứng HTTP được mô tả trong các điều khoản dưới đây.

F.4.2 Mã trạng thái và Mệnh đề lý do

Tất cả các mã trạng thái được liệt kê trong Điều D.1.3 có thể được sử dụng trực tiếp như mã trạng thái HTTP. Ngoài ra một máy chủ cung cấp JPIP trên HTTP có thể sử dụng bất kỳ mã trạng thái HTTP được coi là hữu ích, ví dụ, 402.

Tất cả dữ liệu Mệnh đề lý do được cung cấp trong Điều D.1.3 có thể được sử dụng trực tiếp như Mệnh đề lý do HTTP. Mệnh đề lý do sẽ phù hợp với mã trạng thái. Máy chủ cung cấp JPIP qua HTTP có thể sử dụng bất kỳ Mệnh đề lý do HTTP được coi là hữu ích, ví dụ, yêu cầu Thanh toán.

F.4.3 Thông tin tiêu đề

F.4.3.1 Tiêu đề JPIP

Các dòng tiêu đề trong Điều D.2 được tính là “entity-header” trong đáp ứng HTTP mà không sửa đổi.

F.4.3.2 Sử dụng tiêu đề HTTP Accept

Máy chủ cung cấp JPIP trên HTTP có thể sử dụng dòng tiêu đề HTTP “Accept:” được tìm thấy trong yêu cầu để xác định loại đáp ứng JPIP. Nếu yêu cầu có chứa tham số truy vấn “type =”, kiểu trả về sẽ là một trong những loại được liệt kê trong kiểu tham số. Nếu yêu cầu có cả tham số truy vấn “type =” và dòng tiêu đề “Accept:”, máy chủ có thể sử dụng các ưu tiên được xác định trong dòng “Accept:” để lựa chọn giữa các loại quy định trong tham số truy vấn “type =”. Nếu không có tham số truy vấn “type =” trong các yêu cầu, máy chủ có thể chọn một kiểu trả về được hỗ trợ bởi máy chủ JPIP từ danh sách các loại trong “Accept:”

F.4.3.3 Sử dụng tiêu đề Cache-Control

Lưu ý rằng các bộ nhớ tạm thời trong các proxy HTTP khác với bộ nhớ đệm và mô hình bộ nhớ đệm trong JPIP.

Bất cứ yêu cầu JPIP với một trường yêu cầu Kênh Mới là một phần của phiên và đáp ứng như vậy có thể không \được lưu đệm bởi máy chủ proxy HTTP. Tương tự như vậy, bất kỳ đáp ứng nào bao gồm tiêu đề đáp ứng Kênh Mới cũng là một phần của phiên. Trong cả hai trường hợp, đáp ứng của máy chủ nên bao gồm một dòng tiêu đề HTTP “Cache-Control:” với giá trị “no-cache”.

F.4.3.4 Sử dụng tiêu đề Content-type

Máy chủ cung cấp JPIP trên HTTP nên bao gồm dòng tiêu đề “Content-type:”, chỉ ra loại dữ liệu trong phần thân, phổ biến nhất là image/jpp-stream hoặc image/jpt-stream.

F.4.3.5 Sử dụng tiêu đề Redirect

Các tiêu đề Redirect HTTP có thể hữu ích để thông báo cho máy khách rằng các nguồn đã di chuyển hoặc nên truy cập tới một máy chủ khác.

Lưu ý rằng các đáp ứng JPIP định nghĩa cách để chuyển hướng hiệu quả. Đáp ứng JPIP nên được tham chiếu trong phiên.

F.4.4 Phần thân

Các bản tin trong Phụ lục D được xem như phần thân của đáp ứng HTTP. Lưu ý rằng đáp ứng HTTP có một cơ chế để xác định độ dài của đáp ứng. Nếu máy chủ không có kế hoạch làm gián đoạn một đáp ứng, nó có thể cung cấp thông tin này với \dòng tiêu đề HTTP “Content-Length”. Các phương pháp tham chiếu cho việc cung cấp độ dài là sử dụng dòng tiêu đề HTTP “Transfer-Encoding: chunked” và sau đó cung cấp cho phần thân trong các óausc dữ liệu có kích thước xác định bởi máy chủ và quy định trước. Không khuyến khích kết thúc một đáp ứng bằng cách đóng các kết nối HTTP.

F.5 Tính năng HTTP bổ sung

F.5.1 Sử dụng phương thức HTTP HEAD

Máy khách và máy chủ JPIP không cần phải sử dụng hoặc hỗ trợ phương pháp HTTP “HEAD”. Một máy chủ lựa chọn để thực hiện phương pháp “HEAD” sẽ làm theo quy định tại Điều 9.4 của RFC 2616. Đặc biệt, “Phương thức HEAD giống hệt với GET, ngoại trừ các máy chủ sẽ không trả về phần thân bản tin trong đáp ứng.”

Máy khách có thể thấy sự hữu ích của nó khi phát hành yêu cầu HTTP “HEAD” như một phương tiện để xác định xem máy chủ sẽ sửa đổi bất kỳ thông số yêu cầu theo quy định tại Phụ lục D. Máy khách không nên phát hành yêu cầu HTTP “HEAD” với các trường truy vấn mô hình bộ nhớ đệm vì sẽ khiến các máy chủ cập nhật mô hình bộ nhớ đệm.

Lưu ý máy khách có nhu cầu cập nhật các mô hình bộ nhớ đệm của máy chủ mà không nhận được một đáp ứng có thể sử dụng các trường yêu cầu Độ dài Đáp ứng Tối đa.

Máy chủ có thể từ chối bất kỳ hoặc tất cả các yêu cầu “HEAD”. Không giống như yêu cầu HTTP “HEAD” điển hình đòi hỏi tương đối ít nỗ lực cho một máy chủ để thực hiện, Bộ cài máy chủ JPIP có thể có được dữ liệu từ một số vị trí trong địa chỉ logic, tính toán bản chất của đáp ứng, và sau đó loại bỏ phần thân của đáp ứng để đáp ứng với yêu cầu “HEAD”.

F.5.2 Sử dụng phương pháp HTTP OPTIONS

Máy khách và máy chủ JPIP không cần phải sử dụng hoặc hỗ trợ phương pháp HTTP “OPTIONS”.

F.5.3 Sử dụng Etag

Lưu ý HTTP định nghĩa cơ chế thẻ thực thể (ETag) tương tự như trường yêu cầu ID Địa chỉ JPIP trong đó nó được sử dụng để biểu thị những thay đổi trong tài nguyên. Nếu cả thẻ thực thể và địa chỉ ID có liên quan đến một tài nguyên, thì khuyến cáo rằng ETag quy định của HTTP được thay đổi bất cứ khi nào ID địa chỉ được thay đổi.

F.5.4 Sử dụng mã hóa truyền các khúc dữ liệu

Do đáp ứng có chứa dữ liệu nén có thể rất lớn và mất nhiều thời gian để truyền tải, điều quan trọng là để có thể tạm dừng truyền tải. Trừ khi “Transfer-Encoding: chunked” được quy định, các yêu cầu HTTP quy định cụ thể toàn bộ chiều dài của phần thân trong tiêu đề “Content-Length:” hoặc báo hiệu kết thúc dữ liệu bằng cách đóng kết nối. Không những là tham chiếu trong giao thức tương tác, vì nó có thể cần thiết để chặn các đáp ứng hiện tại và gửi nhiều dữ liệu hơn trên cùng một kết nối cho một đáp ứng mới.

CHÚ THÍCH 1: Điều 19.4.6 của RFC 2616 cung cấp một thuật toán để loại bỏ các mã hòa truyền khúc dữ liệu.

CHÚ THÍCH 2: Mã hòa truyền khúc dữ liệu có thể hữu ích với JPIP khi được phân phối qua các giao thức khác HTTP.

F.6 HTTP và trường yêu cầu độ dài (tham khảo)

Với một kênh trả về HTTP, máy chủ không nhận được phản hồi liên tục từ máy khách và có thể dễ dàng đẩy một lượng lớn dữ liệu vào đường truyền, sẽ được nhận đủ trước khi dữ liệu bất kỳ của một cửa sổ mới có thể được xử lý. Để duy trì đáp ứng, máy khách nên sử dụng trường yêu cầu Độ dài Đáp ứng Tối đa để điều chỉnh luồng lưu lượng và do đó duy trì đáp ứng. Máy khách nói chung cần phải thực hiện các thuật toán điều khiển lưu lượng của mình để điều chỉnh độ dài yêu cầu để thay đổi các điều kiện mạng.

Phụ lục G

(Quy định)

Sử dụng JPIP với các yêu cầu HTTP và các khai báo TCP

G.1 Tổng quan

Giao thức JPIP chính nó là trung tính đối với cơ chế truyền tải cơ bản đối với các yêu cầu của máy khách và đáp ứng máy chủ, ngoại trừ các yêu cầu kênh liên quan đại diện bởi trường yêu cầu Kênh Mới (“cnew“) (xem C.3.3) và tiêu đề đáp ứng Kênh Mới (“JPIP-cnew “) (xem D.2.3), trong đó chi tiết transport-specific sẽ được thông báo. Tiêu chuẩn này định nghĩa ba cách thức truyền tải cụ thể được xác định bởi các chuỗi “http”, “http-tcp” và “http- udp” trong chuỗi giá trị kết hợp với các yêu cầu Kênh mới. Phụ lục này cung cấp các chi tiết truyền tải thứ hai, sẽ được xác định trong văn bản này là HTTP–TCP. Truyền tải đầu tiên được xác định trong văn bản này là HTTP đã được mô tả trong Phụ lục F. Loại truyền tải thứ ba được xác định trong văn bản này là HTTP-UDP.

Truyền tải HTTP-TCP sử dụng chính xác cùng một cơ chế với truyền tải HTTP để gửi yêu cầu máy khách đến máy chủ và nhận các tiêu đề đáp ứng của máy chủ và mã trạng thái. Tuy nhiên, dữ liệu đáp ứng của máy chủ (không phải là tiêu đề đáp ứng) được phân phối qua kết nối TCP bổ trợ. Thông tin truyền tải trên kết nối TCP bổ trợ này giống với truyền tải phần thân của một đáp ứng thuần HTTP, ngoại trừ việc nó được đóng khung thành nhiều khúc dữ liệu, mỗi trong số đó có số thứ tự khúc dữ liệu.

Máy khách báo nhận một cách rõ ràng sự xuất hiện của mỗi khúc dữ liệu bằng cách gửi số thứ tự của nó trở lại cho máy chủ trên đường dẫn phản hồi lại của các kết nối TCP bổ trợ. Một trong những lợi ích của truyền tải HTTP-TCP là máy chủ nhận được các thông báo tăng dần của các khúc dữ liệu đáp ứng đến thông qua của cơ chế xác nhận của máy khách. Điều này cho phép các máy chủ quản lý luồng dữ liệu để duy trì đáp ứng nhanh và hiệu quả mạng lưới.

Mọi yêu cầu gửi qua truyền tải HTTP phải được mã hóa theo quy định của tiêu chuẩn HTTP.

G.2 Yêu cầu máy khách

Yêu cầu được chuyển tiếp trên các kênh chính chính xác như là các yêu cầu HTTP. Chúng có hình thức giống như các yêu cầu được phát hành trên kênh sử dụng truyền tải HTTP được mô tả trong Phụ lục F. Trong đó, các yêu cầu HTTP “GET“ và “POST“ có thể được sử dụng.

G.3 Thiết lập phiên

G.3.1 Thiết lập kênh

Một kênh mới có thể được thiết lập cho máy chủ JPIP bằng cách phát hành một yêu cầu bao gồm các trường yêu cầu Kênh Mới (xem C.3.3). Ví dụ, một yêu cầu như vậy có thể được phát hành bằng cách sử dụng HTTP, mặc dù nó cũng có thể cấp cho máy chủ JPIP cụ thể sử dụng cơ chế truyền tải bất kỳ phù hợp. Nếu đáp ứng của máy chủ (thông qua tiêu đề đáp ứng Kênh Mới trong Điều D.2.3) chỉ ra rằng một kênh mới đã được tạo ra để làm việc truyền tải HTTP-TCP, máy khách sẽ thiết lập kết nối TCP bổ trợ bằng cách sử dụng số cổng bổ trợ phản hồi lại thông qua tiêu đề đáp ứng Kênh Mới. Hơn nữa, yêu cầu trong đó bao gồm các trường yêu cầu Kênh Mới được xử lý như thể nó đã được phát hành mới tạo ra kênh truyền tải HTTP-TCP, có nghĩa là các dữ liệu đáp ứng được tạo ra bởi yêu cầu đó sẽ được phản hồi thông qua kết nối TCP bổ trợ, ngay vì nó đã được kết nối.

Để thiết lập kết nối TCP bổ trợ, máy khách đưa ra yêu cầu kết nối TCP đến máy chủ xác định thông qua tiêu đề đáp ứng Kênh Mới, trên cổng xác định bởi các tiêu đề đáp ứng Kênh Mới. Các máy khách sau đó ngay lập tức gửi dòng văn bản ASCII, bao gồm chuỗi ID Kênh mới, tiếp theo là cặp CR-LF liên tiếp. Đây là thông tin văn bản theo định hướng chỉ được phân phối qua kết nối TCP bổ trợ.

Máy khách sau đó chờ đợi để nhận dữ liệu đáp ứng của máy chủ qua kết nối TCP bổ trợ. Dữ liệu đáp ứng này không thể trống, vì mọi yêu cầu cấp cho kênh truyền tải HTTP-TCP có một dòng dữ liệu đáp ứng bao gồm ít nhất là bản tin EOR (xem D.3). Xem G.4 để biết thêm về điều này.

G.3.2 Khung hình máy chủ của dữ liệu đáp ứng

Tất cả dữ liệu đáp ứng được gửi bởi máy chủ thộng qua kết nối TCP bổ trợ được đóng khung thành khúc dữ liệu. Mỗi khúc dữ liệu bao gồm một tiêu đề khúc 8-byte, tiếp theo là phần thân của khúc chứa dữ liệu đáp ứng của máy chủ, như trong hình G.1. Từ 2-byte đầu tiên của tiêu đề khúc dữ liệu là một số nguyên kiểu big endian không dấu biểu diễn tổng chiều dài của khúc dữ liệu, bao gồm từ độ dài chính nó. Nội dung của 6 byte còn lại của tiêu đề khúc dữ liệu không được định nghĩa bởi tiêu chuẩn này. Chúng có thể được sử dụng cho các dấu hiệu máy chủ cụ thể bổ sung. Các máy khách sẽ trả về toàn bộ tiêu đề khúc dữ liệu 8-byte trong bản tin báo nhận khúc dữ liệu của nó.

Hình G.1 – Cấu trúc dữ liệu đáp ứng trên kết nối http-tcp

G.3.3 Xác nhận của máy khách đối với các khúc dữ liệu đáp ứng máy chủ

Ngay khi nhận được khúc dữ liệu đáp ứng máy chủ trên kết nối TCP bổ trợ, máy khách phải gửi tiêu đề khúc dữ liệu 8-byte lại cho máy chủ như là dòng dữ liệu không đóng khung, sử dụng đường dẫn phản hồi kết nối TCP. Mỗi khúc dữ liệu nhận tương ứng với một bản tin báo nhận theo thứ tự.

G.4 Đáp ứng Máy chủ

Để đáp ứng từng yêu cầu của máy khách, máy chủ sẽ gửi đáp ứng HTTP trả lời lại một đoạn văn bản cho máy khách trên kênh chính. Đoạn văn bản trả lời có chứa mã trạng thái, mệnh đề lý do và tất cả các tiêu đề đáp ứng JPIP liên quan và bất kỳ tiêu đề đáp ứng HTTP thích hợp. Tuy nhiên, không có dữ liệu đáp ứng được trả về thông qua kênh chính. Vì lý do này, sẽ không có phần thân thực thể HTTP trong đáp ứng HTTP-TCP. Hoặc tiêu đề đáp ứng HTTP “Content-length:” hoặc “Transfer-encoding:” được sử dụng.

Dữ liệu đáp ứng được chuyển tiếp qua kênh TCP bổ trợ, đóng khung thành khúc dữ liệu theo cách được mô tả trong Điều G.3.2. Do truyền tải HTTP-TCP chỉ được sử dụng với phiên và với kiểu trả về ảnh dòng JPP và dòng JPT, dữ liệu đáp ứng không thay đổi bao gồm một chuỗi các bản tin dòng JPP hoặc dòng JPT.

Các dữ liệu đáp ứng thu được từ mỗí yêu cầu sẽ bao gồm toàn bộ các khúc dữ liệu, có nghĩa là không có khúc dữ liệu nào chứa dữ liệu đáp ứng được tạo ra để đáp ứng hai yêu cầu khác nhau.

Đáp ứng cho mỗi và mọi yêu cầu kết thúc bằng bản tin EOR (xem D.3), ngay cả khi dữ liệu đáp ứng rỗng. Bản tin EOR được coi là một phần của dữ liệu đáp ứng và được đóng khung vào khúc dữ liệu cùng với bản tin dòng JPP và dòng JPT thực tế.

Điều này có nghĩa là tất cả các yêu cầu đưa ra trên kênh JPIP truyền tải HTTP-TCP được tạo ra từ ít nhất một khúc dữ liệu đáp ứng không rỗng từ máy chủ và khúc dữ liệu cuối cùng được tạo ra để đáp ứng yêu cầu kết thúc với bản tin EOR.

Lưu ý rằng không cần khúc dữ liệu đáp ứng truyền tải HTTP-TCP được sắp xếp trên biên của bản tin.

G.5 TCP và trường yêu cầu độ dài (Tham khảo)

Có thể là rất ít hoặc không có lý do cho việc sử dụng các trường yêu cầu Độ dài Đáp ứng Tối đa trên kênh khai báo TCP, nơi mà các máy chủ có thể điều chỉnh một cách cẩn thận luồng dữ liệu đáp ứng tới máy khách để duy trì đáp ứng.

Phụ lục H

(Quy định)

Sử dụng JPIP trên các giao thức truyền tải khác

H.1 Tổng quan

Tiêu chuẩn này không xác định bất kỳ giao thức truyền tải cụ thể nào giao thông truyền tải “http” được mô tả trong Phụ lục F và giao thức “http-tcp” được mô tả trong Phụ lục G. Mục đích của phụ lục này là cung cấp các hướng dẫn về việc triển khai JPIP trên các giao thức truyền thông không đáng tin cậy và cung cấp một phương pháp tiếp cận chung có thể được áp dụng cho một loạt các giao thức giao tải.

Trong việc phát triển cách tiếp cận chung, phụ lục này có ích để phân chia các khía cạnh của truyền thông thành hai kết nối truyền tải logic, được gọi là “kết nối yêu cầu ” và “kết nối dữ liệu”. Mỗi kết nối logic được hiểu để cung cấp đường dẫn truyền thông thuận và ngược. Vai trò của các đường dẫn như sau:

– Đường dẫn kết nối yêu cầu thuận được sử dụng đề gửi các yêu cầu JPIP từ máy khách đến máy chủ.

– Đường dẫn kết nối yêu cầu ngược lại được sử dụng bởi các máy chủ để xác nhận nhận được yêu cầu và trả về đáp ứng tiêu đề cho máy khách.

– Đường dẫn kết nối dữ liệu thuận được sử dụng để gửi bản tin dòng JPIP từ máy chủ tới khách hàng.

– Đường dẫn kết nối dữ liệu ngược được sử dụng bởi khách hàng để báo nhận bản tin dòng JPIP từ máy chủ.

Chương trình đọc sẽ nhận thấy rằng những vai trò này là phù hợp đường dẫn truyền thông của hai kênh TCP được sử dụng bởi truyền tải “http-tcp” được mô tả trong Phụ lục G. Thực ra các Điều trong phụ lục này có thể được hiểu như là một phần mở rộng của truyền tải “http-tcp” để truyền thông không đáng tin cậy. Lưu ý, mặc dù phụ lục này được mô tả hai kết nối logic khác nhau, không có lý do gì mà không thể thực hiện truyền thông qua kết nối truyền tải duy nhất.

Cuối cùng, nó được giả định rằng mỗi kết nối logic cung cấp một trong hai loại dịch vụ sau đây:

a) Dịch vụ dòng có định hướng đáng tin cậy, chẳng hạn như được cung cấp bởi TCP.

b) Dịch vụ gói có định hướng không tin cậy (ví dụ, xem “http-UDP” tại Phụ lục K). Trong trường hợp này, các gói dữ liệu có thể đến không theo thứ tự hoặc không đến.

Hai kịch bản được xem xét trong phụ lục này. Trong trường hợp đầu tiên, đường dẫn kết nối yêu cầu được cho là cung cấp dịch vụ dòng có định hướng đáng tin cậy, nhưng đường dẫn kết nối dữ liệu không đáng tin cậy. Trong trường hợp thứ hai, cả hai đường dẫn kết nối yêu cầu và kết nối dữ liệu là không đáng tin cậy. Điều này có ích để xử lý hai kịch bản này theo thứ tự.

H.2 Các yêu cầu đáng tin cậy với dữ liệu không tin cậy

Trong điều này, kết nối yêu cầu là đáng tin cậy, có nghĩa là yêu cầu đến máy chủ để không mất mát, và đáp ứng máy chủ nhận được bởi máy khách theo thứ tự và cũng không mất mát. Trong trường hợp này, các trường yêu cầu và tiêu đề đáp ứng có thể được truyền thông chính xác như trong giao thức “http-tcp”, và thực sự HTTP được khuyến khích cho việc truyền tải các yêu cầu và tiêu đề đáp ứng.

Các bản tin dòng JPIP, bao gồm cả bản tin EOR (xem D.3), được chia thành các gói và chuyển tiếp qua các kết nối dữ liệu không đáng tin cậy.

Các hướng dẫn chung sau đây cần quan sát khi xây dựng các truyền tải loại này:

a) Mỗi yêu cầu phải bao gồm trường yêu cầu ID Yêu cầu (xem C.3.5).

b) Đối với mỗi yêu cầu, sẽ có một bản tin EOR tương ứng, ngay cả khi không có bản tin dòng JPIP được gửi để đáp ứng yêu cầu này. Yêu cầu này cũng được áp dụng trong trường hợp truyền tải “http-tcp”.

c) Mỗi gói kết nối dữ liệu được xây dựng bởi các máy chủ sẽ bao gồm các bản tin dòng JPIP và/hoặc bản tin EOR. Hơn nữa, bản tin dòng JPIP đầu tiên trong mỗi gói phải có một tiêu đề đầy đủ, chứ không phải dựa vào sự lặp lại của các định danh dòng mã hoặc thành phần mã lớp của bản tin trước đó.

d) Tất cả các bản tin dòng JPIP (không nhất thiết có bản tin EOR) được tìm thấy trong gói kết nối dữ liệu thuộc đáp ứng của một yêu cầu duy nhất, và các yêu cầu tương ứng với ID Yêu cầu được mã hóa trong tiêu đề của gói.

e) Bản tin EOR có thể được tìm thấy hoặc ở phần cuối của gói cùng mang giá trị ID Yêu cầu như yêu cầu có đáp ứng đã kết thúc, hoặc trong khối chứa một hoặc nhiều bản tin EOR liên tiếp tìm thấy vào lúc bắt đầu gói đầu tiên ngay sau gói cuối cùng mang ID Yêu cầu đó. Chính sách này cho phép bản tin EOR tương ứng với một hoặc nhiều đáp ứng rỗng liên tiếp (ví dụ như do yêu cầu bị chặn) được đóng gói vào gói đầu tiên của đáp ứng không trống tiếp theo.

f) Ngoài giá trị ID Yêu cầu, mỗi tiêu đề gói nên bao gồm một số thứ tự gói. Thứ tự gói được thiết lập bằng 0 cho gói đầu tiên kết hợp với giá trị ID Yêu cầu bất kỳ cụ thể. Các gói dữ liệu tiếp theo với cùng giá trị ID Yêu cầu sẽ có số thứ tự liên tiếp. Chính sách này cho phép máy khách xác định bản tin EOR bất kỳ có thể chưa được nhận do mất gói. Điều quan trọng là máy khách có thể kết hợp với các yêu cầu dữ liệu đáp ứng, để đồng bộ các ảnh hưởng của các báo cáo thao tác mô hình bộ nhớ đệm tại máy chủ với trạng thái của bộ nhớ đệm của riêng mình.

g) Các máy khách xác nhận việc nhận được từng gói bằng cách gửi bản tin báo nhận đến máy chủ trên đường dẫn kết nối dữ liệu đáp ứng. Mỗi bản tin báo nhận cần có một bản sao tiêu đề các gói tin nhận được, nhưng cũng có thể chứa thêm thông tin. Các máy khách có thể quyết định gộp các bản tin báo nhận cho một số gói khi xây dựng các gói tin báo nhận. Tuy nhiên, việc gộp quá mức có thể ảnh hưởng đến độ tin cậy mà các máy chủ ước tính số liệu thống kê mạng.

h) Các máy chủ không bắt buộc phải truyền lại bất kỳ gói không xác nhận và máy khách không nên đợi truyền lại các gói bị mất. Một máy chủ thông minh có thể chọn để truyền lại các gói xác nhận phụ thuộc vào sự liên quan của chúng cửa sổ hiển thị hiện hành.

H.3 Các yêu cầu không tin cậy với dữ liệu không tin cậy

Điều này liên quan đến các truyền tải mà cả kết nối yêu cầu và dữ liệu đều không tin cậy. Hướng dẫn đối với kết nối dữ liệu được mô tả trong H.2 cho trường hợp dữ liệu được chuyển tiếp không chính xác. Với kết nối yêu cầu không tin cậy, nó có thể là một hoặc nhiều yêu cầu bị mất hoặc đến không theo trật tự tại các máy chủ. JPIP cũng được điều chỉnh để xử lý tình trạng này, do các máy chủ có quyền tự do chặn trước các yêu cầu trước đó khi một yêu cầu mới đến.

Các hướng dẫn chung sau đây cần quan sát khi xử lý yêu cầu không tin cậy, ngoài những mục được liệt kê trong H.2 đối với các kết nối dữ liệu không tin cậy.

a) Mỗi gói yêu cầu phải bao gồm một tiêu đề, xác định giá trị của ID Yêu cầu.

b) Mỗi gói yêu cầu cũng nên bao gồm số thứ tự, chứa đầy đủ thông tin để xác định có hay không tất cả các gói dữ liệu liên quan đến yêu cầu đã được nhận.

c) Trong nhiều trường hợp, máy chủ có thể đơn giản bỏ qua các gói tin yêu cầu bị mất khi một yêu cầu mới đến. Để làm điều này, máy chủ chỉ gửi bản tin EOR trên kết nối dữ liệu, chỉ ra rằng yêu cầu bị mất bị chặn ngay lập tức. Không cần gửi đi bản tin báo nhận để đáp ứng với các gói yêu cầu. Không cần gửi đi bất kỳ tiêu đề đáp ứng để đáp ứng với yêu cầu đang bị chặn ngay lập tức do một số hoặc tất cả các gói yêu cầu đã bị mất.

d) Đối với mỗi yêu cầu đến đầy đủ tại các máy chủ, máy chủ sẽ gửi một hay nhiều gói đáp ứng xác định các ID Yêu cầu và bao gồm tiêu đề đáp ứng bất kỳ. Điều này đúng ngay cả khi yêu cầu đến sau khi đáp ứng đã được gửi cho yêu cầu bất kỳ tiếp theo (ví dụ, do một số gói của các yêu cầu đã bị trì hoãn quá mức). Điều này cung cấp cho máy khách một cơ chế để xác định có hay không một yêu cầu quan trọng đã được nhận bởi máy chủ.

e) Một số loại yêu cầu sẽ được xử lý bởi các máy chủ để tránh mất đồng bộ với máy khách. Điều quan trọng nhất trong số này các yêu cầu bao gồm các trường thao tác bớt đi mô hình bộ nhớ đệm. Để kích hoạt máy chủ phát hiện các yêu cầu như vậy, mà không cần phải theo trình tự các dòng yêu cầu, yêu cầu tiêu đề gói nên bao gồm hai trường sau đây:

1) Cờ chỉ ra có hay không các gói thuộc một yêu cầu sẽ được xử lý trước khi xử lý yêu cầu tiếp theo.

2) ID Yêu cầu kết hợp với các yêu cầu gần nhất mà Cờ đề cập trong e1 được thiết lập.

Nếu máy chủ không nhận được một hoặc nhiều gói yêu cầu với bộ e1 Cờ (ví dụ, yêu cầu với điều kiện e2 đến và yêu cầu với cờ e1 bị mất), sẽ rảnh rỗi cho đến khi máy khách truyền lại các gói.

H.4 Cú pháp yêu cầu và đáp ứng

Cú pháp yêu cầu và đáp ứng được mô tả trong Phụ lục C và D nên được theo sau khi thiết kế các truyền tải mới cho giao thức JPIP. Tuy nhiên, nó được cho phép để phát triển các biểu diễn nhị phân tương đương của các trường yêu cầu và các tiêu đề đáp ứng khác nhau.

H.5 Thiết lập phiên

Trường yêu cầu Kênh Mới (xem D.2.3) và tiêu đề đáp ứng tương ứng có thể được sử dụng để tạo ra các kênh liên quan đến các giao thức vận chuyển khác với truyền tải “http” và “http-tcp” được mô tả chuẩn mực trong tiêu chuẩn này. Với mục đích này, tên giao thức vận chuyển mới có thể được đăng ký với hội đồng đăng ký theo quy định tại Phụ lục L. Các thủ tục cho việc tạo ra các kênh cho truyền tải mới nên thực hiện theo giống với các quy ước chung cho “http-tcp”. Đặc biệt, các tiêu đề đáp ứng cho các yêu cầu mà tạo ra các kênh mới sẽ được trả về trên chính truyền tải được sử dụng để tạo ra các kênh, trong khi dữ liệu đáp ứng phải được gửi bằng cách sử dụng truyền tải của kênh mới.

Phụ lục I

(Quy định)

Đánh chỉ mục cho các tập tin JPEG 2000 sử dụng JPIP

1.1 Tổng quan (tham khảo)

Tiêu chuẩn ISO / IEC 15444-1:2004 và các tiêu chuẩn khác định nghĩa định dạng tập tin họ tiêu chuẩn JPEG 2000. Họ tiêu chuẩn sử dụng một cú pháp chung, có phân tử cơ bản là phần chứa thông tin được gọi là khung. Phụ lục này xác định các khung định dạng tập tin mới có chứa thông tin chỉ mục, tạo điều kiện thuận lợi cho việc triển khai các tập tin này trên hệ thống JPIP, bằng cách cho phép trình đọc tập tin xác định vị trí các tập tin trong các phần tử được yêu cầu để cải thiện hình ảnh.

Đặc biệt, các khung này rất hữu ích:

– Cài đặt giao thức JPIP phía máy chủ;

– Máy khách truy cập vào một ảnh từ xa, sử dụng một giao thức đơn giản, cho phép truy cập tới dãy byte xác định trong tập tin.

Phụ lục này xác định khung Chỉ mục tương ứng với cả thông tin về mức tập tin và thông tin dòng mã. Các khung có thể được phân loại như sau:

– Siêu khung Chỉ mục Dòng mã (cidx) đánh chỉ số cho thông tin dòng mã tương ứng với các lớp tiêu đề chính, tiêu đề khối ảnh và ngăn dữ liệu phân khu ảnh của dòng JPP và dòng JPT. Nó chứa khung Dò tìm Dòng mã (cptr) trỏ tới dòng mã được đánh chỉ mục, khung Đặc tả (manf) tóm tắt phần còn lại của nội dung, và các khung Bảng Chỉ mục, như khung Chỉ số Tiêu đề (mhix), siêu khung Bảng Chỉ mục Phần khối ảnh (tpix), siêu khung Bảng Chỉ mục Tiêu đề Khối ảnh (thix), siêu khung Bảng Chỉ mục Gói Phân khu ảnh (pplx) và siêu khung Bảng Chỉ mục Tiêu đề Gói (phix). Các khung Bảng Chỉ mục tương ứng khác với các loại dữ liệu dòng mã biểu diễn bởi các lớp ngăn dữ liệu trong dòng JPP và dòng JPT quy định tại Phụ lục A. Các khung Bảng Chỉ mục là các siêu khung chứa khung Chỉ mục Mảng Phân mảnh (faix) hoặc Bảng Chỉ mục Tiêu đề liệt kê các phần từ dòng mã thực tế. Các siêu khung Bảng Chỉ mục Tiêu đề , Bảng Chỉ mục Gói Phân khu ảnh và Bảng Chỉ mục Tiêu đề Gói đều chứa khung Đặc tả.

– Siêu khung Chỉ mục Tập tin (fidx) đánh chỉ mục cho thông tin mức tập tin tương ứng phù hợp với các lớp ngăn dữ liệu đặc tả của dòng JPP và dòng JPT. Trừ khi nó chỉ ra mức cao nhất của các tập tin, trong trường hợp đó nó được gọi là khung Chỉ mục Tập tin gốc, nó có chứa khung Dò tìm Tập tin (fptr) trỏ đến siêu khung được đánh số. Nó có thể chứa các khung Proxy (prxy) biểu diễn nội dung của tập tin hoặc siêu khung được đánh số.

– Khung Dò tìm chỉ mục (iptr) trỏ tới Chỉ mục Tập tin gốc, có khả năng phát hiện vị trí của nó.

Hình I.1 Minh họa một tập tin JPEG 2000 mẫu chứa các khung Chỉ mục JPIP

Hình I.1 – Phần của tập tin JPEG 2000 mẫu chứa các khung Chỉ mục JPIP

I.2 Nhận diện việc sử dụng các khung Chỉ mục JPIP trong danh sách tương thích định dạng tập tin JPEG 2000

Các tập tin có chứa một hoặc nhiều khung được đánh chỉ mục theo định nghĩa trong tiêu chuẩn này có thể chứa một trường CLi trong khung Loại Tập tin (theo quy định tại Phụ lục I của Tiêu chuẩn ISO / IEC 15444-1) với giá trị ‘jpip’ (0x6a70 6970).

I.3 Các khung định nghĩa

1.3.1 Tổng quát

Bảng I.1 liệt kê tất cả các khung được xác định như là một phần của tiêu chuẩn này. Vị trí và hạn chế trên mỗi khung, được chỉ ra trong các mục dưới đây.

Bảng 1.1 mang tính tham khảo. Khái niệm quy định của mỗi khung được đưa ra trong các mục riêng tham chiếu trong bảng.

Bảng 1.1 – Các khung định nghĩa (Tham khảo)

Tên khung	Kiểu	Siêu khung	Các chú thích
Khung Chỉ mục dòng mã (I.3.2)	‘cidx’ (0x6369 6478)	Có	Khung này chứa thông tin đánh chỉ mục cho dòng mã JPEG 2000
Khung Dò tìm Dòng mã (I.3.2.2)	‘cptr’ (0x6370 7472)	Không	Khung này trỏ đến dòng mã JPEG 2000
Khung Bảng Chỉ mục Dòng mã (I.3.2.4.3)	‘mhix’ (0X6D68 6978)	Không	Khung này xác định chỉ mục của đoạn nhãn trong tiêu đề chính của dòng mã hoặc tiêu đề phần khối ảnh của khối ảnh.
Khung Bảng Chỉ mục Phần Khối ảnh (I.3.2.4.4)	‘tpix‘ (0x7470 6978)	Có	Khung này xác định vị trí và độ dài của từng phần khối ảnh trong dòng mã.
Khung Bảng Chỉ mục Tiêu đề Khối ảnh (I.3.2.4.5)	‘thix‘ (0x7468 6978)	Có	Khung này xác định vị trí và độ dài của từng phần dòng mã cần thiết để xây dựng tiêu đề khối ảnh cho từng khối ảnh để giải mã chính xác của dữ liệu gói phân khu ảnh.
Khung Bảng Chỉ mục Gói Phân khu ảnh (I.3.2.4.6)	‘ppix’ (0x7070 6978)	Có	Khung này xác định vị trí và độ dài của gói trong dòng mã.
Khung Bảng Chỉ mục Tiêu đề Gói (I.3.2.4.7)	‘phix’ (0x7068 6978)	Có	Khung này xác định vị trí và độ dài của tiêu đề gói trong dòng mã.
Khung Đặc tả (I.3.2.3)	‘manf‘ (0x6D61 6E66)	Không	Khung này tóm lược các khung liền kề ngay nó, chứa khung hoặc tập tin tại cùng mức với khung Đặc tả.
Khung Chỉ mục Mảng Phân mảnh (I.3.2.4.2)	‘faix’ (0x6661 6978)	Không	Khung này xác định vị trí và độ dài của các phần tử của một dòng mã.
Khung Chỉ mục Tập tin (I.3.3)	‘fidx‘ (0x6669 6478)	Có	Khung này có thể được sử dụng để tìm các chỉ mục khác và dữ liệu tùy ý trong tập tin
Khung Dò tìm Tập tin (I.3.3.2)	‘fptr‘ (0x6670 7472)	Không	Khung này trỏ tới một khung được đánh chỉ mục
Khung Proxy (I.3.3.3)	‘prxy’ (0x7072 7879)	Không	Khung này đại diện trong khung Chỉ mục Tập tin cho một khung ở vị trí khác trong tập tin
Khung Dò tìm chỉ mục (I.3.4)	‘iptr’ (0x6970 7472)	Không	Khung này trỏ khung Chỉ mục Tập tin gốc của tập tin

I.3.2 Khung Chỉ mục Dòng mã (siêu khung)

I.3.2.1 Tổng quát

Khung Chỉ mục Dòng mã có chứa thông tin đánh chỉ mục cho dòng mã JPEG 2000. Loại khung Chỉ mục Dòng mã là ‘cidx’ (0x6369 6478). Nội dung của khung Chỉ mục Dòng mã như sau (Hình I.2):

Hình I.2 – Tổ chức nội dung của Khung Chỉ mục Dòng mã

cptr: Khung Dò tìm Dòng mã. Khung này trỏ tới dòng mã được đánh số bởi Khung Chỉ mục Dòng mã. Cấu trúc của nó được quy định tại Điều H.3.2.2.

manf: Khung Đặc tả. Khung này tóm tắt các Bảng Chỉ mục bên trong Khung Chỉ mục dòng mã. Cấu trúc của nó được quy định tại Điều H.3.2.3.

I.3.2.2 Khung Dò tìm Dòng mã

Khung Dò tìm Dòng mã trỏ đến một dòng mã JPEG 2000. Loại khung Dò tìm Dòng mã là ‘cptr‘ (0x6370 7472). Nội dung của Khung Dò tìm Dòng mã như sau (Hình H.3):

Hình I.3 – Tổ chức nội dung của Khung Dò tìm Dòng mã

DR: Tham chiếu Dữ liệu. Trường này xác định vị trí của dòng mã, hoặc khung Bảng Phân mảnh đứng cạnh nó. Nếu bằng 0, dòng mã hoặc khung Bảng Phân mảnh của nó tồn tại trong tập tin hiện tại. Nếu không, số lượng định danh mục nhập nằm trong Tham chiếu Dữ liệu trong tập tin hiện tại. Trong trường hợp này, mục nhập Tham chiếu Dữ liệu xác định bởi chỉ mục DR cho biết nguồn tài nguyên chứa các dòng mã hoặc khung Bảng Phân mảnh. Trường này được lưu giữ như một số nguyên không dấu 2-byte kiểu big endian.

CONT: Loại Chứa thông tin. Trường này được lưu giữ như một số nguyên không dấu 2-byte kiểu big endian. Giá trị định nghĩa trong tiêu chuẩn này được mô tả trong Bảng H.2.

COFF: Độ lệch Dòng mã. Trường này xác định vị trí của dòng mã hoặc khung Danh sách Phân mảnh, nếu thích hợp, liên quan đến điểm bắt đầu của tập tin hoặc nguồn tài nguyên xác định bởi DR. Trường này được lưu giữ như một số nguyên không dấu 8-byte kiểu big endian.

Clen: Độ dài Dòng mã. Trường này xác định độ dài của dòng mã hoặc khung Danh sách Phân mảnh, nếu thích hợp. Trường này được lưu giữ như nguyên không dấu 8-byte kiểu big endian.

Bảng I.2 – Giá trị Loại Chứa thông tin

CONT	Ý nghĩa
0	Toàn bộ dòng mã xuất hiện trong phạm vi liền kề của các byte trong tập tin hoặc nguồn tài nguyên. Trong trường hợp này, giá trị độ lệch và độ dài cho trước ở đây đề cập đến dòng mã của nó. Lưu ý rằng dòng mã cũng có thể nằm trong khung Dòng mã Liền kề, nhưng giá trị độ lệch và độ dài đề cập đến chính dòng mã đó, điểm bắt đầu tại nhãn SOC và kết thúc ngay sau nhãn EOC.
1	Dòng mã là bị phân mảnh và giá trị vị trí và độ dài đề cập đến khung Danh sách Phân mảnh (bao gồm tiêu đề khung) mô tả vị trí và độ dài của từng phân mảnh biểu diễn cho dòng mã. Lưu ý rằng tất cả các vị trí và độ dài tiếp theo được thể hiện liên quan đến điểm bắt đầu của dòng mã, vì nó sẽ xuất hiện sau khi phục dựng tất cả các phân mảnh được xác định trong khung Danh sách Phân mảnh.
Tất cả các giá trị khác	Dành riêng cho ISO sử dụng.

I.3.2.3 Khung Đặc tả

Khung Đặc tả tóm tắt các khung liền kề ngay nó, chứa khung hoặc tập tin ở cùng mức với khung Đặc tả.

CHÚ THÍCH: Khung Đặc tả có thể được sử dụng để dễ dàng truy cập ngẫu nhiên vào các khung theo sau, chẳng hạn như khung Chỉ mục theo sau nó bên trong khung Chỉ mục Dòng mã.

Loại khung Đặc tả là ‘manf‘ (0x6D61 6E66). Nội dung của khung Đặc tả như sau (Hình I.4):

Hình 1.4 – Tổ chức các nội dung của một khung Đặc tả

BHⁱ: Tiêu đề Khung. Trường này chứa đầy đủ tiêu đề khung của khung thứ i ngay sau khung Đặc tả. Chiều dài của trường này là 16 byte nếu giá trị của trường LBox chứa trong khung tiêu đề đó là 1, hoặc 8 byte với trường hợp khác.

Số lượng các khung N, có các tiêu đề chứa trong khung Đặc tả, được xác định bởi chiều dài của khung Đặc tả. Khi sử dụng bên trong khung Bảng Chỉ mục Gói Phân khu ảnh hay khung Bảng Chỉ mục Tiêu đề Gói, N sẽ là số thành phần dòng mã.

Bên trong khung Chỉ mục Dòng mã, khung Bảng Chỉ mục Tiêu đề Khối ảnh, khung Bảng Chỉ mục Gói Phân khu ảnh hay khung Bảng Chỉ mục Tiêu đề Gói, khung Đặc tả sẽ bao gồm tất cả các khung theo sau nó, đến điểm cuối của khung chứa.

I.3.2.4 Các Bảng Chỉ mục

I.3.2.4.1 Tổng quát

Khung Chỉ mục Dòng mã có thể chứa một Bảng Chỉ mục cho từng loại dữ liệu dòng mã: Tiêu đề chính, phần khối ảnh, tiêu đề khối ảnh, gói (phân khu ảnh) và tiêu đề gói. Mỗi Bảng Chỉ mục là một loại khung khác nhau. Có tối đa một loại bảng trong khung Chỉ mục Dòng mã.

Khung Bảng Chỉ mục Phần khối ảnh, Bảng Chỉ mục Gói Phân khu ảnh và Bảng Chỉ mục Tiêu đề Gói là các siêu khung chứa các khung Chỉ mục Mảng Phân mảnh. Khung Bảng Chỉ mục Tiêu đề Khối ảnh là một siêu khung chứa các khung Bảng Chỉ mục Tiêu đề. Đầu tiên xét khung Chỉ mục Mảng Phân mảnh và sau đó là các khung Bảng Chỉ mục.

I.3.2.4.2 Khung Chỉ mục Mảng Phân mảnh

Khung Chỉ mục Mảng Phân mảnh liệt kê các vị trí và độ dài của các phần tử trong dòng mã. Nó được sử dụng trong siêu khung Bảng Chỉ mục Phần khối ảnh, Bảng Chỉ mục Gói Phân khu ảnh và Bảng Chỉ mục Tiêu đề Gói.

Loại khung Chỉ mục Mảng Phân mảnh là ‘faix’ (0x6661 6978). Nội dung của khung Chỉ mục Mảng Phân mảnh như sau (Hình I.5):

Hình I.5 – Tổ chức nội dung của khung Chỉ mục Mảng phân mảnh

V: Phiên bản. Trường này được mã hóa như là một số nguyên không dấu 1 byte. Các giá trị được định nghĩa trong tiêu chuẩn này được mô tả trong Bảng I.3.

NMAX: Số lượng phần tử hợp lệ tối đa trong hàng bất kỳ của mảng. Khi sử dụng bên trong Bảng Chỉ mục dòng mã, NMAX là số lượng phần tử tối đa các yếu tố được chỉ ra trong khối ảnh bất kỳ.

M: Số hàng của mảng. Khi sử dụng bên trong Bảng Chỉ mục dòng mã, M là số lượng khối ảnh.

OFF^i,j: Độ lệch. Trường này quy định cụ thể độ lệch tính theo byte (liên quan đến điểm bắt đầu của dòng mã) của phần tử thứ j trong dòng i của mảng.

LEN^i,j: Độ dài. Trường này xác định độ dài tính theo byte của phần tử thứ j trong dòng i của mảng.

AUX^i,j: Bổ trợ. Trường này xác định thông tin bổ trợ cho phần tử thứ j thuộc dòng i của mảng. Giá trị của trường này sẽ bằng không nếu không cho phép siêu khung chứa khung này. Tất cả các giá trị khác không của trường này được dự trữ.

Trong khi tất cả các hàng của mảng quy định tại khung Chỉ mục Mảng Phân mảnh được lưu trữ với số lượng phần tử NMAX, các đối tượng được mô tả bởi hàng có số lượng phần tử nhỏ hơn để xác định. Trong trường hợp này, hàng i bất kỳ chứa các phần tử J hợp lệ, trong đó J nhỏ hơn NMAX, các giá trị từ OFF^l,j đến 0FF^i,NMAX^–¹ và từ LEN^i,j đến LEN^i,NMAX^–¹ được thiết lập bằng không.

Bảng I.3 – Các giá trị phiên bản

CONT	Ý nghĩa
0	Trường NMAX, M và tất cả OFF^i,j và LEN^i,j, được mã hóa như số nguyên không dấu 4-byte kiểu big endian và trường AUX^i,j là không xuất hiện.
1	Trường NMAX, M và tất cả OFF^i,j và LEN^i,j được mã hóa như số nguyên không dấu 4-byte kiểu big endian và các trường AUX^i,j là không xuất hiện.
2	Tất cả các trường khác V được mã hóa như số nguyên không dấu 4-byte kiểu big endian.
3	Trường NMAX, M và tất cả OFF^i,jvà LEN^i,j được mã hóa như số nguyên không dấu 8-byte kiểu big endian và trường AUX^i,j được mã hóa như số nguyên không dấu 4-byte kiểu big endian.
Tất cả các giá trị khác	Dành riêng cho ISO sử dụng.

I.3.2.4.3 Khung Bảng Chỉ mục Tiêu đề

Khung Bảng Chỉ mục Tiêu đề đánh chỉ mục cho tiêu đề chính của dòng mã hoặc tiêu đề phần khối ảnh của khối ảnh, chỉ ra tổng độ dài tiêu đề chính hoặc độ dài phần khối ảnh đầu tiên, vị trí và độ dài của các đoạn nhãn trong tiêu đề. Tất cả các đoạn nhãn sẽ được bao gồm, ngoại trừ đoạn nhãn SOT có thể bị bỏ qua, đối với tiêu đề phần khối ảnh chỉ bao gồm SOT và SOD. Đoạn nhãn không cần liệt kê theo thứ tự xuất hiện trong dòng mã. Khung Bảng Chỉ mục Tiêu đề chỉ xuất hiện trong khung Chỉ mục Dòng mã. Ở mức độ cao nhất, nó đánh chỉ mục cho dòng mã và được thực hiện không quá một lần. Trong Khung Bảng Chỉ mục Tiêu đề, nó đánh chỉ mục cho các tiêu đề phần khối ảnh.

CHÚ THÍCH: Mục đích để cung cấp phương thức hiệu quả để bỏ qua thông tin con trỏ trong tiêu đề, không cần yêu cầu hiệu quả truy cập tập tin nhưng có thể không cần thiết số lượng lớn các tiêu đề. Thống kê nhiều đoạn nhãn với cũng mã nhãn liền kề trong khung Bảng Chỉ mục Tiêu đề sẽ cho phép trình đọc bỏ qua nhóm các đoạn nhãn, mà chúng không quan tâm.

Loại khung Bảng Chỉ mục Tiêu là ‘mhix’ (0x6D68 6978). Nội dung của khung Bảng Chỉ mục Tiêu đề như sau (Hình I.6):

Hình I.6 – Tổ chức nội dung của khung Bảng Chỉ mục Tiêu đề

TLEN: Độ dài. Khi khung Bảng Chỉ mục Tiêu đề đánh chỉ mục cho tiêu đề chính, trường này xác định tổng độ dài tiêu đề chính. Khi khung Bảng Chỉ mục Tiêu đánh chỉ mục cho tiêu đề phần khối ảnh, trường này xác định tổng độ dài của tiêu đề phần khối ảnh đầu tiên. Giá trị của trường này được mã hóa như là một số nguyên không dấu 8-byte kiểu big endian.

Mⁱ: Mã Nhãn. Trường này quy định cụ thể các mã nhãn bắt đầu đoạn nhân thứ i được liệt kê trong khung này. Giá trị của trường này được mã hóa như là một số nguyên không dấu 2-byte kiểu big endian.

NRⁱ: Số còn lại. Trường này chỉ ra rằng (ít nhất) NRⁱ đoạn nhãn với cũng mã nhãn Mⁱ được liệt kê liền kề ngay đoạn nhãn thứ i trong danh sách này. Giá trị của trường này được mã hóa như là một số nguyên không dấu 2-byte kiểu big endian.

OFFⁱ: Độ lệch. Trường này quy định độ lệch cụ thể tính theo byte, liên quan đến điểm bắt đầu của dòng mã, các tham số đoạn nhãn (bao gồm cả tham số độ dài, nhưng không phải nhãn của chính nó) đối với đoạn nhãn thứ i trong danh sách này. Giá trị của trường này được mã hóa như là một số nguyên không dấu 8-byte kiểu big endian.

LENⁱ: Độ dài. Trường này xác định độ dài tính theo byte của các tham số đoạn nhãn (bao gồm cả hai byte của tham số độ dài nhưng không phải là nhãn hai byte của chính nó) đối với đoạn nhãn thứ i trong danh sách này. Giá trị của trường này được mã hóa là một số nguyên không dấu 2-byte kiểu big endian, và giống như giá trị của tham số độ dài trong đoạn nhãn của chính nó.

Số lượng đoạn nhãn N, được liệt kê trong khung Bảng Chỉ mục Tiêu đề, được xác định bởi độ dài của khung Bảng Chỉ mục Tiêu đề.

I.3.2.4.4 Khung Bảng Chỉ mục phần Khối ảnh (siêu khung)

Khung Bảng Chỉ mục phần Khối ảnh đánh chỉ mục cho vị trí và độ dài của từng phần khối ảnh trong dòng mã, trong đó mỗi phần khối ảnh bắt đầu với nhãn SOT và kết thúc với các gói cuối cùng của phần khối ảnh.

Loại Khung Bảng Chỉ mục phần Khối ảnh là ‘tpix’ (0x7470 6978). Nội dung của Khung Bảng Chỉ mục phần Khối ảnh như sau (Hình I.7):

Hình I.7 – Tổ chức nội dung của Khung Bảng Chỉ mục phần Khối ảnh

faix: Khung Chỉ mục Mảng phân mảnh. Khung này liệt kê vị trí và độ dài của tất cả các phần khối ảnh trong dòng mã. Cấu trúc của nó được quy định tại Điều H.3.2.4.2. Hàng thứ m trong bảng này tương ứng với khối ảnh thứ m trong dòng mã. Các mục nhập trên hàng này giữ các vị trí và độ dài của tất cả phần khối ảnh trong khối ảnh tương ứng, theo thứ tự dòng mã. Nếu khung Chỉ mục Mảng phân mảnh có trường Phiên bản bằng 2 hoặc 3, thì trường Bổ trợ chỉ định từng phần khối ảnh nhỏ nhất n, trong tất cả các thành phần ảnh (N_L – n) không âm, mức phân giải (N_L – n) và tất cả các mức phân giải thấp hơn đã được hoàn thành khi phần khối ảnh này được kết hợp với các phần khối ảnh trước trong cùng một khối ảnh, trong đó N_L là số mức phân tách, có thể thay đổi tùy theo thành phần. Nếu không hoàn thành mức phân giải cho thành phần bất kỳ, giá trị của trường Bổ trợ bằng giá trị tối đa N_L công một. Giá trị không đạt được khi hoàn thành tất cả độ phân giải cho tất cả các thành phần. Do độ phân giải không nhất thiết phải xuất hiện theo thứ tự trong một khối ảnh, một số mức phân giải cao hơn giá trị báo hiệu bởi trường Bổ trợ có thể được hoàn thành.

I.3.2.4.5 Khung Bảng Chỉ mục Tiêu đề Khối ảnh (siêu khung)

Khung Bảng Chỉ mục Tiêu đề Khối ảnh đánh chỉ mục cho các tiêu đề khối ảnh của từng khối ảnh, đối với việc giải mã chính xác của dữ liệu gói phân khu ảnh.

Loại khung Bảng Chỉ mục Tiêu đề Khối ảnh là ‘thix’ (0x7468 6978). Nội dung khung Bảng Chỉ mục Tiêu đề Khối ảnh như sau (Hình I.8):

Hình 1.8 – Tổ chức nội dung của khung Bảng Chỉ mục Tiêu đề Khối ảnh

Số lượng khung Bảng Chỉ mục Tiêu đề N, là số lượng khối ảnh.

manf: Khung Đặc tả. Khung này tóm lược các khung quy định bởi mhixⁱ trong khung Bảng Chỉ mục Tiêu đề Khối ảnh này. Cấu trúc của nó được quy định tại Điều I.3.2.3.

mhixi: Khung Bảng Chỉ mục Tiêu đề. Khung này đánh chỉ mục cho các tiêu đề phần khối ảnh của khối ảnh thứ i. cấu trúc của nó được quy định tại Điều I.3.2.4.3.

I.3.2.4.6 Khung Bảng Chỉ mục Gói Phân khu ảnh (siêu khung)

Khung Bảng Chỉ mục Gói Phân khu ảnh đánh chỉ mục cho các gói trong dòng mã. Loại khung Bảng Chỉ mục Gói Phân khu ảnh là ‘ppix’ (0x7070 6978). Nội dung của khung Bảng Chỉ mục Gói Phân khu ảnh như sau (Hình I.9):

Hình I.9 – Tổ chức nội dung của khung Bảng Chỉ mục Gói Phân khu ảnh

Số lượng các khung Chỉ mục Mảng Phân mảnh N, không được lớn hơn số lượng thành phần dòng mã.

manf: Khung Đặc tả. Khung này tóm lược các khung quy định bởi faixⁱ trong khung Bảng Chỉ mục Gói Phân khu ảnh này. Cấu trúc của nó được quy định tại Điều H.3.2.3.

faixⁱ: Khung Chỉ mục Mảng Phân mảnh thứ i tương ứng với thành phần ảnh thứ i trong dòng mã. Hàng thứ m trong bảng này tương ứng với khối ảnh thứ m trong dòng mã. Các mục nhập trên hàng này giữ các vị trí và độ dài của tất cả các gói tương ứng với khối ảnh thành phần. Các gói xuất hiện liên tiếp, tăng dần theo thứ tự lớp, trong phân khu ảnh của chúng, và các phân khu ảnh xuất hiện theo thứ tự được gán với số thứ tự s được quy định tại Điều A.3.2.1. Tuy nhiên, thứ tự cố định của các gói dữ liệu không nhất thiết phải giống như quy định trong bất kỳ đoạn nhãn COD/POC trong dòng mã. Cấu trúc của khung Chỉ mục Mảng Phân mảnh được quy định tại Điều I.3.2.4.2.

Nếu tiêu đề gói được đóng gói vào đoan nhãn PPM hoặc PPT, các mục nhập tương ứng trong mảng phân mảnh đề cập đến vị trí và độ dài của phần thân gói duy nhất, nó xuất hiện trong phần thân của phần khối ảnh. Các mục nhập đề cập đến các gói không tồn tại (hoặc do khối ảnh thành phần có liên quan bao gồm một vài gói khác các khối ảnh thành phần trong cùng một mảng, hoặc do dòng mã đã được cắt ngắn trước thời điểm mà tại đó gói đã tồn tại) có trường vị trí được thiết lập bằng không. Các mục nhập đề cập đến các gói mà phần thân rỗng và tiêu đề bao gồm chính xác một byte, 0x80, có thể được xác định bằng cách sử dụng giá trị độ dài bằng không. Các gói dữ liệu như vậy xuất hiện thường xuyên trong các dòng mã JPEG 2000; các ứng dụng có thể tránh truy cập các mào đầu của gói mà nội dung có thể dự đoán được. Nếu đoạn nhãn COD liên quan xác định rằng các nhãn EPH xuất hiện sau mỗi tiêu đề gói trong khối ảnh, giá trị độ dài cụ thể bằng không được giải thích trong khối ảnh có nghĩa là các gói bao gồm các byte 0x80 theo sau là nhãn EPH.

I.3.2.4.7 Khung Bảng Chỉ mục Tiêu đề Gói (siêu khung)

Khung Bảng Chỉ mục Tiêu đề Gói đánh chỉ mục cho các tiêu đề gói trong dòng mã. Loại khung Bảng Chỉ mục Tiêu đề Gói là ‘phix’ (0x7068 6978). Nội dung khung Bảng Chỉ mục Tiêu đề Gói như sau (Hình H.10):

Hình I.10 – Tổ chức nội dung của Khung Bảng Chỉ mục Tiêu đề Gói

Số lượng các khung Chỉ mục Mảng Phân mảnh N, không được lớn hơn số lượng thành phần dòng mã.

manf: Khung Đặc tả. Khung này tóm lược các khung quy định bởi faixⁱ trong khung Bảng Chỉ mục Tiêu đề Gói này. Cấu trúc của nó được quy định tại Điều I.3.2.3.

faixⁱ: Khung Chỉ mục Mảng Phân mảnh thứ i tương ứng với thành phần ảnh thứ i trong dòng mã. Hàng thứ m trong bảng này tương ứng với khối ảnh thứ m trong dòng mã. Các mục nhập trên hàng này giữ các vị trí và độ dài của tất cả tiêu đề gói tương ứng với khối ảnh thành phần. Các tiêu đề gói xuất hiện liên tiếp, tăng dần theo thứ tự lớp, trong phân khu ảnh của chúng, và các phân khu ảnh xuất hiện theo thứ tự được gán với số thứ tự s được quy định tại Điều A.3.2.1. Tuy nhiên, thứ tự cố định của các tiêu đề gói dữ liệu không nhất thiết phải giống như quy định trong bất kỳ đoạn nhãn COD/POC trong dòng mã. Cấu trúc của khung Chỉ mục Mảng Phân mảnh được quy định tại Điều I.3.2.4.2.

Các mục nhập đề cập đến tiêu đề gói không tồn tại (hoặc do khối ảnh thành phần có liên quan bao gồm một vài gói khác các khối ảnh thành phần trong cùng một mảng, hoặc do dòng mã đã được cắt ngắn trước thời điểm mà tại đó tiêu đề gói đã tồn tại) có trường vị trí được thiết lập bằng không. Các mục nhập đề cập đến các gói mà phần thân rỗng và tiêu đề bao gồm chính xác một byte, 0x80, có thể được xác định bằng cách sử dụng giá trị độ dài bằng không. Các gói như vậy xuất hiện thường xuyên trong các dòng mã JPEG 2000; các ứng dụng có thể tránh truy cập các mào đầu của gói mà nội dung có thể dự đoán được. Nếu đoạn nhãn COD liên quan xác định rằng các nhãn EPH xuất hiện sau mỗi tiêu đề gói trong khối ảnh, giá trị độ dài cụ thể bằng không được giải thích trong khối ảnh có nghĩa là các gói bao gồm các byte 0x80 theo sau là nhãn EPH.

I.3.3 Khung Chỉ mục Tập tin (siêu khung)

I.3.3.1 Tổng quát

Khung Chỉ mục Tập tin có thể được sử dụng để tìm các chỉ mục khác (đặc biệt, chỉ mục dòng mã tương ứng với dòng mã) và dữ liệu tùy ý trong tập tin.

Khung Chỉ mục Tập tin gốc đánh chỉ mục cho mức cao nhất của tập tin. Khung Chỉ mục Tập tin bất kỳ đánh chỉ số cho một siêu khung trong tập tin. Phải có ít nhất một khung Chỉ mục Tập tin với phạm vi áp dụng cho trước (mức cao nhất hoặc siêu khung cụ thể) trong tập tin nhất định.

Loại khung Chỉ mục Tập tin là ‘fidx’ (0x6669 6478). Các nội dung khung Chỉ mục Tập tin như sau (Hình I.11):

Hình I.11 – Tổ chức nội dung của khung Chỉ mục Tập tin

fptr: Khung Dò tìm Tập tin. Khung Chỉ mục Tập tin gốc sẽ không bao gồm khung này. Khung Chỉ mục Tập tin bất kỳ bao gồm khung này, trỏ tới siêu khung được đánh số bởi khung Chỉ mục Tập tin. Cấu trúc của khung Dò tìm Tập tin được định nghĩa trong Điều I.3.3.2.

prxyⁱ: Khung Proxy. Khung này biểu diễn một phần của tập tin được đánh số bởi khung Chỉ mục Tập tin. Khung Chỉ mục Tập tin gốc bao gồm các proxy cho khung ở mức cao nhất của tập tin. Khung Chỉ mục Tập tin bất kỳ bao gồm các proxy cho các khung ở mức cao nhất của siêu khung được đánh số bởi khung Chỉ mục Tập tin. Các proxy có cùng thứ tự khung, nhưng không phải tất cả các khung đều được ủy nhiệm. Cấu trúc của khung Proxy được xác định trong Điều I.3.3.3.

CHÚ THÍCH: Tùy vào từng trường hợp mà sự xuất hiện, vắng mặt, hoặc trình tự các khung trong các tập tin là quan trọng, nó hữu ích cho các ứng dụng nếu, có khung Proxy bất kỳ phía trước như vậy, không có khung trong phạm vi áp dụng của chỉ mục bị bỏ qua từ chỉ mục.

I.3.3.2 Khung Dò tìm Tập tin

Khung Dò tìm Tập tin trỏ vào một khung. Loại khung Dò tìm Tập tin là ‘fptr‘ (0x6670 7472). Nội dung khung Dò tìm Tập tin như sau (Hình I.12):

Hình I.12 – Tổ chức nội dung của khung Dò tìm Tập tin

OOFF: Độ lệch ban đầu. Trường này quy định độ lệch cụ thể tính theo byte (liên quan đến điểm bắt đầu của tập tin) của khung được trỏ đến khung Dò tìm Tập tin này. Giá trị của trường này được mã hóa như là một số nguyên không dấu 8-byte kiểu big endian.

OBH: Tiêu đề Khung ban đầu. Trường này chứa tiêu đề khung đầy đủ của khung được trỏ đến bởi khung Dò tìm Tập tin này. Độ dài của trường này là 16 byte nếu giá trị của trường LBox chứa trong khung tiêu đề đó là 1, hoặc 8 byte với trường hợp khác.

I.3.3.3 Khung Proxy

Khung Proxy đại diện cho một khung Chỉ mục Tập tin nằm trong tập tin, đánh chỉ mục cho vị trí và độ dài của nó, vị trí và độ dài của bất kỳ chỉ mục của khung, và tiền tố của nội dung khung.

Loại khung Proxy là ‘prxy’ (0x7072 7879). Nội dung khung Proxy như sau (Hình I.13):

Figure H.13 – Tổ chức nội dung của khung Proxy

OOFF: Độ lệch ban đầu. Trường này quy định độ lệch cụ thể tính theo byte (liên quan đến điểm bắt đầu của tập tin) của khung được trỏ đến khung Proxy này. Giá trị của trường này được mã hóa như là một số nguyên không dấu 8-byte kiểu big endian.

OBH: Tiêu đề Khung ban đầu. Trường này chứa tiêu đề khung đầy đủ của khung được trỏ đến bởi khung Proxy này. Độ dài của trường này là 16 byte nếu giá trị của trường LBox chứa trong khung tiêu đề đó là 1, hoặc 8 byte với trường hợp khác.

NI: Số lượng chỉ mục. Trường này cho biết số lượng con trỏ chỉ mục bao gồm trong khung Proxy này. Mỗi tập trường IOFFⁱ, và IBHⁱ trỏ đến hoặc là khung Chỉ mục Tập tin hoặc là khung Chỉ mục Dòng mã được đánh chỉ mục cho khung đại diện bởi khung Proxy này. Tất cả các giá trị khác được dự trữ. Giá trị của trường này được mã hóa như là một số nguyên không dấu 1 byte.

IOFFⁱ: Độ lệch Chỉ mục. Trường này chứa độ lệch tính theo byte (liên quan đến điểm bắt đầu của tập tin) của khung chỉ mục thứ i. Giá trị của trường này được mã hóa như là một số nguyên không dấu 8-byte kiểu big endian.

IBHⁱ: Tiêu đề Khung Chỉ mục. Trường này chứa tiêu đề khung đầy đủ của khung chỉ mục thứ i. Độ dài của trường này là 16 byte nếu giá trị của trường LBox chứa trong đó tiêu đề là 1 khung, hoặc 8 byte với trường hợp khác.

PREF: Tiền tố. Trường này chứa một tiền tố tùy ý của dữ liệu trong khung đại diện bởi khung Proxy này. Nó có thể có độ dài từ không đến độ dài của nội dung khung ban đầu.

I.3.4 Khung Dò tìm Chỉ mục

Khung Dò tìm chỉ mục trỏ đến khung Chỉ mục Tập tin gốc của tập tin. Nó sẽ chỉ xuất hiện nếu tập tin có chứa khung Chỉ mục Tập tin gốc. Loại khung Dò tìm chỉ mục là ‘iptr‘ (0x6970 7472). Nội dung khung Dò tìm chỉ mục như sau (Hình I.14):

Hình I.14 – Tổ chức nội dung của khung Dò tìm chỉ mục

OFF: Độ lệch. Trường này xác định vị trí của khung Chỉ mục Tập tin gốc liên quan đến điểm bắt đầu của tập tin. Trường này được lưu như một số nguyên không dấu 8-byte kiểu big endian.

LEN: Độ dài. Trường này xác định kích thước của khung Chỉ mục Tập tin gốc. Trường này được lưu như một số nguyên không dấu 8-byte kiểu big endian.

I.4 Kết hợp chỉ mục dòng mã với dòng mã

Trong một tập tin JP2, JPX hoặc JPM, khung Chỉ mục Dòng mã sẽ xuất hiện ở mức cao nhất của tập tin và các khung Chỉ mục Dòng mã thứ i tương ứng, cũng ở mức cao nhất của tập tin. Khung Dò tìm Dòng mã trong khung Chỉ mục Dòng mã cũng chỉ ra dòng mã được đánh chỉ mục bởi khung Chỉ mục Dòng mã.

I.5 Các giới hạn vị trí (tham khảo)

Một vài giới hạn vị trí đã được áp dụng trên các khung xác định tại phụ lục này. Chúng có thể được đặt ở cuối của tập tin nếu muốn; điều này thuận tiện khi tập tin không được đánh số được đánh chỉ mục tiếp theo. Tuy nhiên, nó có thể hữu ích cho việc đặt khung Dò tìm chỉ mục gần điểm bắt đầu tập tin, tốt nhất là ngay sau khung bất kỳ được yêu cầu trong nhóm liền kề ở phần đầu của tập tin (chẳng hạn như sau khung Loại Tập tin trong tập tin JP2 hoặc sau khung Yêu cầu Trình đọc trong tập tin JPX), tại đó nó có thể dễ dàng được tìm thấy bởi các trình đọc tập tin. Để giảm thiểu sự di chuyển của các khung tập tin, việc bổ sung khung này và tùy chọn thêm mã ‘jpip’ vào danh sách tương thích trong các khung Loại Tập tin, khung Free (quy định tại Phụ lục M.11.20 của tiêu chuẩn ISO / IEC 15444-2) có thể được sử dụng như một khung Chờ trong tập tin yet-to-be-indexed.

Phụ lục J

(Quy định)

Hồ sơ và các biến thể cho khả năng tương tác và thử nghiệm

J.1 Tổng quan

Phụ lục này cung cấp khung chương trình, khái niệm và phương pháp luận để thiết lập khả năng tương tác, và các tiêu chí phải đạt được để khẳng định tuân thủ tiêu chuẩn ISO / IEC 15444-9. Phụ lục này cũng cung cấp một phương pháp để kiểm tra sự tuân thủ tập hồ sơ và biến thể được xác định. Mục tiêu của tiêu chuẩn hóa trong trường này là để thúc đẩy khả năng tương tác giữa các máy chủ và máy khách JPIP cho phép thử nghiệm trên các hệ thống cho phù hợp với tiêu chuẩn này.

Phụ lục này cũng xác định các hồ sơ và biến thể. Hồ sơ xác định các trường mà máy chủ JPIP dự kiến sẽ thực hiện và hỗ trợ phân tích cú pháp và giải thích; hồ sơ cũng hạn chế các yêu cầu máy khách có thể dự kiến máy chủ trong hồ sơ này để hỗ trợ và thực hiện đầy đủ. Các máy khách thực hiện yêu cầu trong hồ sơ nhận được mã lỗi 501 (“Không được triển khai”, xem Phụ lục D) hoặc 400 (“Yêu cầu bị lỗi”) có thể sử dụng điều này như một dấu hiệu cho thấy máy chủ không thực hiện đầy đủ hồ sơ và có thể dự phòng các yêu cầu cho hồ sơ mức thấp hơn. Các biến thể xác định những đặc điểm của tiêu chuẩn JPIP được sử dụng để yêu cầu và truyền tải dữ liệu giữa máy khách và máy chủ. Hồ sơ và biến thể là trực giao với nhau. Các máy chủ được phân loại theo hồ sơ tại mức cao nhất chúng hỗ trợ, và tất cả các biến thể mà chúng thực hiện. Máy khách được phân loại theo tất cả các biến thể mà chúng thực hiện, và theo hồ sơ mức cao nhất chúng có thể làm việc.

CHÚ THÍCH: Mặc dù thông qua các thủ tục kiểm tra, hồ sơ và biến thể trong phụ lục này được xác định cho ảnh mã hóa trong một số phần của họ tiêu chuẩn JPEG 2000 (Tiêu chuẩn ISO / IEC 15444-1) và một tập tính năng giới hạn của JPIP được thử nghiệm, điều này không có nghĩa là các máy chủ hoặc máy khách sử dụng phương thức JPIP để cung cấp hình ảnh ở các định dạng khác hoặc bằng phương thức khác JPIP không được liệt kê ở đây. Nó chỉ có nghĩa rằng việc tuân thủ của chúng không được định nghĩa trong phạm vi của phụ lục này, và hiện không khuyến nghị chính sách kiểm tra và phân loại cho chúng.

J.1.1 Hồ sơ

Hồ sơ xác định các yêu cầu mà máy chủ được dự kiến để hỗ trợ, yêu cầu máy khách có thể đợi để được hỗ trợ và thực hiện đầy đủ bởi các máy chủ. Yêu cầu quy định trong hồ sơ mức thấp hơn cũng được hỗ trợ và thực hiện đầy đủ trong hồ sơ mức cao hơn. Các hồ sơ được quy định chi tiết trong J.3.

J.1.2 Biến thể

Biến thể xác định cách thức áp dụng tiêu chuẩn JPIP cho máy khách và máy chủ để truyền dữ liệu. Máy khách và máy chủ phải cung cấp một tập con của các biến thể phổ biến để tương thích. Các biến thể được định nghĩa trong J.2.

J.2 Định nghĩa biến thể

JPIP cho phép ba kiểu trả về ảnh khác nhau, đối với yêu cầu truyền thông theo phiên hoặc phi trạng thái và đối với việc trao đổi dữ liệu đặc tả hoặc dữ liệu dòng mã giữa máy chủ và máy khách. Các biến thể phân loại máy khách và máy chủ trong một không gian 3 chiều dựa trên:

1) Kiểu trả về hình ảnh mà chúng hỗ trợ;

2) Dù máy khách yêu cầu và máy chủ thực hiện mô hình bộ nhớ đệm liên tục cho các yêu cầu trong phiên hoặc truyền thông là phi trạng thái hay không (xem B.1);

3) Dù dữ liệu được truyền bao gồm các dòng mã hoặc dữ liệu đặc tả được mã hóa trong các khung của định dạng tập tin.

Để phân loại máy khách hoặc máy chủ, các biến thể thực hiện theo từng trục xác định. Khả năng tương tác của cặp máy khách – máy chủ đòi hỏi hoạt động theo một tập con của các biến thể phổ biến. Không giống như các hồ sơ được sắp xếp theo độ phức tạp, các phiên bản không tạo thành một hệ thống tính năng phân cấp.

J.2.1 Biến thể kiểu trả về ảnh (P, T hoặc R)

Tham số này xác định kiểu trả về ảnh mà máy chủ có thể cung cấp và máy khách có thể hiểu được. Các máy chủ trong biến thể P có thể cung cấp dòng JPP; các máy chủ trong các biến thể T có thể cung cấp dòng JPT; các máy chủ trong các biến thể R có thể cung cấp các kiểu trả về ảnh “thô”. Các máy khách trong biến thể P chấp nhận dòng JPP, các máy khách trong biến T chấp nhận dòng JPT và các máy khách trong biến thể R chấp nhận ảnh thô. Biến thể P, T và R không loại trừ lẫn nhau; các máy chủ hoặc máy khách có thể hỗ trợ một vài biến thể.

J.2.2 Biến thể mô hình trạng thái (N hoặc S)

Tham số này xác định liệu máy chủ có thể sử dụng các kênh để truyền thông hay không. Một máy chủ trong biến thể S có thể cấp một kênh để đáp ứng với yêu cầu Kênh Mới (xem C.3.3) và duy trì một mô hình bộ nhớ đệm liên tục giữa các yêu cầu trong kênh. Một máy chủ trong biến thể N có khả năng đáp ứng yêu cầu không liên quan đến trường yêu cầu kênh mới hoặc ID Kênh.

Máy khách hoạt động trong biến thể S được yêu cầu lưu đệm dữ liệu giữa các yêu cầu trong cùng một phiên để lặp lại dữ liệu yêu cầu từ một máy chủ; đối với truyền thông liên tục hiệu quả, máy khách trong biến thể N cần phải sử dụng các yêu cầu thao tác mô hình bộ nhớ đệm. Các biến thể S và N không loại trừ lẫn nhau, và các máy chủ và máy khách có thể hỗ trợ cả hai biến thể.

J.2.3 Biến thể dòng bit (M hoặc C)

Tham số này xác định các loại địa chỉ logic các máy chủ có khả năng phục vụ. Các máy chủ hoạt động trong biến thể M có thể cung cấp nội dung khung ban đầu của định dạng tập tin JPEG 2000 như là ngăn dữ liệu đặc tả. Các máy chủ trong biến thể C có thể cung cấp dữ liệu chứa trong dòng mã sử dụng biểu diễn dòng mã tăng dần. Máy chủ trong biến thể C sẽ cung cấp ít nhất là ngăn dữ liệu đặc tả # 0 (xem A.3.6), mặc dù ngăn này sẽ trống đối với địa chỉ logic chỉ bao gồm dòng mã. Máy khách trong biến thể C chấp nhận tối thiểu biểu diễn dòng mã tăng dần của các dữ liệu ảnh; máy khách trong biến thể M chấp nhận ít nhất là ngăn dữ liệu đặc tả. Các biến thể M và C không loại trừ lẫn nhau, và các máy chủ và máy khách có thể hỗ trợ cả hai biến thể.

CHÚ THÍCH: Máy chủ hoặc máy khách chỉ có thể là biến thể M, trong trường hợp đó chúng chỉ có thể trả về hoặc chấp nhận ngăn dữ liệu đặc tả, nhưng không có ngăn dữ liệu phân khu ảnh hoặc khối ảnh. Đây là loại máy chủ hữu ích để nhanh chóng quét các dữ liệu đặc tả hình ảnh trong một cơ sở dữ liệu hình ảnh. Máy khách trong biến thể M (và không có trong C) nên bao gồm ” meta:orig“ trong trường tham chiếu máy khách để hạn chế đáp ứng ngăn dữ liệu đặc tả. Máy khách trong biến thể C (và không có trong M) có thể sử dụng ” src-codestream-specs“ của trường “subtarget” để cho biết các máy chủ xây dựng địa chỉ logic chỉ bao gồm dòng mã s, xem C.2.3.

Bảng J.1 – Định nghĩa yêu cầu các biến thể

Biến thể	Yêu cầu máy chủ	Yêu cầu máy khách	Nhận xét
P	Phải thực hiện kiểu trả về ảnh “jpp-stream”	Phải có khả năng phân tích cú pháp jpp-streams	P, T và R là không loại trừ lẫn nhau. Máy khách và máy chủ có thể thực hiện một vài biến thể.
T	Phải thực hiện kiểu trả về ảnh “jpt-stream”	Phải có khả năng phân tích cú pháp jpt-streams
R	Phải kiểu trả về ảnh “thô”	Phải có khả năng xử lý dữ liệu đến thô
N	Phải thực hiện yêu cầu thao tác mô hình bộ nhớ đệm tường minh bổ sung sử dụng đầy đủ byte từ hồ sơ 1 trở lên.		Các biến thể N và S là không loại trừ lẫn nhau. Máy khách hoặc máy chủ có thể thực hiện cả hai.
S	Phải thực hiện đầy đủ các trường cnew, cclose và cid. Phải thực hiện mô hình bộ nhớ đệm liên tục.	Phải tạo ra trường cnew để thiết lập phiên. Phải có khả năng lưu đệm dữ liệu giữa các yêu cầu.
C	Phải có khả năng truyền dữ liệu hình ảnh trong biểu diễn dòng mã tăng dần. Chịu trách nhiệm thực hiện hành vi client-preferences “meta:incr”.	Phải có khả năng phân tích cú pháp biểu diễn dòng mà tăng dần	Các biến thể M và C là không loại trừ lẫn nhau. Máy chủ hoặc máy khách có thể thực hiện nhiều hơn một biến thể cùng một lúc. Đối với truyền thông hiệu quả, máy chủ thực hiện C trong trường hợp đầu tiên, bổ sung bởi M. Máy chủ hoạt động tại M (và không phải C) có thể không có khả năng đáp ứng một cách hiệu quả để giới hạn yêu cầu cửa sổ hiển thị theo các dòng mã được lựa chọn. Máy khách quan tâm đến việc lấy dữ liệu hình ảnh tối thiểu ở biến thể C.
M	Phải có khả năng truyền dữ liệu đặc tả và dữ liệu hình ảnh trên các khung. Phải thực hiện các trường metareq từ hồ sơ 1 trở lên. Chịu trách nhiệm thực hiện hành vi client- preferences “meta:orig“.	Phải có khả năng phân tích cú pháp ngăn dữ liệu đặc tả, bao gồm dữ liệu ảnh mã hóa trong các khung dòng mã JPEG 2000 và khung Chờ.

J.3 Định nghĩa hồ sơ

Các hồ sơ xác định tập các trường yêu cầu một máy chủ dự kiến sẽ thực hiện và hỗ trợ. Tổng quan về các trường yêu cầu trên hồ sơ được đưa ra trong Bảng I.2. Nói chung, hồ sơ mức cao hơn đòi hỏi máy chủ hỗ trợ công nghệ tiên tiến hơn cho tiêu chuẩn. Máy khách tạo ra các yêu cầu từ hồ sơ mức thấp hơn có thể đợi các đáp ứng thỏa mãn yêu cầu từ một máy chủ thuộc về hồ sơ tương đương hoặc cao hơn.

Các hồ sơ cung cấp một cơ chế cho máy khách thích ứng với các yêu cầu của chúng với năng lực của máy chủ. Để điều này thành công, các máy chủ phải cung cấp đầy đủ dấu hiệu của việc không thể thực hiện yêu cầu cụ thể trong hồ sơ. Sau khi phát hiện ra rằng máy chủ không thể thỏa mãn yêu cầu cụ thể trong hồ sơ, một kế hoạch hợp lý cho máy khách sẽ hạn chế các yêu cầu trong tương lai tại hồ sơ mức thấp hơn. Máy chủ cho thấy không có khả năng để đáp ứng yêu cầu cụ thể được đưa ra bởi các máy khách cách hoặc phát hành một mã trả về lỗi được áp dụng ở đây, hoặc bằng cách thay đổi các yêu cầu và phát hành các tiêu đề đáp ứng JPIP thích hợp (xem phụ lục D).

J.3.1 Hồ sơ 0: “Truyền thông cơ bản”

Hồ sơ này cung cấp một cơ chế truyền thông cơ bản cho yêu cầu của máy khách và đáp ứng của máy chủ. Chỉ hỗ trợ các hoạt động cơ bản trên dòng mã hoặc tập tin quy định tại JPEG 2000 Phần 1. Điều này bao gồm việc cung cấp vùng ảnh hoặc toàn bộ hình ảnh phù hợp với kích thước cửa sổ hiển thị cụ thể. Thao tác bộ nhớ đệm không cho phép trên dòng yêu cầu đối với hồ sơ 0. Các trường mà máy chủ dự kiến để hỗ trợ trong hồ sơ 0 là:

Đích, loại, đích id, kích thước khung hình, độ lệch vùng, kích thước vùng, len, pref (có giới hạn), (tất cả các biến thể) cid, cnew, cclose (trong biến thể S)

Máy khách phải có khả năng phân tích cú pháp dữ liệu trả về bởi máy chủ và được yêu cầu xử lý kiểu trả về ảnh JPP, JPT hoặc thô phù hợp với các biến thể của chúng. Máy chủ không thể dự kiến sẽ ưu tiên yêu cầu đối với ngăn dữ liệu phân khu ảnh và khối ảnh mở rộng, nghĩa là trường “ptype” hoặc “ttype” quy định tại Bảng C.4, Điều C.7.3. Máy khách phù hợp phải chấp nhận bản tin không đồng bộ; máy chủ không ưu tiên yêu cầu “align”.client-preference-pref mà máy chủ cần để đáp ứng trong hồ sơ này là “concise”, xem C.10.2.8, và “fullwindow”, xem C.10.2.2. Các máy chủ trong hồ sơ 0 biến thẻ S phải thực hiện trường cid, cnew và cclose, nhưng chỉ cần hỗ trợ một kênh duy nhất cho mỗi phiên.

J.3.2 Hồ sơ 1: “Truyền thông nâng cao”

Hồ sơ 1 mở rộng hồ sơ 0 bằng cách đòi hỏi máy chủ hỗ trợ các yêu cầu thao tác mô hình bộ nhớ đệm, và yêu cầu có thể bị giới hạn bởi các lớp hoặc thành phần ảnh. Tùy thuộc vào biến thể hồ sơ, mô hình bộ nhớ đệm hoặc truyền thông tường minh với máy chủ bằng yêu cầu mô hình bộ nhớ đệm trong biến thể N hoặc ngầm đợi để được thực hiện bởi máy chủ trong biến thể S. Hồ sơ 1 cũng mở rộng hồ sơ 0 từ 0 bao gồm các trường bổ sung sau đây:

Thành phần, lớp, đợi, mô hình (với những hạn chế, xem văn bản),	(tất cả các biến thể)
metareq	(trong biến thể M)

Hồ sơ 1 của các máy chủ cũng được chờ để xử lý các yêu cầu thao tác mô hình bộ nhớ đệm thêm vào với địa chỉ ngăn và số lượng byte rõ ràng, tức là, các trường mô hình sử dụng mô tả ngăn tường minh theo quy định tại Điều C.8.1.2. Như trong hồ sơ 0, máy chủ trong hồ sơ 1 biến thể S sẽ thực hiện các trường cid, cnew, cclose, nhưng chỉ có một kênh duy nhất cho mỗi phiên cần được hỗ trợ. Các máy chủ trong hồ sơ 1 biến thể M phải thực hiện bổ sung trường metareq.

J.3.3 Hồ sơ đầy đủ

Hồ sơ đầy đủ cung cấp khả năng vượt ngoài các hồ sơ mức thấp hơn theo quy định tại tiêu chuẩn này

Bảng J.2 – Tập các trường thuộc hồ sơ

Hồ sơ		0: Truyền thông cơ bản	1: Truyền thông nâng cao	Hồ sơ đầy đủ
Trường hỗ trợ máy chủ	target	có	có	có
	subtarget			có
	fsiz	có	có	có
	roff	có	có	có
	rsiz	có	có	có
	comps		có	có
	layers		có	có
	len	có	có	có
	tid	có	có	có
	metareq		có	có
	ptype=ext, ttype=ext			có
	Đồng bộ			có
Đa kênh	cnew	có (chỉ trên một phiên)	có (chỉ trên một phiên)	có
	cid	có (chỉ một trên phiên)	có (chỉ một trên phiên)	có
	cclose	có	yes	có
Làm rỗng từ trước	wait		yes	có
	qid			có
	stream			có
	context			có
	Implicit model			có
	tpmodel			có
	mset			có
Quản lý Bộ nhớ đệm	model		Hiển thị, đếm byte counts và chỉ thêm vào	Tất cả
Trường yêu cầu điều khiển máy chủ	align			có
Trường yêu cầu điều khiển máy chủ	type	jpp-stream jpt-stream raw	jpp-stream jpt-stream raw	Tất cả
Tham chiếu máy khách	pref	concise fullwindow	concise fullwindow	Tất cả

J.4 Phương pháp luận thử nghiệm

Thử nghiêm khả năng tương tác JPIP được thực hiện tại mức ngăn, chẳng hạn trong dữ liệu truyền từ máy chủ tới máy khách. Điều này cung cấp tập ảnh mẫu và yêu cầu JPIP mẫu theo tiêu chuẩn ISO / IEC 15444-1, cùng các với các tiêu đề và dữ liệu đáp ứng mẫu tương thích từ máy chủ. Dữ liệu đáp ứng từ máy chủ dưới dạng tập tin JPP và tập tin JPT, được mô tả trong Điều A.5.

J.4.1 Quy ước máy chủ cần thiết để thử nghiệm

Tất cả các dòng mẫu được tạo ra với tham chiếu máy khách conciseness-pref thiết lập là “concise” và view-window-pref thiết lập là “fullwindow”. Nguồn tài nguyên hạn chế tại máy chủ có thể yêu cầu máy chủ thực tế thực hiện để hạn chế yêu cầu đòi hỏi quá nhiều dữ liệu từ máy chủ cùng một lúc. Các dữ liệu mẫu được cung cấp trong điều này không kích hoạt các điều kiện như vậy cho việc triển khai nhắm đánh địa chỉ cho máy bàn state-of-the-art. Nếu máy chủ thực hiện bao gồm các phương thức để hạn chế yêu cầu để hạn chế nguồn tài nguyên cần thiết để thực hiện kiểm thử, loại này phải được vô hiệu hóa đối với mục đích đo kiểm tuân thủ. Điều này không giới thiệu giới hạn nguồn tài nguyên mà máy chủ phải có khả năng hoạt động.

J.4.2 Thử nghiệm máy chủ

Thử nghiệm máy chủ là việc kết hợp biến thể và hồ sơ cho trước. Thử nghiệm một máy chủ JPIP được thực hiện bằng cách khởi tạo yêu cầu JPIP cho dữ liệu từ ảnh mẫu và so sánh các dữ liệu lấy từ các máy chủ trong thử nghiệm với những đáp ứng mẫu theo các biến thể và hồ sơ sử dụng thuật toán được mô tả trong Điều J.4.3. Để khẳng định sự phù hợp với hồ sơ và biến thể cụ thể, máy chủ sẽ vượt qua tất cả các bài đo kiểm máy chủ đối với hồ sơ này và tất cả các hồ sơ mức thấp hơn bằng cách sử dụng biến thể quy định.

Mặc dù các máy chủ JPIP được phép thay đổi những gì chúng cung cấp, các dòng mẫu sẽ không được sửa đổi bởi máy chủ trong quá trình thử nghiệm.

CHÚ THÍCH 1: Các dòng mẫu cho kiểu trả về ảnh JPP được tạo ra theo cách mà mỗi phân khu ảnh của dòng mẫu chỉ bao gồm một khối mã trong mỗi băng con. Vì vậy không cần thiết quá trình chuyển mã bất kỳ, mặc dù cho phép chèn thêm hoặc loại bỏ các nhãn COM, PLT, PLM và TLM trong ngữ cảnh của thủ tục đo kiểm này.

Đối với mục đích thử nghiệm, dữ liệu JPIP mà máy chủ sẽ gửi qua mạng phải được lưu lại dưới định dạng tập tin JPP hoặc tập tin JPT thích hợp. Bất kỳ một đóng gói nào như các mã đáp ứng HTTP phải bị loại bỏ khỏi những tập tin này.

Các mã EOR chỉ định các thông tin phải nằm trong trong các tập tin. Nội dung của những tập tin này sau đó được so sánh với nội dung của các đáp ứng mẫu. Đáp ứng được trả về bởi máy chủ phù hợp, tuy nhiên, khác với đáp ứng mẫu.

CHÚ THÍCH 2: Trên thủ tục đo kiểm quy định tại Điều l.4.3, cho phép sự khác biệt so với các dòng mẫu như sau:

– Sắp xếp lại các ngăn dữ liệu trong đáp ứng.

– Đặt lại các nội dung của các khung dữ liệu đặc tả vào khung Chờ.

– Sử dụng quá trình mã hóa tương đương với các tiêu đề VBAS của ngăn dữ liệu.

– Sử dụng các phương pháp phân nhỏ dữ liệu đặc tả vào các ngăn chờ, cung cấp các dữ liệu đặc tả yêu cầu nằm trong các đáp ứng.

– Sử dụng biểu diễn tương đương dòng cho dữ liệu đặc tả.

Khái niệm quy định sự khác nhau giữa các dòng có thể chấp nhận được mặc nhiên được đưa ra bởi các thủ tục đo kiểm trong Điều J.4.3.

CHÚ THÍCH 3: Công cụ đo kiểm (“vbasdiff.py“) được cung cấp để thực hiện, thủ tục đo kiểm và phân tích sự khác biệt giữa hai đáp ứng máy chủ.

CHÚ THÍCH 4: Các máy chủ có thể cung cấp thêm các biểu diễn tương đương dòng. Tuy nhiên, việc xác định tính đúng đắn của chủng nằm ngoài phạm vi của phụ lục này; chúng được bỏ qua trong phương pháp luận thử nghiệm quy định tại Điều I.4. Hơn nữa, đo kiểm tuân thủ đối với JPlP áp dụng cho dữ liệu đòi hỏi phải các giá trị cờ của khung chờ khác, ví dụ như sử dụng trong tiêu chuẩn ISO / IEC 15444-3, nằm ngoài phạm vi của phụ lục

J.4.3 Đáp ứng máy chủ So sánh

Điều này xác định một thuật toán quy định so sánh các dữ liệu đáp ứng của máy chủ trong thử nghiệm với những đáp ứng mẫu được cung cấp bởi tiêu chuẩn này.

CHÚ THÍCH: Bao gồm tập dòng thử nghiệm là một tập lệnh thử nghiệm python (“vbasdiff.py”) để thực hiện so sánh triển khai giải thuật được mô tả sau đây: Bản chất của thử nghiệm phụ thuộc vào sự tồn tại của trường độ dài. Nếu trường len có mặt trong yêu cầu, chỉ thử nghiệm với kích thước đáp ứng máy chủ và mã EOR. Nếu không, thực hiện bốn bước sau đây:

1) Phân tích cú pháp các bản tin trong tập tin jpp hoặc jpt, kiểm tra quá trình mã hóa và gán chúng vào các ngăn.

2) Đưa các ngăn dữ liệu đặc tả vào dạng chính tắc theo quy định tại Điều J.4.3.3.

3) Đo lượng dữ liệu dư thừa.

4) So sánh các phần của dữ liệu dư thừa với một ngưỡng.

J.4.3.1 So sánh kích thước đáp ứng máy chủ

Trong trường hợp yêu cầu bao gồm trường len, so sánh độ dài tính bằng byte của đáp ứng máy chủ không bao gồm bản tin EOR bất kỳ với độ dài yêu cầu. Nếu theo kích thước tính bằng byte của đầu ra này là lớn hơn độ dài yêu cầu, so sánh bị lỗi. Nếu không có dữ liệu (ngoại trừ EOR) bị trả về, so sánh bị lỗi. Thì so sánh các mã EOR của dòng thử nghiệm với mã EOR của dòng mẫu. Nếu mã EOR của dòng thử nghiệm không phải là 1 (“Image Done”) cũng không phải là 2 (“Window Done”), xem Bảng D.2) cũng không bằng mã EOR của dòng mẫu, so sánh bị lỗi. Nội dung bản tin EOR sẽ bị bỏ qua.

CHÚ THÍCH: Các dòng mẫu chứa các yêu cầu tương tự có và không có trường len.

J.4.3.2 Bước phân tích cú pháp

Đối với yêu cầu kiểm tra không bao gồm trường len, dữ liệu thử nghiệm và mẫu được phân tích. Các tiêu đề bản tin VBAS phải được giải mã, ban đầu tách bản tin EOR từ các bản tin thông thường, và đối với các bản tin thông thường, nhận diện định danh lớp trong, lớp bản tin, số thứ tự dòng mã (CSN), “bit bản tin cuối cùng” (bit 4, dán nhãn Để“c” trong Hình A.3), giá trị AUX, nếu có, độ lệch và độ dài bản tin. Sau đó nội dung bản tin sẽ được đưa vào ngăn dữ liệu tùy theo trường độ lệch và độ dài bản tin trong tiêu đề bản tin, trong đó mỗi ngăn được xác định bởi bộ ba tham số lớp ngăn, định danh lớp trong và số thứ tự dòng mã. Ánh xạ giữa lớp bản tin và lớp ngăn được đưa ra trong Bảng A.2, Phụ lục A. Nó sẽ được chấp nhận nếu bản tin thay thế phần dữ liệu cung cấp bởi bản tin cũ, nhưng nó không được chấp nhận cung cấp dữ liệu cho làm phình to ngăn xếp khi bản tin cuối cùng đã nhận được.

Đầu tiên, các mã EOR được so sánh. Nếu mã EOR của dòng thử nghiệm không phải là 1 (“Image Done”) mà cũng không phải là 2 (“Window Done”, xem Bảng D.2) cũng không bằng mã EOR của dòng mẫu, so sánh bị lỗi. Phần thân của bản tin EOR bị bỏ qua.

Giá trị AUX hoặc được bao gồm trong tất cả các bản tin tập trung trong ngăn dữ liệu, hoặc không có. Nếu không, các tập tin bị hỏng và so sánh bị lỗi. Đối với mỗi ngăn dữ liệu có chứa các bản tin với các giá trị AUX, các giải thuật sau đây được sử dụng để chỉ định một giá trị AUX cho ngăn dữ liệu:

– Đối với ngăn dữ liệu phân khu ảnh, giá trị AUX của ngăn phải là giá trị AUX lớn nhất được tìm thấy trong tất cả các bản tin tập trung trong ngăn.

– Đối với ngăn dữ liệu khối ảnh, giá trị AUX của ngăn phải là giá trị AUX nhỏ nhất được tìm thấy trong tất cả các bản tin tập trung trong ngăn.

Chú thích: Bản tin chứa các giá trị AUX không xuất hiện trong thử nghiệm với hồ sơ 0 và 1.

J.4.3.3 Tóm tắt cách bố trí ngăn dữ liệu đặc tả

Trong bước tiếp theo, ngăn dữ liệu đặc tả được đưa vào dưới dạng chính tắc để tóm tắt một cách máy chủ cụ thể chia nhỏ dữ liệu đặc tả thành các khung Chờ. Các bản tin tập trung trong ngăn dữ liệu có thể không chỉ ra tất cả dữ liệu của nó, điều này xảy ra với bản tin ngăn dữ liệu được định từng phần và chấp nhận các ngăn dữ liệu đặc tả bao gồm “holes” của dữ liệu bị mất được định vị lại theo cơ chế khung chờ. Các vùng như vậy được gọi là “missing bytes” như sau.

Các tập lệnh kiểm tra thực hiện các thuật toán sau đây để tái tạo lại dữ liệu trung gian từ tập tin jpp hoặc jpt:

– Ngăn dữ liệu đặc tả # 0 được quét trong dòng kiểm tra đối với tiêu đề khung không đầy đủ. Các dòng thử nghiệm và mẫu thực hiện so sánh bằng cách đánh dấu các phạm vi tương ứng với dữ liệu bị mất trong cả hai dòng. Các dòng sửa đổi kiểm tra các khung Chờ. Nếu các giá trị cờ của khung chờ có tập LSB, chỉ ra rằng OriglD hợp lệ, khung chờ sẽ được xử lý như trong các bước tiếp theo; nếu không, nó sẽ vẫn nguyên bản:

• Nếu ngăn dữ liệu tham chiếu bởi khung chờ nằm trong dòng, thì khung sẽ được thay thế bằng tiêu đề khung và nội dung ngăn tham chiếu bên trong.

• Nếu ngăn dữ liệu tham chiếu, trong khung chờ không nằm trong dòng, khung chờ sẽ được gỡ bỏ, tiêu đề khung trong khung chờ sẽ được chèn vào trong dòng, và trong dãy byte trong ngăn địa chỉ bị mất sẽ được đánh dấu là dữ liệu bị mất.

– Sau khi ngăn dữ liệu đặc tả # 0 của dòng thử nghiệm và mẫu đã được phân tích như trên, tất cả các ngăn dữ liệu đặc tả khác ngăn # 0 còn lại được lấy ra khỏi dòng.

CHÚ THÍCH: Các thuật toán trên yêu cầu các phần mềm thực hiện so sánh chứa cơ sở dữ liệu mô tả các khung là siêu khung và là các khung đơn giản. Điều này cần thiết để có thể quét nội dung siêu khung một cách chính xác đối với các khung chờ. Trong quá trình kiểm tra, đó là lợi thế không bao gồm dữ liệu dư thừa trong các đáp ứng. Các máy chủ nên sử dụng khung chờ phù hợp để tránh dữ liệu dư thừa. Đối với hồ sơ 1 và cao hơn, mọi siêu khung được thay thế bằng một khung chờ trong dòng mẫu. Dòng mẫu đối với hồ sơ 0 được tạo ra mà không cần khung chờ và chỉ có số lượng dữ liệu đặc tả tối thiểu, theo quy định tại Điều C.5, sẽ được đưa ra.

J.4.3.4 So sánh ngăn dữ liệu

Trong bước thứ ba, tất cả ngăn dữ liệu còn lại phải được so sánh, định vị cho mỗi giá trị bin-class, bin-Id và CSn trong một dòng tương ứng ngăn trong dòng thứ hai: một ngăn dữ liệu có mặt trong dòng thử nghiệm khi và chỉ khi nó có mặt trong dòng mẫu; nếu không, so sánh bị lỗi.

Các ngăn dữ liệu được so sánh như sau:

– Nếu một trong số các ngăn dữ liệu mang giá trị AUX, thì các ngăn cũng khác phải mang giá trị AUX. Nếu cả hai ngăn mang giá trị AUX, thì chúng phải bằng nhau; nếu không, so sánh bị lỗi. Xem I.4.3.1 về cách tính toán giá trị AUX của một ngăn từ giá trị AUX trong các bản tin tập trung trong ngăn.

– Nếu ngăn dữ liệu mẫu chứa bản tin chỉ ra rằng byte “cuối cùng” của ngăn đã được kết hợp, các ngăn dữ liệu tương ứng trong dòng đang thử nghiệm cũng phải chứa một bản tin với cùng chỉ mục. Nếu không, việc so sánh bị lỗi.

– Đối với tất cả các loại ngăn ngoại trừ ngăn dữ liệu tiêu đề chính và ngăn dữ liệu tiêu đề khối ảnh, tất cả các byte được định nghĩa trong ngăn dữ liệu được so sánh phải bằng nhau. Nếu không, việc so sánh bị lỗi. Số byte dư thừa trong dòng thử nghiệm nhưng không phải trong trong dòng mẫu sẽ được gộp lại.

– Các ngăn dữ liệu tiêu đề chính và ngăn dữ liệu tiêu đề khối ảnh được so sánh bằng cách phân tích chúng thành các đoạn nhãn và so sánh các đoạn nhãn độc lập theo thứ tự. Tất cả các đoạn nhãn ngoại trừ COM, PLT, PLM và TLM phải bằng nhau.

Sau khi so sánh tất cả ngăn dữ liệu, lượng byte dư thừa Ne đo được trong bước ba này sẽ được chia cho tổng số byte trong các ngăn Nt. Nếu thương số này cao hơn ngưỡng T, so sánh bị lỗi. Đối với yêu cầu mẫu và mẫu đáp ứng hiện có đang được xác định trong tiêu chuẩn này, ngưỡng T bằng không.

CHÚ THÍCH: Để kiểm tra tuân thủ của các máy chủ theo quy định tại phụ lục này, các máy chủ sẽ hoạt động phù hợp với các điều ngắn gọn về các trường pref, xem C.10.2.8. Các máy chủ không hoạt động theo cách này vẫn có thể được tuân thủ theo tiêu chuẩn này, nhưng thử nghiệm của chúng là nằm ngoài phạm vi của phụ lục này.

J.4.4 Thử nghiệm máy khách

Thử nghiệm máy khách cụ thể cho một biến thể cho trước. Tuân thủ của các máy khách sẽ được kiểm tra bằng cách cung cấp một tiêu đề đáp ứng mẫu và tập tin jpp hoặc jpt cho biến thể và hồ sơ cụ thể để tiến thành đo thử nghiệm. Máy khách xử lý đáp ứng này. Đối với mục đích của thử nghiệm, máy khách sẽ tạo ra các tập tin hoặc dòng mã tương thích với tiêu chuẩn ISO / IEC 15444-1. Tính năng này không yêu cầu bắt buộc đối với một máy khách phải tuân thủ, nhưng nó được yêu cầu để thực hiện thử nghiệm. Việc tạo ra các dòng mã hoặc tập tin sẽ được so sánh với dòng mã hoặc tập tin mẫu được cung cấp tại điều này bằng cách sử dụng thuật toán xác định sau đây. Để khẳng định sự phù hợp với biến thể, máy khách phải vượt qua tất cả các bài đo kiểm đối với biến thể nhất định.

So sánh các dòng mẫu với các dòng được tạo ra bởi máy khách được thực hiện trong hai giai đoạn: ban đầu so sánh dữ liệu đặc tả (nếu nó) hiện có, sau đó so sánh các dữ liệu hình ảnh có sẵn.

CHÚ THÍCH: Thủ tục kiểm tra máy khách được mô tả ở đây chỉ để kiểm tra khả năng của máy khách phân tích thành công các dòng JPP hoặc JPT, và tái tạo tập tin phù hợp JPEG 2000 hoặc dòng mã từ dữ liệu đó. Nó không kiểm tra khả năng của máy khách tạo ra các yêu cầu hoặc khai thác các khả năng khác được cung cấp trong tiêu chuẩn này.

J.4.4.1 So sánh dữ liệu đặc tả

Nếu địa chỉ được được mã hóa trong định dạng tập tin JPEG 2000, các nội dung của khung tập tin mẫu và nội dung của các khung ngoại trừ khung dòng mã được tạo ra bởi thử nghiệm được so sánh. Tuy nhiên máy khách cho phép thực hiện các sửa đổi sau đây:

– Chứa các khung UUID bổ sung không có mặt trong dòng mẫu.

– Sắp xếp lại các khung, cung cấp các khung không làm thay đổi ngữ nghĩa của tập tin.

Bao gồm các sửa đổi, nội dung khung của dòng thử nghiệm và dòng mẫu phải giống hệt nhau. Nếu không, việc so sánh bị lỗi.

J.4.4.2 So sánh dữ liệu ảnh phục dựng

Nếu yêu cầu được sử dụng để tạo ra tập tin jpp hoặc jpt mẫu bao gồm trường yêu cầu đối với cửa sổ hiển thị không rỗng, các dữ liệu ảnh phục dựng lại phải được so sánh. Các dòng và dòng mã mẫu tạo ra bởi máy khách thực hiện đều được giải mã bởi bộ giải mã thích hợp JPEG 2000. Việc thực hiện tương tự được sử dụng cho cả hai dòng. Ảnh kết quả phải giống hệt nhau đến từng điểm ảnh trong cửa sổ hiển thị của yêu cầu. So sánh trong giai đoạn này được thực hiện như sau:

– Đặt fx ‘= Xsiz-XOsiz và fy’ = Ysiz-YOsiz trong đó Xsiz, XOsiz và Ysiz, YOsiz được lấy từ các nhãn Siz của dòng mã có liên quan.

– Đặt ox, oy và sx, sy cho độ lệch và kích thước vùng của cửa sổ hiện thị được xác định trong yêu cầu, và đặt fx và fy là kích thước khung được xác định trong yêu cầu.

;

(J-1)

So sánh tất cả các điểm ảnh trong ảnh phục dựng hạn chế đến cửa sổ hiển thị góc trên cùng bên trái ox’ và oy’ và có kích thước sx’ và sy‘. Tất cả các điểm trong vùng này phải giống hệt nhau; nếu không, so sánh bị lỗi.

CHÚ THÍCH 1: Các thủ tục trên giống nhau, nhưng không giống với định nghĩa trong Công thức (C-1) và (C-2) Điều C.4. Sự khác biệt mức phân giải r trong công thức (C-1) ở đây được hạn chế bằng không, tuân theo sự so sánh tại độ phản giải ảnh đầy đủ.

CHÚ THÍCH 2: Công cụ (“jp2file.py”) được cung cấp trong tập tin điện tử đính kèm với tiêu chuẩn này mà tạo ra một văn bản đại diện cho nội dung của các tập tin JPEG 2000 hoặc dòng mã để dễ dàng phân tích các dữ liệu được tạo ra bởi các máy khách.

CHÚ THÍCH 3: Toàn bộ thủ tục kiểm tra các máy khách yêu cầu nhà cung cấp để triển khai bộ giải mã tương thích JPEG 2000, tuy nhiên, không cần phù hợp với tiêu chuẩn này. Khả năng máy khách tạo ra tập tin JPEG 2000 hoặc dòng mã cũng không bắt buộc phải tuân thủ tiêu chuẩn này 9 nhưng được yêu cầu để thực hiện các bài kiểm tra trong phụ lục này.

Phụ lục K

(Quy định)

Sử dụng JPIP với các yêu cầu HTTP và các khai báo UDP

K.1 Tổng quan

Phụ lục này cung cấp các chi tiết về truyền tải “http-udp”, được xác định trong tài liệu này như HTTP-UDP. Truyền tải HTTP-UDP sử dụng các cơ chế tương tự như việc truyền tải HTTP để gửi yêu cầu máy khách đến máy chủ và nhận được các tiêu đề đáp ứng và mã trạng thái của máy chủ. Tuy nhiên, dữ liệu đáp ứng của máy chủ được phân phối như là các gói tin UDP qua một kết nối UDP bổ trợ. Thông tin truyền tải trên kết nối UDP bổ trợ này được nhận diện phải được truyền đi như toàn bộ đáp ứng thuần HTTP, ngoại trừ việc nó được đóng khung thành nhiều khúc dữ liệu, mỗi khúc trong số đó có số thứ tự khúc dữ liệu và bản ghi của request-id kết hợp với các yêu cầu của máy khách tương ứng. Mỗi khúc dữ liệu phải chứa một số bản tin JPIP và tối đa một bản tin EOR như quy định tại Phụ lục A. Định dạng lớp bản tin và số thứ tự dòng mã phải xuất hiện ít nhất trong bản tin JPIP đầu tiên của mỗi khúc dữ liệu.

CHÚ THÍCH: Do truyền tải UDP không tin cậy (nghĩa là, các gói tin UDP có thể bị mất hoặc đến không theo thứ tự) máy khách có thể không nhận được tất cả khúc dữ liệu tương ứng với yêu cầu. Máy khách có thể sử dụng trường yêu cầu Bỏ qua dạng tường minh để thông báo cho máy chủ về tình trạng này, xem C.7.6.

K.2 Yêu cầu máy khách

Các yêu cầu được phân phối trên các kênh chính như các yêu cầu HTTP. Chúng có tính chính xác giống như các yêu cầu được phát hành qua kênh có sử dụng truyền tải HTTP được mô tả trong Phụ lục F. Cụ thể, cả hai yêu cầu HTTP “GET“ và “POST” có thể được sử dụng. Yêu cầu máy khách được phát trên kênh JPIP sử dụng truyền tải HTTP-UDP bao gồm trường yêu cầu Request-id (qid).

CHÚ THÍCH: Các máy khách cần phát các giá trị Request-id liên tiếp.

K.3 Cung cấp dữ liệu đáp ứng và thiết lập kênh

Một kênh mới có thể được thành lập cho máy chủ JPIP bằng cách phát một yêu cầu bao gồm các trường yêu cầu Kênh Mới (xem C.3.3). Đối với một mẫu, yêu cầu như vậy có thể được phát bằng cách sử dụng HTTP, mặc dù nó cũng có thể được phát cho một máy chủ JPIP cụ thể sử dụng cơ chế truyền tải bất kỳ phù hợp. Nếu đáp ứng của máy chủ (thông qua tiêu đề đáp ứng Kênh Mới trong Điều D.2.3) chỉ ra rằng một kênh mới đã được tạo ra để làm việc với truyền tải HTTP-UDP, yêu cầu bao gồm trường yêu cầu Kênh Mới được xử lý mặc dù nó được phát trong kênh truyền tải HTTP-UDP mới được tạo ra. Điều này đảm bảo rằng dữ liệu đáp ứng cho yêu cầu đó và tất cả các yêu cầu tiếp theo trong cùng một kênh được đóng khung vào các khúc dữ liệu và cung cấp như là các gói UDP. Dữ liệu đáp ứng này không thể để trống, cho đến khi mọi yêu cầu được phát trên kênh truyền tải HTTP-UDP có một dòng dữ liệu đáp ứng bao gồm ít nhất một bản tin EOR (xem D.3).

Đích đến của các gói tin đáp ứng được cung cấp tùy thuộc vào việc có hay không có yêu cầu kết hợp chứa một trường yêu cầu Gửi đi.

1) Đối với các yêu cầu có chứa trường yêu cầu Gửi đi, các gói dữ liệu được phát đến địa chỉ cụ thể mà không cần bất kỳ bản tin báo nhận nào từ máy khách.

2) Đối với các yêu cầu không chứa trường yêu cầu Gửi đi, các gói tin đáp ứng có thể không được phát đến khi một kết nối UDP bổ trợ được thiết lập. Để làm điều này, máy khách gửi một hoặc nhiều gói tin thiết lập kết nối đến máy chủ được xác định thông qua tiêu đề đáp ứng Kênh Mới, trên cổng được nhận diện bởi tiêu đề đáp ứng Kênh Mới. Mỗi gói tin thiết lập kết nối bắt đầu với tiêu đề bốn byte, theo sau bởi chuỗi ID Kênh kết hợp với kênh HTTP-UDP mới. Một khi máy chủ nhận được gói tin thiết lập kết nối với chuỗi ID Kênh chính xác, nó sẽ gửi tất cả các gói tin đáp ứng tiếp theo (trừ các gói tin liên quan đến trường yêu cầu Gửi Đi) đến địa chỉ IP và cổng mà gói tin thiết lập kênh đến và nó chờ để nhận được gói tin báo nhận từ địa chỉ IP và cổng của máy khách.

CHÚ THÍCH : Do UDP là truyền thông không tin cậy, nên gói tin thiết lập kết nối có thể bị mất. Vì lý do này, máy khách được chuẩn bị để gửi nhiều gói tin thiết lập kết nối nếu cần thiết, và các máy chủ phải được chuẩn bị để loại bỏ gói tin thiết lập kết nối không cần thiết nếu nó đến. Khi nhận được gói tin thiết lập kết nối hợp lệ, máy chủ có thể lựa chọn để lọc các gói tin đến như là một phần của một kế hoạch bảo vệ.

Hai byte đầu tiên của tiêu đề gói tin thiết lập kết nối là FF, trong khi các byte thứ ba và thứ tư nhận diện độ dài của chuỗi ID Kênh, ghi nhận một số 16-bit kiểu big endian. Tiêu đề bốn byte theo sau chuỗi ID Kênh, mã hóa theo các ký tự UTF-8. Nội dung bổ sung có thể được cung cấp, ngoài việc kết thúc của chuỗi ID Kênh, việc biên dịch nội dung như vậy là không được xác định trong tiêu chuẩn này.

K.4 Đáp ứng máy chủ

Trong đáp ứng với mỗi yêu cầu máy khách, máy chủ sẽ gửi trả lời lại một đoạn văn bản HTTP cho máy khách qua kênh chính. Đoạn văn bản trả lời có chứa mã trạng thái, mệnh đề lý do và tất cả các tiêu đề đáp ứng JPIP liên quan và các tiêu đề đáp ứng HTTP bất kỳ thích hợp. Tuy nhiên, không có dữ liệu đáp ứng được phản hồi thông qua kênh chính. Vì lý do này, sẽ không có phần thân thực thể HTTP trong đáp ứng HTTP-UDP. Tiêu đề đáp ứng HTTP hoặc không I sử dụng “Content-length:”:” hoặc không sử dụng “Transfer-encoding:”.

Bản thân dữ liệu đáp ứng được phân phối thông qua UDP, đóng khung thành nhiều khúc dữ liệu theo cách được mô tả trong J.5. Do truyền tải HTTP-UDP chỉ được sử dụng với các phiên, kiểu trả về ảnh bị hạn chế trong dòng JPP và dòng JPT theo quy định tại Phụ lục A. Do đó, dữ liệu đáp ứng luôn bao gồm các bản tin dòng JPP hoặc dòng JPT liên tục.

Kết quả dữ liệu đáp ứng từ mỗi yêu cầu sẽ bao gồm một số khúc dữ liệu, có nghĩa là không có khúc dữ liệu nào chứa dữ liệu đáp ứng được tạo ra để đáp ứng hai yêu cầu khác nhau.

Đáp ứng đối với mỗi và mọi yêu cầu sau đây mà một trong những kênh được yêu cầu, được kết thúc bằng bản tin EOR, ngay cả khi dữ liệu đáp ứng rỗng. Bản tin EOR được coi là một phần của dữ liệu đáp ứng.

Điều này có nghĩa rằng tất cả các yêu cầu đưa ra trên kênh JPIP truyền tải HTTP-UDP là kết quả của việc tạo ra của ít nhất một khúc dữ liệu đáp ứng không rỗng từ máy chủ và khúc dữ liệu cuối cùng được tạo ra để đáp ứng cho từng yêu cầu kết thúc với bản tin EOR.

K.5 Đóng khung dữ liệu đáp ứng vào khúc dữ liệu

Tất cả dữ liệu đáp ứng được gửi bởi máy chủ thông qua kết nối UDP bổ trợ được đóng khung thành các khúc dữ liệu. Mỗi khúc bao gồm một tiêu đề khúc 8-byte, tiếp theo là phần thân của khúc chứa dữ liệu đáp ứng của máy chủ, như trong Hình K.1. Các tiêu đề và phần thân được gửi dưới dạng gói tin UDP đơn lẻ, có chiều dài chính xác bằng độ dài của phần thân khúc cộng thêm 8 tính theo byte. Hơn nữa, không có gói tin UDP nào sẽ có độ dài lớn hơn 4096 byte hoặc có độ dài nhỏ hơn 8 byte. Từ 2 byte đầu tiên của tiêu đề khúc dữ liệu giữ một số nguyên không dấu kiểu big endian, có biên dịch như trường “control” được quy định tại Bảng K.1.

6 byte còn lại của tiêu đề khúc dữ liệu chứa 16 bit trọng số thấp của ID Yêu cầu được cung cấp bởi máy khách trong các yêu cầu gán với dữ liệu đáp ứng của khúc dữ liệu, cùng với trường “repeat” một byte và số thứ tự khúc 24 bit được mã hóa như số nguyên không dấu kiểu big endian. Số thứ tự khúc dữ liệu là số được tạo bởi máy chủ, bắt đầu từ không và sẽ được tăng thêm một cho mỗi khúc dữ liệu tiếp theo gửi cho máy khách để đáp ứng cùng một yêu cầu.

Các yêu cầu mới từ máy khách sẽ khiến số thứ tự khúc dữ liệu bị thiết lập lại bắt đầu từ 0 cho khúc dữ liệu đầu tiên được gửi trong đáp ứng của yêu cầu mới. Số thứ tự khúc dữ liệu không thể hoán đổi, và các máy chủ sẽ chỉ ra lỗi bằng cách sử dụng 7 mã lý do EOR (đạt giới hạn đáp ứng), xem D.3 trong trường hợp hết số thứ tự có sẵn.

Trường “repeat” một byte có thể được sử dụng bởi máy chủ bằng bất kỳ cách nào. Thông thường, trường “repeat” sẽ được sử dụng để phân biệt giữa các phiên bản khúc dữ liệu gốc và truyền lại, cho phép máy chủ quyết định trường hợp khúc dữ liệu là báo nhận trong gói tin báo nhận. Tuy nhiên, trường này có thể có khả năng được sử dụng theo những cách khác. Máy khách không nên cố gắng biên dịch trường “repeat” nhưng phải tái tạo nó trong các gói dữ liệu báo nhận trả về.

CHÚ THÍCH: ID Yêu cầu và số thứ tự khúc dữ liệu cho phép khúc dữ liệu được sắp xếp lại đúng theo thứ tự. Chúng cũng cung cấp phương thức để phát hiện khúc dữ liệu bị mất. Máy khách có thể phát hiện sự mất mát của các khúc bằng cách kiểm tra các thiết lập của số thứ tự khúc dữ liệu với những khoảng trống hoặc phát hiện các máy chủ đã không được truyền khúc dữ liệu chứa bản tin EOR; sau này sẽ nằm trong trong khúc dữ liệu cuối cùng được gửi để đáp ứng yêu cầu. Máy khách có thể sử dụng trường yêu cầu Bỏ qua để thông báo một cách rõ ràng cho máy chủ về khúc dữ liệu bị mất. Máy khách có thể lựa chọn để trì hoãn việc sử dụng các cơ chế hoặc không sử dụng chúng, theo quyết định của chúng.

Hình K.1 – Cấu trúc dữ liệu đáp ứng trên kết nối http-udp

Bảng K.1 – Biên dịch trường “control” trong từng tiêu đề khúc dữ liệu

Giá trị trường “control”	Biên dịch trong tiêu đề khúc dữ liệu đáp ứng	Biên dịch trong tiêu đề khúc dữ liệu báo nhận
0000 xxxx DDDD DDDD	Thời gian tối đa mà máy chủ muốn máy khách phải chờ đợi kể từ khi nhận được khúc dữ liệu này trước khi xác nhận nơi đến của khúc dữ liệu trong gói báo nhận đối với thời gian đầu được cho bởi 2⁽^D/8) micro giây, trong đó D là số nguyên không dấu biểu diễn bởi byte thứ hai của trường điều khiển. Biên dịch này không áp dụng nếu các yêu cầu tương ứng chứa trường yêu cầu Gửi đi với giá trị “no“.	Ước lượng thời gian khi máy khách nhận được khúc dữ liệu và gửi gói báo nhận, thể hiện bằng 2^(D/8) micro giây.
0000 AAAA xxxx xxxx	Lặp lại A xác nhận, trong phạm vi từ 0 đến 15. Máy chủ sẽ muốn máy khách xác nhận sự xuất hiện của khúc dữ liệu này ít nhất A +1 làn, trong A + 1 gói tin báo nhận riêng biệt. Các máy chủ sẽ muốn tất cả A + 1 gói tin báo nhận được gửi trong thời gian nhất định bởi tham số D, như định nghĩa ở trên. Nếu yêu cầu tương ứng bao gồm trường yêu cầu Gửi Đi, giá trị A không có nqhĩa, do máy khách không gửi gói tin báo nhận trong trường hợp đó.	Số lượng gói tin trước đó, mà máy khách đã xác nhận việc nhận được khúc dữ liệu này.
1111 1111 1111 1111	Dành riêng cho ITU/ISO sử dụng	Gói tin thiết lập kết nối
Các giá trị khác	Dành riêng cho ITU/ISO sử dụng	Dành riêng cho ITU/ISO sử dụng

K.6 Xác nhận máy khách đối với đáp ứng máy chủ

Đối với các gói tin đáp ứng đưa ra trong đáp ứng yêu cầu có chứa trường yêu cầu Gửi đi, không có xác nhận của máy khách rõ ràng, mặc dù các máy chủ có thể đón được khúc dữ liệu xuất hiện hoặc không xuất hiện bằng cách sử dụng thông tin được cung cấp thông qua trường yêu cầu Mảng chắn hoặc Bỏ qua trong các yêu cầu tiếp theo.

Trong các trường hợp khác, máy khách dự kiến sẽ xác nhận sự xuất hiện thành công của khúc dữ liệu bằng cách gửi lại gói tin báo nhận cho máy chủ. Các gói tin báo nhận UDP được gửi đến cùng một địa chỉ và cổng với gói tin thiết lập kết nối. Hơn nữa, máy khách phải gửi gói tin báo nhận từ socket giống với các địa chỉ nội bộ và cổng được sử dụng để gửi gói tin thiết lập kết nối. Mỗi gói tin báo nhận bao gồm một hoặc nhiều tiêu đề khúc dữ liệu từ khúc dữ liệu nhận được, ngoại trừ trường “control” được sửa đổi như sau. Giá trị D 8-bit trong trường “control” của tiêu đề khúc dữ liệu trả về được sửa đổi để phản hồi (ít nhất là xấp xỉ) chênh lệch thời gian khi máy khách nhận được khúc dữ liệu và gửi gói tin báo nhận tính theo micro giây, bằng 2⁽^D/8⁾ micro giây. Giá trị A 4-bit trong trường “điều khiển” của tiêu đề khúc dữ liệu trả về được sửa đổi để phản hồi số lượng gói tin trước, trong đó máy khách đã xác nhận nhận được khúc dữ liệu trong câu hỏi. Thông tin này được phản ánh trong Bảng J.1. Không có gói tin báo nhận nào lớn hơn 512 byte. Không có gói tin báo nhận nào có nhiều hơn 64 tiêu đề khúc dữ liệu. Gói tin thiết lập kết nối được phân biệt từ gói dữ tin báo nhận dựa vào 4 bit đầu tiên của trường điều khiển, như minh họa trong Bảng J.1.

Ngay cả khi máy khách đã xác định được khúc dữ liệu thông qua trường yêu cầu Bỏ qua, nếu khúc đó nhận được sau, máy khách có thể xác nhận đến thông qua gói tin báo nhận; điều này có thể làm giảm việc truyền tải thừa thông tin từ máy chủ. Trong trường hợp này, máy khách dự kiến sẽ cập nhật bộ nhớ đệm của nó cho phù hợp. Nghĩa là, máy khách không được nhận các phần dữ liệu mà nó đã loại bỏ, cho đến khi đăng nhập của máy chủ sau đó của những gì máy khách sẽ nhận được có thể chứa các mục nhập có sai sót.

Máy khách có thể xác nhận khúc dữ liệu nhiều lần trong các gói tin báo nhận riêng rẽ, trong trường hợp có nhiều gói tin báo nhận, các giá trị D và A sửa đổi nói chung sẽ khác nhau. Máy khách không cần phải gửi gói tin báo nhận riêng biệt cho từng khúc dữ liệu thu được, nhưng chúng cần phải nỗ lực để xác nhận các khúc dữ liệu trong khoảng thời gian quy định bởi giá trị D trong trường “control” của tiêu đề khúc dữ liệu.

CHÚ THÍCH 1: Xác nhận có thể được sử dụng bởi các máy chủ cho các mục đích điều khiển luồng. Lưu ý thêm rằng một khúc dữ liệu một khi đã được xác nhận bởi máy khách, thì các trường yêu Bỏ qua đề cập đến các khúc dữ liệu báo nhận có thể bị từ chối bởi máy chủ. Trong một số máy chủ thực thi, điều này có nghĩa là khi nhận được thông tin báo nhận cho phép máy chủ giải phóng tài nguyên lưu trữ tạm thời cần để duy trì mô hình bộ nhớ đệm thống nhất.

CHÚ THÍCH 2: Mặc dù các hướng dẫn trình bày ở trên, nó có khả năng chấp nhận được cho máy khách để kịp thời trả về một gói tin báo nhận riêng cho từng khúc dữ liệu nhận được, chỉ chứa tiêu đề khúc dữ liệu, với trường “điều khiển” đặt là 0. Các giá trị D được dự định cho phép các thuật toán điều khiển lưu lượng máy chủ để đưa vào tính toán trễ bổ sung có thể xảy ra khi một máy khách lựa chọn để tổng hợp báo nhận khúc dữ liệu thành một số lượng nhỏ hơn của gói tin báo nhận. Các giá trị A được dự định cho phép một máy chủ giảm xác suất xuất hiện các gói tin báo nhận và cung cấp đề xuất đếm lặp lại cho máy khách để tăng sức mạnh cho cơ chế xác nhận.

K.7 UDP và trường Độ dài Đáp ứng Tối đa (tham khảo)

Có thể có rất ít hoặc không có lý do cho việc sử dụng trường Độ dài Đáp ứng Tối đa với một kênh khai báo UDP, trừ khi trường yêu cầu Gửi đi được sử dụng. Ngoài trường hợp này, máy chủ sẽ có thể sử dụng thời gian mà gói tin báo nhận đến để điều chỉnh luồng dữ liệu đáp ứng cho máy khách, để duy trì đáp ứng. Nếu trường yêu cầu Gửi đi được sử dụng, tuy nhiên, các máy chủ không nhận được phản hồi liên tục từ máy khách và có thể dễ dàng đẩy một lượng lớn dữ liệu được xử lý qua kênh. Để duy trì đáp ứng hoặc tránh mất mát quá nhiều trong những trường hợp này, máy khách nên sử dụng trường Độ dài Đáp ứng Tối đa (xem C.6.1) để điều chỉnh luồng lưu lượng.

K.8 Kế hoạch thực hiện đối với truyền thông có xác nhận (tham khảo)

Khúc dữ liệu đáp ứng được gửi để đáp ứng với yêu cầu không chứa các trường yêu cầu Gửi đi được xác nhận thông qua gói tin báo nhận rõ ràng. Mô hình này khá phổ biến trong các giao thức và các phương tiện truyền thông mạng và thực hiện quản lý điều khiển luồng trong phạm vi máy chủ. Mặc dù không phải cần thiết với tiêu chuẩn này, các máy chủ được đề nghị chấp nhận kế hoạch truyền lại, trong đó khúc dữ liệu không được xác nhận sau một khoảng thời gian thích hợp sẽ được truyền lại, trừ khi máy chủ có thể xác định rằng các khúc dữ liệu không còn phù hợp cho máy khách, để thay đổi các thành phần trong cửa sổ quan tâm của máy khách. Thông thường, truyền lại sẽ dừng lại, khi khúc dữ liệu hoặc được xác nhận hoặc bị từ chối bởi chính trường yêu cầu Bỏ qua.

Máy khách không thể đợi máy chủ truyền lại các khúc dữ liệu không được xác nhận. Máy khách không có bất kỳ điểm bảo đảm nào mà tại đó máy chủ có thể quyết định khúc dữ liệu không được xác nhận đã không đến máy khách. Điều này rất quan trọng, vì nó có thể ảnh hưởng đến việc biên dịch đáp ứng cho các yêu cầu trong tương lai. Cho ví dụ, đáp ứng yêu cầu trong tương lai có thể bao gồm một bản tin EOR với mã lý do “Window Done “, nhưng máy khách không thể chắc chắn rằng nó đã thực sự nhận được tất cả các nội dung liên quan nếu yêu cầu trước đó chồng chéo cửa sổ quan tâm vẫn chưa giải quyết xong việc mất các khúc dữ liệu. Để tránh sự nhập nhằng được tạo ra bởi tình huống như vậy, các máy khách có thể sử dụng các trường yêu cầu Bỏ qua để từ chối một cách rõ ràng các khúc dữ liệu bị mất từ các yêu cầu không nhận được bất kỳ nội dung nào trong một khoảng thời gian khá lâu. Điều này cho phép các máy khách đảm bảo chắc chắn rằng máy chủ sẽ bao gồm các nội dung có liên quan bị mất từ những yêu cầu để đáp ứng các yêu cầu đó trong tương lai.

Nếu một máy khách không cần phản hồi mã lý do được cung cấp bởi bản tin EOR (chẳng hạn máy khách có thể tính toán trực tiếp cho dù nội dung bộ nhớ đệm của nó chứa đáp ứng hoàn thiện của yêu cầu cửa sổ liên quan), có thể không cần cho nó để xem xét sử dụng trường yêu cầu Bỏ qua.

Các máy khách cần lưu ý rằng việc sử dụng tích cực trường yêu cầu Bỏ qua có thể làm tăng đáng kể lượng công việc trên máy chủ. Ví dụ, một máy chủ điển hình có thể tạo ra khúc dữ liệu xử lý theo khối được lập lịch để truyền đi. Nếu một máy khách tự động đưa ra trường yêu cầu Bỏ qua đề cập đến tất cả các yêu cầu trước đó bất cứ khi nào cửa sổ quan tâm của nó thay đổi theo bất kỳ cách nào, máy chủ có thể phải loại bỏ rất nhiều khúc dữ liệu đã được tạo ra mà không truyền chúng. Mặc dù điều này không phá vỡ khả năng tương tác, máy chủ phải tái tạo nội dung nhiều lần trong khoảng thời gian một phiên tương tác. Để tránh vấn đề này, khuyến nghị máy khách chờ đợi cho đến khi nhận được ít nhất một khúc dữ liệu từ yêu cầu A trước khi đưa ra yêu cầu Bỏ qua đề cập đến khúc dữ liệu từ yêu cầu B trước đó, trừ khi không nhận được khúc dữ liệu nào trong khoảng thời gian đáng kể. Nói chung là máy chủ có thể đưa ra quyết định tốt hơn so với máy khách đối với các khúc dữ liệu không được truyền do cửa sổ quan tâm của máy khách đã thay đổi.

Trường yêu cầu Mảng chắn không thường sử dụng với truyền thông có xác nhận. Tuy nhiên, nếu trường yêu cầu này được sử dụng bởi một máy khách, nó cung cấp một cơ chế bổ sung để mặc nhiên thừa nhận sự xuất hiện của khúc dữ liệu không bị từ chối – nó có thể là gói tin báo nhận đối với các dữ liệu bị mất này. Bỏ qua trường yêu cầu Mảng chắn không ảnh hưởng đến khả năng tương tác trong JPIP nhưng có thể dẫn đến truyền tải dư thừa, vì vậy các máy chủ được khuyến nghị để thực hiện tính năng này.

K.9 Kế hoạch thực hiện đối với truyền thông không có xác nhận (tham khảo)

Khúc dữ liệu đáp ứng được gửi để đáp ứng với yêu cầu không chứa các trường yêu cầu Gửi đi không được xác nhận thông qua gói tin báo nhận. Như tất cả truyền thông JPIP, máy chủ có thể xác nhận dữ liệu mà nó đã gửi đến cho máy khách và được lưu đệm tại máy khách, trừ khi nó tiếp cận theo cách khác. Nếu không có giả định này, các máy chủ sẽ tìm thấy việc truyền tải cùng một nội dung lặp đi lặp lại trong phiên tương tác điển hình. Do UDP là truyền tải không tin cậy, nên máy chủ phải được chuẩn bị cho khả năng khúc dữ liệu thực tế bị mất. Đặc biệt, nó phải được chuẩn bị để xử lý các trường yêu cầu Bỏ qua.

Một máy chủ điển hình sẽ giữ một bản ghi các dãy byte ngăn dữ liệu chứa trong từng khúc dữ liệu đã được gửi cho máy khách. Nếu khúc dữ liệu là bị bỏ qua, bản ghi có thể bị xóa và máy chủ nên loại bỏ các dãy byte ngăn dữ liệu có liên quan trong nội dung bản ghi máy khách đã nhận được (chẳng hạn mô hình bộ nhớ đệm máy khách); nội dung này có thể được gửi lại trên đáp ứng với yêu cầu sắp tới, nếu thấy có liên quan. Do yêu cầu Bỏ qua chỉ cung cấp một cơ chế cho máy khách để biểu thị nó không nhận được khúc dữ dữ liệu, nếu không có bước đó được thực hiện bởi các máy khách, khúc dữ liệu của máy chủ điển hình được gửi đi và không bị từ chối có thể phát triển vô hạn; kết quả là, máy chủ điển hình cuối cùng sẽ phải từ chối khúc dữ liệu đó, để tất cả mọi thứ nhận được sự từ chối trong thời gian dài. Điều này cuối cùng sẽ gây ra truyền tải dư thừa, nhưng các máy khách có thể tránh được vấn đề bằng cách sử dụng một trong hai kế hoạch sau:

1) Máy khách thực thi có thể sắp xếp đẻ gửi báo cáo thao tác mô hình bộ nhớ đệm thêm vào để trực tiếp thêm các dãy byte ngăn dữ liệu vào mô hình bộ nhớ đệm của máy chủ. Điều này tránh được các tính toán dư thừa, miễn là các máy chủ không vô tình xóa thông tin này một lần nữa trong khi từ chối khúc dữ liệu có liên quan tại một điểm sau đó. Để tránh khả năng này và giảm bớt gánh nặng trên các máy chủ, các máy khách được khuyến nghị nên sử dụng đồng thời hai trường yêu cầu Mô hình và trường yêu cầu Bỏ qua, khai báo tất cả các khúc dữ liệu từ một yêu cầu trước đó được đưa ra bị từ chối, nhưng đồng thời thêm tất cả các dãy byte ngăn dữ từ khúc dữ liệu đến vào mô hình bộ nhớ đệm của máy chủ thông qua các trường yêu cầu Mô hình. Tổng quát hơn, nó sẽ hoàn hảo hơn cho các máy khách từ chối khúc dữ liệu một cách rõ ràng hơn là để các máy chủ làm như vậy ở tại một điểm bên dưới trong tương lai; và nó là thích hợp hơn cho các máy khách từ chối khúc dữ liệu trong cùng một yêu cầu trước đó, trong đó nội dung đến được xác định thông qua các trường yêu cầu Mô hình. Giữ lại ý tưởng này, nó sẽ hoàn hảo cho các máy chủ để xử lý các tác động của trường yêu cầu Bỏ qua trước khi xử lý bất kỳ trường yêu cầu Mô hình tìm thấy trong cùng yêu cầu.

2) Một máy khách thực thi có thể sử dụng trường yêu cầu Mảng chắn để đảm bảo rằng máy chủ sẽ không có yêu cầu liên tiếp chứa trường yêu cầu Bỏ qua từ chối các khúc dữ liệu thuộc về yêu cầu trước đó tại một điểm nhất định. Các xác nhận có hiệu quả đối với tất cả các khúc dữ liệu chưa bị từ chối từ các yêu cầu trước đến yêu cầu–id theo quy định của Mảng chắn. Để giữ nguồn tài nguyên máy chủ, các máy khách được khuyến cáo sử dụng thường xuyên Mảng chắn. Một máy khác thực thi điển hình có thể từ chối tất cả các khúc dữ liệu không đến kết hợp với yêu cầu đầy đủ trước đó và đồng thời sử dụng các trường yêu cầu Mảng chắn để chỉ đến máy chủ không bị từ chối thêm cho khúc dữ liệu từ yêu cầu đó.

Phụ lục L

(Tham khảo)

Quy trình đăng ký mở rộng cho tiêu chuẩn ISO/IEC 15444-9

L.1 Giới thiệu việc đăng ký

Đăng ký là quá trình bổ sung phần mở rộng tiêu chuẩn này sau khi nó đã được xuất bản. Trong tiêu chuẩn này, nhiều khả năng có thể được mở rộng thông qua đăng ký. Điều này xác định các khoản mục có thể được mở rộng bằng cách đăng ký, quá trình có khả năng được đăng ký, và quá trình mà Cơ quan đăng ký sẽ công bố những phần mở rộng. Chỉ có các khoản mục được quy định trong mục này có thể được mở rộng bằng cách đăng ký.

L.2 Các yếu tố đăng ký

Quá trình đăng ký bao gồm các yếu tố sau đây.

– Cơ quan đăng ký: Đơn vị tổ chức trách nhiệm xem xét, duy trì, phân phối và hoạt động như một địa chỉ liên lạc cho tất cả các hoạt động liên quan đến việc đăng ký. Thẩm quyền đăng ký sẽ được xác định.

– Người nộp: Người nộp là tổ chức hoặc người yêu cầu các khoản mục cần được đăng ký.

– Hội đồng Xét duyệt: Hội đồng Xét duyệt là cơ quan tổ chức chấp thuận việc đăng ký của một khoản mục được đề xuất. Nó bao gồm một ủy ban đặc biệt do Chủ tịch Hội đồng Xét duyệt bổ nhiệm. Hội đồng Xét duyệt sẽ là tiểu ban tiêu chuẩn JPIP ISO/IEC JTC 1/SC 29/WG 1.

– Chủ tịch Hội đồng Xét duyệt: Chủ tịch Hội đồng Xét duyệt chịu trách nhiệm cho mỗi khoản mục đề xuất được xem xét. Ông giao tiếp với người nộp thông qua Thẩm quyền Đăng ký. Chủ tịch Hội đồng Xét duyệt phải là chủ tịch tiểu ban tiêu chuẩn JPIP ISO/IEC JTC 1/SC 29/WG 1.

– Kiêm thử: Cơ sở lý luận đề Hội đồng Xét duyệt sử dụng để xác định đệ trình/ khoản mục được đăng ký.

– Đệ trình/khoản mục: Đây là đề xuất đăng ký. Mỗi đề xuất sẽ bao gồm tên của khoản mục được mở rộng, thẻ/định danh đề xuất cho các phần mở rộng và cơ sở/mục đích mở rộng.

L.3 Tiêu chí thẩm định đăng ký

Hội đồng Xét duyệt phải thẩm định các đệ trình dựa trên các tiêu chí sau:

– Liệu nó có đáp ứng nhu cầu chưa được đáp ứng bởi tiêu chuẩn hoặc phần mở rộng khác không?

– Đã xác định đầy đủ phần mở rộng chưa?

– Đã có phần mở rộng đáp ứng một nhu cầu chung (ví dụ, các ứng dụng video trực tuyến nói chung) hoặc một nhu cầu cụ thể của nhà cung cấp (ví dụ, triển khai streaming video của một nhà cung cấp cụ thể)?

L.4 Các khoản mục có thể đăng ký mở rộng

L.4.1 Các khung mở rộng bên trong khung Chờ

Các loại khung mới cho các khung sẽ được sử dụng trong trường ExtendedBoxList trong khung Chờ (xem A.3.6.3) có khả năng được đăng ký. Đề xuất đăng ký loại khung mới phải có một định nghĩa đầy đủ về khung (loại khung và nội dung khung), hướng dẫn khi một máy chủ có thể ghi vào khung này bên trong khung Chờ, và hướng dẫn về những gì một máy khách có thể làm khi nó gặp một khung Chờ chứa khung này.

L.4.2 Ngữ cảnh Dòng mã

Giá trị context-range mới cho yêu cầu cụ thể sử dụng trường Ngữ cảnh Dòng mã (Xem C.4.7) có thể được đăng ký. Đề xuất đăng ký context-range mới phải có một định nghĩa đầy đủ về giá trị, hướng dẫn về cách các máy chủ ánh xạ giá trị đó vào dòng mã có sẵn tại địa chỉ logic, và hướng dẫn về cách các máy chủ đáp ứng trong tiêu đề đáp ứng Ngữ cảnh Dòng mã.

L.4.3 Truyền tải kênh

Truyền tải kênh mới (Phụ lục H) có khả năng được đăng ký. Đề xuất đăng ký truyền tải kênh mới phải bao gồm định nghĩa đầy đủ của truyền tải, gồm định danh sử dụng cho truyền tải kênh đó.

L.4.4 Tham chiếu

Tham chiếu mới của máy khách mới có khả năng được đăng ký. Điều này bao gồm tập các tham chiếu mới (giá trị mới của related-pref-set quy định tại C.10.2.1), hoặc tùy chọn mới cho tập tham chiếu hiện tại hoặc đã đăng ký. Đề xuất đăng ký tùy chọn tham chiếu hoặc tập tham chiếu mới phải có một định nghĩa đầy đủ về cú pháp, ý nghĩa của tùy chọn mới, và hướng dẫn về cách các máy chủ đáp ứng khi hoạt động theo tham chiếu đó.

L.5 Quy trình đăng ký

Quy trình đăng ký như sau:

a) Người nộp đưa ra một khoản mục đề xuất để đăng ký.

b) Khoản mục đề xuất này được nộp tại Cơ quan Đăng ký.

c) Cơ quan đăng ký chuyển khoản mục đề xuất đến Chủ tịch Hội đồng Xét duyệt.

d) Chủ tịch Hội đồng Xét duyệt xem xét gửi khoản mục đề xuất cho Hội đồng Xét duyệt xem xét và lên lịch cuộc họp, các trao đổi điện thoại,… thích hợp cho việc xem xét các khoản mục.

e) Hội đồng Xét duyệt phải thẩm định tất cả các đệ trình. Nếu văn bản của đệ trình không đáp ứng được yêu cầu, thì nó sẽ được trả lại cho người nộp để làm rõ. Ưu tiên sẽ được trao cho các giải pháp tổng quát hơn, và các giải pháp của nhà cung cấp cụ thể có thể được trả lại cho người nộp để thực hiện tổng quát hơn và thích hợp hơn cho ngành công nghiệp nói chung được đề xuất.

f) Nếu được chấp thuận Chủ tịch sẽ chuyển đề xuất cho Cơ quan Đăng ký và thông báo ISO và người nộp, để tiến hành đăng ký hoặc công bố.

g) Nếu bị từ chối, Chủ tịch chuẩn bị một tài liệu phản hồi đưa ra lý do tại sao các khoản mục bị từ chối và chuyển tài liệu này cho Cơ quan Đăng ký thông báo cho người nộp.

L.6 Khung thời gian đối với quy trình đăng ký

Hội đồng Xét duyệt phải đáp ứng tất cả các yêu cầu đăng ký trong thời hạn bảy tháng kể từ ngày nộp. Trong thời gian đó, Hội đồng Xét duyệt sẽ gặp nhau tại một cuộc họp chính thức của ISO/IEC JTC 1/SC 29/WG 1 để thẩm định đề xuất, đưa ra quyết định, và dự thảo phản hồi.

Phụ lục M

(Tham khảo)

Các ví dụ áp dụng

M.1 Tổng quan

Phụ lục này trình bày một số ví dụ tham khảo về các khía cạnh triển khai JPIP.

M.2 Sử dụng JPIP với các dòng mã trong định dạng tập tin khác

JPIP có thể được sử dụng để truy cập các dòng mã JPEG 2000 được lưu trữ trong các định dạng tập tin khác với các tập tin họ tiêu chuẩn JPEG 2000. Ví dụ, các tập tin DICOM và PDF cả hai đều có khả năng chứa các dòng mã JPEG 2000. Trong môi trường máy chủ – máy khách, một số thủ tục không quy định trong tiêu chuẩn này có thể được sử dụng để xác định vị trí dòng mã JPEG 2000. Các yêu cầu và đáp ứng JPIP có thể được sử dụng trên các đối tượng khi các dòng mã được định vị. Các trường yêu cầu địa chỉ phụ chỉ dành cho tình huống như vậy. Ngoài ra, máy chủ có thể cung cấp truy cập tới các dòng mã qua một URL khác.

M.3 Kỹ thuật triển khai phần khối ảnh

M.3.1 Máy chủ quyết định các phần khối ảnh đối với yêu cầu cửa sổ hiển thị

Đối với truyền thông qua phần khối ảnh, việc ánh xạ cửa sổ hiển thị đến một tập các khối ảnh là đơn giản. Các vùng mong muốn của ảnh được chuyển đổi sang “đơn vị lưới tọa độ tham chiếu.” Các thành phần XTsiz và YTsiz của đoạn nhãn SIZ được sử dụng đề xác định khối ảnh giao với cửa sổ hiển thị.

CHÚ THÍCH: Mặc dù trên lưới tọa độ tham chiếu tất cả các khối ảnh có cùng kích thước, trên lưới tọa độ tham chiếu lấy mẫu phụ, sau khi phân tách băng con, khối ảnh không nhất thiết phải có cùng một kich thước. Một khối ảnh giao với của sổ hiển thị, thậm chí là một khối ảnh chứa hoàn toàn trong nó, có thể không đóng góp mẫu cho cửa sổ hiển thị tại mức phân giải thấp nhất; Tuy nhiên, việc triển khai không cần phải tận dụng điều này bằng cách bỏ qua các khối ảnh đầy đủ từ các đáp ứng.

Mức phân giải và chất lượng được sử dụng để xác định phần khối ảnh cần thiết. Các khung Bảng Chỉ mục phần Khối ảnh, nếu có, có thể được sử dụng để thu thập thông tin về vị trí của các phần trong dòng mã và (nếu có các trường Bổ trợ) hoàn thành các mức phân giải trong phần khối ảnh. Các đoạn nhãn SOT cũng cung cấp cho các chỉ số phần khối ảnh và khối ảnh, số lượng các byte trong mỗi phần khối ảnh. Từ dòng mã, các byte thích hợp, tương ứng với phần khối ảnh cần được gửi đi, được truyền cho máy khách. Trong trường hợp cửa sổ hiển thị thay đổi và các khối ảnh có liên quan tương ứng cũng thay đổi, thì chỉ có phần khối ảnh liên quan không được gửi đi trước đó cần được gửi để cập nhật các hình ảnh hiển thị.

M.3.2 Quá trình giải mã ảnh từ bản tin dòng JPT trả về

JPIP quy định cụ thể cơ chế để giao tiếp dữ liệu ảnh nén và dữ liệu đặc tả giữa máy khách và máy chủ. Các cơ chế cho máy khách để hiển thị dữ liệu trả về chưa được xác định, và trên thực tế sẽ rất khác giữa các ứng dụng. Mục này cung cấp thông tin về việc thu thập mẫu thành phần từ dữ liệu trả về.

Một ứng dụng máy khách nhận được tất cả các dữ liệu tiêu đề chính (chỉ định bởi các tiêu đề ngăn dữ liệu xuất hiện trong bản tin đáp ứng cho ngăn dữ liệu tiêu đề 0 hoàn chỉnh), có thể nối ngăn dữ liệu với đầy các phần khối ảnh hoàn chỉnh từ ngăn dữ liệu để tạo thành một dòng mã JPEG 2000 hợp lệ. Dòng mã này có thể được cung cấp phù hợp với bộ giải mã JPEG 2000 và kết quả được hiển thị. Tất nhiên, với mục đích hiệu quả, máy khách có thể muốn cung cấp các tham số cửa sổ hiển thị để một bộ giải mã thông minh cùng với dòng mã nên chỉ có các phần cần thiết đối với cửa sổ hiển thị hiện tại được hiển thị.

M.3.3 Tín hiệu Bổ trợ đối với các phần khối ảnh

Bảng M.1 và M.2 minh họa việc sử dụng các trường Bổ trợ trong bản tin ngăn dữ liệu khối ảnh và khung Bảng Chỉ mục phần Khối ảnh.

CHÚ THÍCH: Trong ví dụ này, định nghĩa r khác với việc sử dụng ở các chỗ khác trong tiêu chuẩn này, nhưng phải phù hợp với Phụ lục B của tiêu chuẩn ISO/IEC 15444-1:2004.

Bảng M.1 minh họa một trường hợp đơn giản trong đó tất cả các phần khối ảnh độ phân giải lũy tIến có cùng số mức phân tách, trong đó ranh giới bản tin (trong trường hợp ngăn dữ liệu) hoặc ranh giới phần khối ảnh (trong trường hợp khung chỉ số) chỉ xảy ra giữa các mức phân giải liên tiếp.

Bảng M.1 – Ví dụ về việc sử dụng các trường Bổ trợ trong trường hợp đơn giản

Số thứ tự bản tin trong ngăn dữ liệu, hoặc số thứ tự phần khối ảnh trong khối ảnh	Mức phần giải r	*n = N_L – r*	Giá trị Bổ trợ
0	0	2	2
1	1	1	1
2	2	0	0

Bảng M.2 minh họa một trường hợp phức tạp hơn, trong đó số mức phân tách khác nhau với khối ảnh thành phần. Chú giải được đưa ra trong cột cuối cùng của bảng trên xuất hiện đầu tiên của mỗi giá trị bổ trợ mới. Trường hợp này tương ứng với khối ảnh từ một hình ảnh ba thành phần trong một RC… theo thứ tự lũy tiến, ví dụ như thứ tự lũy tiến LRCP với một lớp duy nhất, hoặc thứ tự lũy tiến RPCL với môt phân khu ảnh duy nhất trong khối ảnh. Giới hạn bản tin (trong trường hợp ngăn dữ liệu) hoặc giới hạn phần khối ảnh (trong trường hợp khung Chỉ mục) xảy ra giữa các thành phần của từng mức phân giải cũng như giữa các mức phân giải. Thành phần 0 và 1 có hai mức phân tách (N_L = 2) và thành phần 2 có một mức khai triển duy nhất (N_L = 1).

Bảng M.2 – Ví dụ về việc sử dụng các trường Bổ trợ trong trường hợp phức tạp hơn

Số thứ tự bản tin trong ngăn dữ liệu, hoặc số thứ tự phần khối ảnh trong khối ảnh	Chỉ số thành phần c	Mức phân giải r	*n = N_L*– r	Giá trị Bổ trợ	Chú giải
0	0	0	2	3	Không có mức hoàn thành
1	1	0	2	2	n = 2 hoàn thành
2	2	0	1	2
3	0	1	1	2
4	1	1	1	1	n = 1 hoàn thành
5	2	1	0	1
6	0	2	0	1
7	1	2	0	0	Tất cả các mức hoàn thành

M.4 Kỹ thuật triển khai dựa trên phân khu ảnh

M.4.1 Máy chủ quyết định các phân khu ảnh lên quan đối với yêu cầu cửa sổ hiển thị

Khi truyền thông liên quan đến kiểu phương tiện truyền thông dòng JPP, máy chủ dịch vùng ảnh yêu cầu của máy khách vào một tập các phân khu ảnh có liên quan đến yêu cầu. Phần đầu tiên của quá trình này liên quan đến bản dịch của các tham số fx, fy, sx, sy, ox và oy được cung cấp bởi trường yêu cầu Kích thước Khung hình, Kích thước Vùng và Độ lệch Vùng, vào các tham số dòng mã như kích thước khung hình, kích cỡ vùng và độ lệch fx, fy ‘, sx, sy, ox và oy, cho từng dòng mã có liên quan. Bản dịch này được xử lý theo cùng một cách với dịch vụ dựa trên phân khu ảnh và dịch vụ dựa trên khối ảnh, và dựa trên Phương trình C-1 và C-2, có thể sửa đổi theo Phương trình C-3 và C-4. Mục này mô tả cách một máy chủ xác định các phân khu có liên quan đến các vùng được xác định bởi các tham số fx, fy ‘, sx, sy, ox và oy’, trong một dòng mã cụ thể.

Cho r là số nguyên không âm trong Phương trình C-1 được sử dụng bởi các máy chủ để tìm fx và fy ‘, dựa trên yêu cầu của máy khách. Như đã đề cập trong liên kết với các phương trình đó, r được hiểu là số mức DWT phân giải cao nhất bị loại bỏ, mặc dù r được phép vượt quá con số thực tế của các mức DWT có sẵn cho bất kỳ khối ảnh thành phần cho trước. Đó Ià thuận Iợi cho việc ánh xạ các vùng được mô tả sx’, sy’, ox’ và oy’ lên lưới tọa độ phân giải cao của dòng mã. Điều này tạo ra một vùng mà góc trên bên trái cho bởi (, ) có góc dưới bên phải cho bởi (, ), trong đó:

, , and

Các máy chủ chỉ cần xem xét các khối ảnh giao với vùng này trên lưới tọa độ phân giải cao của dòng mã. Đối với mỗi khối ảnh như vậy, máy chủ chỉ cần xem xét những thành phần ảnh được yêu cầu bởi máy khách, theo cách thức được mô tả trong liên kết trường yêu cầu Ngữ cảnh Dòng mã và Dòng mã. Đối với mỗi khối ảnh thành phần, ký hiệu t and c, cho D_t_,c là số mức DWT đã được sử dụng để nén khối ảnh thành phần. Nếu D_t,c ≥ r, máy chủ phải loại bỏ tất cả các phân khu ảnh tại mức phân giải cao nhất r của khối ảnh thành phần; nếu không, nó sẽ loại bỏ tất cả phân khu ảnh tại mức phân giải cao nhất D_t,c của khối ảnh. Nếu D_t,c ≥ r, máy chủ phải loại bỏ tất cả các phân khu ảnh tại mức phân giải cao nhất r của khối ảnh thành phần, chỉ để lại các phân khu ảnh đại diện cho băng con LL thấp nhất của khối ảnh thành phần.

Đối với mỗi phân khu ảnh còn lại sau khi loại bỏ các khối ảnh, thành phần và mức phân giải đề cập ở trên, máy chủ cần xác định có hay không các khối mã thuộc phân khu ảnh góp phần phục dựng các vùng được xác định bởi , và , trên lưới tọa độ phân giải cao của dòng mã. Một khối mã đóng góp cho vùng này nếu các mẫu của nó ảnh hưởng đến việc phục dựng mẫu thành phần hình ảnh phân giải đầy đủ có tọa độ (x, y) thoả mãn:

and

Trong đó XRsiz^c và YRsiz^c biểu thị hệ số lấy mẫu phụ theo phương ngang và dọc đối với thành phần liên quan, c, trong đoạn nhãn SIZ của dòng mã hóa.

Điều quan trọng cần lưu ý rằng việc phục dựng lại một phần hình ảnh có độ phân giải đầy đủ liên quan đến tổng hợp sóng con, đó là một quá trình tự mở rộng. Như vậy, vùng mà bất kỳ phân khu ảnh cho trước đóng góp thường chồng lên vùng mà phân khu lân cận đóng góp. Các máy chủ phải được chuẩn bị để giải thích cho những hiệu ứng mở rộng của biến đổi sóng con khi xác định các phân khu ảnh có liên quan đến yêu cầu của máy khách.

M.4.2 Quá trình giải mã ảnh từ bản tin dòng JPP trả về

JPIP quy định cụ thể cơ chế giao tiếp dữ liệu ảnh nén và dữ liệu đặc tả giữa máy khách và máy chủ. Các cơ chế cho máy khách để hiển thị dữ liệu trả về chưa được xác định, và trên thực tế sẽ rất khác giữa các ứng dụng.

M.5 Bản ghi giao thức JPIP

M.5.1 Tổng quan

Trong bản ghi ví dụ sau đây, đoạn văn bản theo sau các biểu tượng “<<” ở đầu dòng được gửi từ máy khách đến máy chủ, đoạn văn bản theo sau các biểu tượng “>>” ở đầu dòng được gửi từ máy chủ tới khách hàng, và các đoạn văn bản theo sau biểu tượng “-” là một chú giải và không thực sự truyền đi. Các chú giải có thể cho thấy một số dữ liệu được truyền nhưng không được hiển thị.

M.5.2 Sử dụng HTTP

Bản ghi dưới đây cho thấy năm yêu cầu được gửi từ máy khách đến máy chủ và đáp ứng của máy chủ.

Yêu cầu đầu tiên yêu cầu gọi tập tin JP2 phoenix.jp2, yêu cầu dòng mã đầu tiên trong tập tin, chiều dài tối đa được đặt trên đáp ứng, yêu cầu một id địa chỉ, các dữ liệu được yêu cầu để trả lại như một dòng JPP, và yêu cầu thiết lập một phiên trên HTTP. Không có cửa sổ, và do đó không có dữ liệu ảnh được yêu cầu.

Các máy chủ trả lời cung cấp một ID địa chỉ cho các hình ảnh, và một ID cho các kênh mới thiết lập. Dòng tiêu đề bắt đầu “JPIP-cnew” chỉ ra một đường dẫn mới có thể được sử dụng để truy cập các tập tin hình ảnh. Giá trị của đường dẫn “jpip” có thể là một đường dẫn đến chương trình CGI trên máy chủ được thiết kế để đối phó với tất cả các lệnh tương tác JPIP. Một số dữ liệu từ các tập tin được trả về trong phần thân; đây sẽ là khung định dạng tập tin, và là tiêu đề chính của dòng mã đầu tiên.

Yêu cầu thứ hai của máy khách sử dụng các đường dẫn mới, “jpip.cgi”, và ID Kênh để xác định hình ảnh mong muốn (không cần thiết tên hình ảnh hoặc ID địa chỉ). Yêu cầu này cũng quy định một cửa sổ quan tâm đặc biệt.

Đáp ứng của yêu cầu thứ 2 chỉ ra rằng cửa sổ hiển thị đã được thay đổi và một cửa sổ nhỏ hơn làm trung tâm trong giao diện cửa sổ hiển thị yêu cầu được trả về. Các máy chủ bắt đầu trả về dữ liệu cho cửa sổ này.

Trước khi nhận được đáp ứng hoàn chỉnh cho yêu cầu thứ 2, máy khách đưa ra yêu cầu thứ 3. Các máy khách điều chỉnh cửa sổ hiển thị với kích thước theo quy định của máy chủ.

Các máy chủ tiếp tục đáp ứng yêu cầu thứ 2 trong một thời gian, sau đó bắt đầu đáp ứng yêu cầu thứ 3. Trong đáp ứng này, máy khách gửi yêu cầu thứ 4 với một vùng hơi khác. Các máy chủ tiếp tục đáp ứng yêu cầu thứ 3 trong một thời gian sau đó bắt đầu đáp ứng yêu cầu thứ 4.

Các máy khách chờ đợi cho đến khi đáp ứng thứ 4 hoàn thành, sau đó đưa ra yêu cầu kết thúc phiên và kết nối HTTP. Không có dữ liệu đáp ứng được hiển thị trong trường hợp này khi đóng kết nối.

Sau đây là ví dụ về HTTP GET truyền thông theo phiên với yêu cầu mô hình.

Sau đây là ví dụ về HTTP GET truyền thông phi trạng thái với yêu cầu mô hình.

M.5.3 Sử dụng HTTP với khai báo TCP

M.6 Sử dụng JPIP với HTML

Một hệ thống JPIP có thể được sử dụng với các trang HTML và xHTML theo nhiều cách khác nhau. Nếu một máy chủ JPIP bao gồm khả năng chuyển mã một phần hình ảnh JPEG hoặc các kiểu phương tiện truyền thông hình ảnh hoàn chỉnh khác, thì có thể sử dụng HTML để truy cập vào các phần của hình ảnh JPEG 2000 không có bất kỳ thay đổi các trình duyệt hiện tại.

Xét một trang web có chứa các đoạn HTML sau:

Bất kỳ trình duyệt web nào muốn hiển thị trang web này với hình ảnh sẽ đưa ra một yêu cầu để có được những hình ảnh. Yêu cầu này sẽ bắt đầu:

và sẽ bao gồm nhiều dòng tiêu đề HTTP khác, thường xác định các trình duyệt, và các thứ trình duyệt chấp nhận. Yêu cầu HTTP này là một yêu cầu JPIP hợp lệ và máy chủ JPIP nhận được yêu cầu này hoặc trả về một bản tin lỗi hoặc quyết định phần có liên quan của tập tin JP2 để truy cập và chuyển nó vào tập tin JPEG. Các bản tin được trả về như sau:

Đó là một đáp ứng JPIP hợp lệ, và cũng có thể là một đáp ứng HTTP hợp lệ mà tất cả các trình duyệt ảnh biết làm thế nào để hiển thị. Lưu ý rằng nó được ưa thích nhưng không bắt buộc cho máy chủ để sử dụng chuyển mã các khúc dữ liệu để yêu cầu này có thể bị gián đoạn. Ví dụ trên không phải là một ví dụ về chuyển mã khúc dữ liệu.

Nó cũng có thể để viết các trang web sử dụng JPEG khi chỉ có sẵn JPEG, sử dụng JPEG 2000 khi có sẵn, và dòng JPT hoặc dòng JPP sẵn trong trình duyệt của máy khách. Xét các đoạn HTML:

Trong trường hợp này, không yêu cầu loại tường minh. Một máy chủ JPIP sử dụng HTTP nên kiểm tra các dòng yêu cầu HTTP “Chấp nhận:” cấp cho máy khách. Tùy thuộc vào sự hiện diện của image/jp2 hoặc image/jpt-stream hoặc image/jpp-stream hoặc image/jpeg, máy chủ có thể xác định một định dạng tương thích để trả về.

Phụ lục N

(Tham khảo)

Tập ABNF của JPIP

N.1 ABNF của yêu cầu JPIP

N.2 BNF của đáp ứng JPIP

Phụ lục O

(Tham khảo)

Tuyên bố bằng sáng chế

Tổ chức tiêu chuẩn quốc tế (ISO) và Ủy ban Kỹ thuật Điện Quốc tế (IEC) hướng chú ý đến một thực tế rằng đây là tuyên bố về việc tuân thủ một phần của tiêu chuẩn ISO / IEC 15444 có thể liên quan đến việc sử dụng các bằng sáng chế.

ISO và lEC sẽ không liên quan đến các chứng cứ, tính hiệu lực và phạm vi của các bản quyền sáng chế.

Chủ sở hữu các bản quyền sáng chế đã đảm bảo với tiêu chuẩn ISO và IEC rằng họ sẵn sàng đàm phán cấp giấy phép theo các điều khoản hợp lý và không phân biệt đối xử và điều kiện với các ứng viên trên khắp thế giới. Về mặt này, các báo cáo của những người nắm giữ các bằng sáng chế phải được đăng ký với ISO và IEC. Thông tin có thể thu được từ các công ty được liệt kê dưới đây.

Sự chú ý đưa ra khả năng rằng một số các yếu tố này là một phần của tiêu chuẩn ISO / IEC 15444 có thể là đối tượng của quyền sáng chế khác với những xác định trong phụ lục này. ISO và IEC sẽ không chịu trách nhiệm xác định bất kỳ hoặc tất cả các quyền bằng sáng chế như vậy.

Công ty
1	Canon InC.
2	Ricoh Company, Limited.

Thư mục tài liệu tham khảo

[1] ISO/IEC 15444-9:2005/Amd5:2014, Information technology – JPEG 2000 image coding system: Interactivity tools, APIs and protocols

[2] ISO/IEC 15444-9:2005/Amd 1:2006 – APIs, metadata, and editing

[3] ISO/IEC 15444-9:2005/Cor 1:2007

[4] ISO/IEC 15444-9:2005/Amd 2:2008 – JPIP extensions

[5] ISO/IEC 15444-9:2005/Amd 3:2008 – JPIP extensions to 3D data

[6] ISO/IEC 15444-9:2005/Cor 2:2008

[7] ISO/IEC 15444-9:2005/Amd 4:2010 – JPIP server and client profiles

[8] ISO/IEC 15444-9:2005/Cor 3:2011

[9] ISO/IEC 15444-9:2005/Amd 5:2014 – UDP transport and additional enhancements to JPIP

MỤC LỤC

1 Phạm vi áp dụng

2 Tài liệu viện dẫn

3 Thuật ngữ và định nghĩa

3.1 Thuật ngữ JPEG 2000 Phần 1

3.2 Thuật ngữ cho HTTP

3.3 Thuật ngữ cho JPIP

3.4 Ký hiệu

4 Chữ viết tắt

5 Quy ước

5.1 Các quy tắc ABNF

5.2 Quy tắc ABNF định dạng tập tin

5.3 Giải pháp mô tả đồ họa cho các khung (tham khảo)

6 Mô tả chung

6.1 Giao thức JPIP

6.2 Mục đích

7 Sự phù hợp

Phụ lục A (Quy định) Các kiểu phương tiện truyền thông dòng JPP và dòng JPT

Phụ lục B (Quy định) Phiên, kênh, mô hình bộ nhớ đệm và tập mô hình

Phụ lục C (Quy định) Yêu cầu của máy khách

Phụ lục D (Quy định) Dấu hiệu đáp ứng của máy chủ

Phụ lục E (Quy định) Tải ảnh lên máy chủ

Phụ lục F (Quy định) Sử dụng JPIP trên HTTP

Phụ lục G (Quy định) Sử dụng JPIP với các yêu cầu HTTP và các khai báo TCP

Phụ lục H (Quy định) Sử dụng JPIP trên các giao thức truyền tải khác

Phụ lục I (Quy định) Đánh chỉ mục cho các tập tin JPEG 2000 sử dụng JPIP

Phụ lục J (Quy định) Hồ sơ và các biến thể cho khả năng tương tác và thử nghiệm

Phụ lục K (Quy định) Sử dụng JPIP với các yêu cầu HTTP và các khai báo UDP

Phụ lục L (Tham khảo) Quy trình đăng ký mở rộng cho tiêu chuẩn ISO/IEC 15444-9

Phụ lục M (Tham khảo) Các ví dụ áp dụng

Phụ lục N (Tham khảo) Tập ABNF của JPIP

Phụ lục O (Tham khảo) Tuyên bố bằng sáng chế

Thư mục tài liệu tham khảo

TIÊU CHUẨN QUỐC GIA TCVN 11777-9:2017 (WITH AMENDMENT 5:2014) VỀ CÔNG NGHỆ THÔNG TIN – HỆ THỐNG MÃ HÓA HÌNH ẢNH JPEG 2000 – CÁC CÔNG CỤ TƯƠNG TÁC, GIAO THỨC VÀ API
Số, ký hiệu văn bản	TCVN11777-9:2017	Ngày hiệu lực
Loại văn bản	Tiêu chuẩn Việt Nam	Ngày đăng công báo
Lĩnh vực	Giao dịch điện tử	Ngày ban hành	01/01/2017
Cơ quan ban hành		Tình trạng	Còn hiệu lực

Các văn bản liên kết

Văn bản được hướng dẫn		Văn bản hướng dẫn
Văn bản được hợp nhất		Văn bản hợp nhất
Văn bản bị sửa đổi, bổ sung		Văn bản sửa đổi, bổ sung
Văn bản bị đính chính		Văn bản đính chính
Văn bản bị thay thế		Văn bản thay thế
Văn bản được dẫn chiếu		Văn bản căn cứ

Tải văn bản

Tải văn bản về Bản PDF/Bản gốc