There are many different aspects to consider when extracting frames to make a new object, to ensure that the new image remains a fully valid SOP Instance, and the following is a non-exhaustive list of important issues
The Number of Frames (0028,0008) attribute will need to be updated.
Any attributes that refer to start and end times such as Acquisition Time (0008,0032) and Content Time (0008,0033) must be updated to reflect the new start time if the first frame is not the same as the original. This is typically the case where the multi-frame object is a “video” and where the first frame is not included. Likewise, Image Trigger Delay (0018,1067) may need to be updated.
The Frame Time (0018,1063) may need to be modified if frames in the new image are not a simple contiguous sequence from the original, and if they are irregular, then the Frame Time Vector (0018,1065) will need to be used in its place, with a corresponding change to the Frame Increment Pointer (0028,0009). This also needs careful consideration if non-consecutive frames are requested from an image with non-linearly spaced frames.
Identifying the location of the requested frames within an MPEG-2 data stream is non-trivial, but if achieved, then little else other than changes to the starting times are likely to be required for MPEG-2 encoded data, as the use-cases for such encoded data (e.g. endoscopy) are unlikely to include explicit frame related data. See the note below however for comments on “single-frame” results.
An application holding data in MPEG-2 format is unlikely to be able to create a range with a frame increment of greater than one (a calculated frame list with a 3 rd value greater than one), and if such a request is made, it might return a status of AA02 : Unable to extract Frames.
The approximation feature of the Time Range form of request is especially suitable for data held in MPEG-2 form, as it allows the application to find the nearest surrounding key frames, which greatly simplifies editing and improves quality.
Similar issues exist as for MPEG-2 data and similar solutions apply.
It is very important that functional groups for enhanced image objects are properly re-created to reflect the reduced set of frames, as they include important clinical information. The requirement in the standard that the resulting object be a valid SOP instance does make such re-creations mandatory.
Images of the Nuclear Medicine SOP class are described by the Frame Increment Pointer (0028,0009) which in turn references a number of different “Vectors” as defined in Table C.8-7 in PS3.3. Like the Functional Groups above, these Vectors are required to contain one value for each frame in the Image, and so their contents must be modified to match the list of frames extracted, ensuring that the values retained are those corresponding to the extracted frames.
The requirement that the newly created image object generated in response to a Frame level retrieve request must be the same as the SOP class will frequently result in the need to create a single frame instance of an object that is more commonly a multi-frame object, but this should not cause any problems with the IOD rules, as all such objects may quite legally have Number of Frames = 1.
However, a single frame may well cause problems for a transfer syntax based on “video” such as those using MPEG-2, and therefore the SCU when negotiating a C-GET should consider this problem, and include one or more transfer syntaxes suitable for holding single or non-contiguous frames where such a retrieval request is being made.