Hình K.1 - Cấu trúc dữ liệu đáp ứng trên kết nối http-udp

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

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.

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

Quá trình đăng ký bao gồm các yếu tố sau đây.

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.

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

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

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

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.

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

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.

Đố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ị.

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.

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

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.

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.