[Bug 783591] openjpegdec: doesn't support grayscale with alpha

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=783591

--- Comment #14 from Aaron Boxer <boxerab at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #13)
> Review of attachment 353729 [details] [review]:
Thanks for the review

> 
> ::: ext/openjpeg/gstopenjpegdec.c
> @@ +425,3 @@
> +      tmp[1] = off[0] + (*data_in[0] << shift[0]);
> +      tmp[2] = tmp[1];
> +      tmp[3] = tmp[1];
> 
> Why are you generating something like RAGB here, i.e. alpha on the second
> component and all other components the same value?

I assume that alpha is always in the last component : component == 1. Since
format is ARGB, and tmp[0] stores alpha in output, we need tmp[0] =  off[1] +
(*data_in[1] << shift[1]);


> 
> @@ +888,2 @@
>        if (image->numcomps == 4) {
> +        /* alpha:  0 == colour channel, 1 == non-pre-multiplied alpha, 2 ==
> pre-multiplied alpha */
> 
> This comment seems wrong for numcomps==4, and also above

In the comment, alpha is referring to image->comps[c].alpha. If the value of
image->comps[c].alpha is zero, then c is a colour channel. Otherwise, it is an
alpha channel. I will make this clearer.


> 
> @@ +903,3 @@
> +          return GST_FLOW_NOT_NEGOTIATED;
> +        }
> +        if (alpha_channel != 3) {
> 
> If it's elsewhere, that seems to require only a minimal change to the
> conversion function or using e.g. BGRA instead of ABGR.

The code previously was assuming that alpha is always the last channel in the
input; just making this assumption explicit :)  I don't think input frames have
alpha in the first channel ?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.