Spec allows >8bit depth in Golomb-Rice mode but nothing can make this

[dwbuiten]

The reference encoder cannot produce Golomb-Rice coded content that has a bit depth greater than 8, but the spec allows it.

One of the two should be fixed, or it's a risk of defining files that don't exist in real life.

[michaelni]

The implementation, that is both encoder and decoder have hardcoded limits of 8bit in the bias computation (which is then stored in 8bit). These limits seem not optimal when there are alot more than 8bits per sample. Theres also an issue with the golomb coder at 14bits and above.
So i would say its probably better for now to disallow this in the spec. We can always undo that OR decide to standarize a different solution for >8bps

[dwbuiten]

Since it reflects reality, I'm on board with a bit of clear info in the spec to say it isn't allowed.

(If it's there, I missed it...)

[JeromeMartinez]

[...] or it's a risk of defining files that don't exist in real life.

Generally speaking, I am not in favor of not defining files that don't exist in real life, as we extend sometimes the encoder or decoder without touching the spec, e.g. we have 9-bit support for all but grey & RGBA, 12-bit support for some color spaces only, 14-bit for only 1 color space, due to limitations in the list of pixel formats supported by the whole tool (so more complex to add these color spaces to the encoder) but we could add the support later (or in another encoder). Current wording in the spec permits to easily implement additional bit depth & color space mix. In my opinion different solutions should be reserved to a new version (when there is no big change, e.g. Bayer is a completely different color space without any definition in the spec, so we could extend v3 for that).

That said, and for this case, I may be in favor of exceptionally limiting Golomb-Rice to 8-bit, as we have Range Coder for all bit depths and we should limit our work, so limiting new work to Range Coder only.

BTW, I am wondering the historical reason Golomb-Rice exists in FFV1, as the focus seems to be on Range Coder (the start of the bistream is always with Range Coder). Would it make sense to consider Golomb-Rice as legacy and limit it to what exists only e.g. we would forbid it in v4 and/or Bayer?