[FFmpeg-devel] [PATCH]libopenjpeg 64bit encoding

[Michael Bradshaw]

On Fri, Jan 13, 2012 at 9:14 AM, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:

> Michael Bradshaw <mbradshaw <at> sorensonmedia.com> writes:
>
> > @@ -219,7 +224,7 @@ static int libopenjpeg_copy_rgb16(AVCodecContext
> > *avctx, AVFrame *frame, opj_ima
> >
> > Just a thought: libopenjpeg_copy_rgb16 should probably be renamed to
> > libopenjpeg_copy_rgba16.
>
> ?
> It is used for RGB48 which has no "a" channel.
>

Which is why I thought the name was fine originally.  But now with this
patch it would support RGBA as well.  I just like having the 'a' in the
name because it makes it more explicit what it is (i.e. is it rgba or
argb?).  If we move copying gray to copy_yuv() (see comment below), the
numcomps parameter in copy_rgba() could be changed to a boolean has_alpha,
which seems more natural for this function than does passing the number of
channels.  I could be over-engineering though.  You thoughts?


> >  Also, would you be opposed to renamin> libopenjpeg_copy_rgba to
> > libopenjpeg_copy_rgba8, seeing as we now have two versions of the
> function and
> > it'll clarify which one it is?
>
> I wanted to suggest to rename it to libopenjpeg_copy_rgb8() although it is
> also
> used for GRAY8 - do you have a better suggestion?
>

I'm wondering if we should create another copy function specifically for
gray (i.e. libopenjpeg_copy_gray8), or perhaps use the libopenjpeg_copy_yuv
function (and just set numcomps to 1).  Personally, I'm leaning towards
using the yuv function, as another semi-redundant function wouldn't need to
be created, and it seems like a more natural place to copy a gray channel
than in the rgb copier (in hindsight, I'm not sure why I didn't do this in
the beginning).  libopenjpeg_copy_rgba() could still be renamed to
libopenjpeg_copy_rgba8().  Your opinion?


> Do you think the patch is useful overall?
> It would currently allow reencoding tif -> j2k on le, dpx/sgi -> j2k on be,
> colour transformations will probably be supported in the future.
>

 I think so, yes.  Flexibility and lots of supported formats were one of my
main goals with this encoder (something much easier to achieve with this
one than with j2kenc), and you've certainly been helping with that lately :)

Michael