[x265] HEVC for 32bits 30channel images?

[Steve Borho]

On Fri, Feb 14, 2014 at 9:31 AM, Roozbeh Fazl <roozyfx at gmail.com> wrote:

> I want to use HEVC to compress a set of openEXR files I have. OpenEXR is a
> high dynamic range (HDR) image file format. These files are 32bit, 30
> channels, i.e. an image has 30 different spectral(color) channels and a
> pixel in each channel is stored by 32bits.
>
> I want to consider these images as frames in a 'video' and then encode
> this video using HEVC, to benefit from high compression ratio. Next I want
> to have random access to this openEXR-HEVC-coded "video", so that I can
> quickly and easily read any pixel of any image in my original dataset.
> Obviously pixels' bit depth and color-space of my images are different
> from what is supported by HEVC by default, and I know HEVC is designed for
> something else. Still, do you guys think this is possible or say there's a
> theoretical barrier or sth like that to it?
>
> I'm in computer graphics and don't have an in depth knowledge of video
> coding, so I cannot see beforehand if there is a theoretical barrier to
> what I want to do or not.
>
> Preferably I want to do this as simple as possible: add support for
> reading my input format and some tweaks and change of values here and
> there, and tearing x265 implementation inside-out and rewrite everything
> from scratch.
>

Hello Roozbeh,

I'm not entirely sure how to respond, but in general I can say that HEVC is
pretty closely related to H.264 in the way it deals with pixels.  The spec
only supports pixel samples of 8, 10 (and 12 once the Range Extension work
is finalized).  There's no support for anything close to 32bits, and even
with the ongoing REXT work they are only adding 4:4:4 and 4:2:2, the same
as H.264.

So to encode your video with HEVC the input pixels must be down-sampled to
3-channel 10/12bit 4:4:4.  x265's support for 4:4:4 is not quite yet in the
public tree but will be soon.

Modifying the encoder to deal directly with the 32bit 30 channel raw pixels
would be counter-productive for the most part, since they must be coded as
10/12bits.

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140214/2c5d9910/attachment.html>