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ó.

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á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"

• "tkhd"

• "mdhd"

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

• "stsd"

• "stts"

- 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;

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:

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 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.

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ũ.

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Ụ:

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.

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.

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á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.

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.

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'.

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.

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).

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.

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.

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.