Clarify supported values of NewSubfileType tag in OME-TIFF specification

[sbesson]

The storage section of the OME-TIFF specification for sub-resolutions includes the following statement

the NewSubFileType TIFF tag 254 for each pyramidal level should be set to 1 to distinguish full-resolution planes from downsampled planes.

As per the [revision 6.0 of the TIFF specification](https://download.osgeo.org/libtiff/doc/TIFF6.pdf page 36),

         NewSubfileType

         A general indication of the kind of data contained in this subfile.

         Tag = 254 (FE.H)

         Type = LONG

         N = 1

         Replaces the old SubfileType field, due to limitations in the definition of that field.

         NewSubfileType is mainly useful when there are multiple subfiles in a single
         TIFF file.

         This field is made up of a set of 32 flag bits. Unused bits are expected to be 0. Bit 0
         is the low-order bit.

         Currently defined values are:

Bit 0    is 1 if the image is a reduced-resolution version of another image in this TIFF file;
         else the bit is 0.

Bit 1    is 1 if the image is a single page of a multi-page image (see the PageNumber field
         description); else the bit is 0.

Bit 2    is 1 if the image defines a transparency mask for another image in this TIFF file.
         The PhotometricInterpretation value must be 4, designating a transparency mask.

         These values are defined as bit flags because they are independent of each other.

         Default is 0.

The statement in the TIFF specification is thus not full correct. To distinguish full-resolution planes from downsampled planes, the bit 0 of the NewSubFileType should be set to 1. Other bits can be set independently, especially the bit 1 may be set to different values to differentiate single page from multi-page image. This is consistent with original recommendations of the OME005 design document for the extension of the OME-TIFF specification :

The TIFF extension tag SubIFDs must be used to specify sub-resolution image directories. The reducedimage bit of the Baseline tag NewSubfileType must be used to distinguish full-resolution images from reduced-size images; the page bit may optionally be set when appropriate

The statement about the NewSubfileType tag was discussed in the PR updating the OME-TIFF specification. As this was a note to come back to clarify these terms. However, there was no follow-up until this date.

Given the current terms of the specification are not 100% correct since a value of 1 is sufficient but not necessary to distinguish full-resolution planes from downsampled planes, I would propose to use this opportunity to clarify the OME-TIFF specification.

Options are:

1. keep 1 as the only recommendation for the NewSubfileType for sub-resolution IFDs independently of the single-page/multi-page status. Clarify this implies the reduced resolution is a single image as per the TIFF specification
2. modify the language to state the bit 0 of the NewSubFileType TIFF tag 254 must be set to 1. This is consistent with the language of the TIFF specification, the design document and the PR review linked above
3. in addition to 2., also indicate the bit 1 may be set appropriately depending whether there are multiple primary IFDs and that the values might be 1 or 3 depending on the scenario.

Option 1 is the most conservative approach but goes against the language of the original design proposal and may reduce the compatibility with other applications that would expect NewSubfileType values with the bit 1 set to 1. Additionally, given the NewSubfileType tag can take more values than 0 and 1, it leaves the language ambiguous on what a value of 3 would imply for the OME-TIFF specification. Would it be still valid but not recommended or not valid?

Option 2. and 3. makes these scenarios unambiguous, is consistent with the original proposal and possibly improves compatibility with other tools. The biggest impact would be on any client which would read the value of NewSubfileType of sub-resolution IFDs of an OME-TIFF and validate it be strictly equal to 1 as they would need to be adjusted to restrict the check on bit 0.

For reference, this issue was raised in the context of Glencoe's work on glencoesoftware/raw2ometiff#145 which currently implements option 3 i.e. setting the value of the NewSubfileType tag to 0 or 2 for full-resolution IFDs and 1 or 3 for sub-resolution IFDs.

[sbesson]

Separately of the technical consideration, we have been discussing the process of updating the OME-TIFF specification as part of the @ome/formats weekly meeting and at the 2025 OME-NGFF workshop.

One consideration was to make use of the existing RFC process for the OME-Zarr specification to propose changes against any OME file format. In discussions with @joshmoore @jo-mueller @clbarnes, we were balancing the value of using an established community based workflow versus its overhead for a change which primarily aims to address the clarity of the language in a specification documentation where no new developments are currently planned.

The current proposed next steps are to:

1. open a Pull Request against this repository implementing the changes proposed in option 3
2. reference this Pull Request and the original issue describing the rationale in an image.sc post to allow dissemination and feedback from a wider community
3. give a timeline of a few weeks allowing for people to comment using either image.sc or GitHub
4. aim towards a clarification of the specification before the end of the calendar year