[FFmpeg-devel] [PATCH] grayalpha pixfmt + support in pngdec

[Michael Niedermayer]

On Sun, Jun 06, 2010 at 02:51:59PM -0700, Baptiste Coudurier wrote:
> On 6/3/10 2:25 PM, Michael Niedermayer wrote:
>> On Thu, Jun 03, 2010 at 02:22:48PM -0700, Baptiste Coudurier wrote:
>>> On 06/03/2010 02:16 PM, Michael Niedermayer wrote:
>>>> On Thu, Jun 03, 2010 at 12:14:58PM -0700, Baptiste Coudurier wrote:
>>>>> On 06/03/2010 03:45 AM, Michael Niedermayer wrote:
>>>>>> On Wed, Jun 02, 2010 at 05:37:36PM -0700, Baptiste Coudurier wrote:
>>>>>>> On 04/18/2010 03:57 PM, Michael Niedermayer wrote:
>>>>>>>> On Sun, Apr 18, 2010 at 09:36:22PM +0200, Stefano Sabatini wrote:
>>>>>>>>> On date Tuesday 2010-04-13 12:21:47 +0200, Michael Niedermayer
>>>>>>>>> encoded:
>>>>>>>>>> On Tue, Apr 13, 2010 at 10:34:48AM +0200, Andreas ?man wrote:
>>>>>>>>>>> Kostya wrote:
>>>>>>>>>>>> On Tue, Apr 13, 2010 at 09:33:51AM +0200, Andreas ?man wrote:
>>>>>>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>>>>>>> On Mon, Apr 12, 2010 at 09:40:03PM +0200, Andreas ?man wrote:
>>>>>>>>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>>>>>>>>> On Mon, Apr 12, 2010 at 10:43:02AM +0200, Andreas ?man 
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Hi
>>>>>>>>>>>>>>>>> +    [PIX_FMT_GRAYALPHA] = {
>>>>>>>>>>>>>>>>> +        .name = "grayalpha",
>>>>>>>>>>>>>>>> where does the name grayalpha come from?
>>>>>>>>>>>>>>> I just didn't come up with anything better.
>>>>>>>>>>>>>>> Ideas are most welcome.
>>>>>>>>>>>>>> something that is consistent with existing formats would
>>>>>>>>>>>>>> be better also what is it calld in the png docs?
>>>>>>>>>>>>> PNG docs seems to call it "Grayscale with alpha" or "ya".
>>>>>>>>>>>>> Perhaps "ya" would be a good name then?
>>>>>>>>>>>> Nej, it obviously stands for "Y(aka luma) + A(alpha)"
>>>>>>>>>>>> i.e. not so good acronym.
>>>>>>>>>>>
>>>>>>>>>>> Kostya suggested "Y400A" on IRC.
>>>>>>>>>
>>>>>>>>> I'm not very happy with this name, "4XX" notation only makes sense
>>>>>>>>> when we have three components, in this case I would have preferred
>>>>>>>>> something of the kind GRAY8ALPHA8 or GRAYALPHA8 (consistent with
>>>>>>>>> GRAY8), even YA was not that bad.
>>>>>>>>
>>>>>>>> GRAY*ALPHA* is inconsistent with the existing naming and gray8 is
>>>>>>>> quite
>>>>>>>> alone and the exception, not a good example to copy.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not that I consider this a big issue, we will eventually fix the
>>>>>>>>> names
>>>>>>>>> at the next major bump.
>>>>>>>>
>>>>>>>> The naming is good and reasonable consistent. To change it at the 
>>>>>>>> next
>>>>>>>> maj
>>>>>>>> ver
>>>>>>>> bump there needs to be a problem in the existing naming and a better
>>>>>>>> naming and
>>>>>>>> consensus amongth the devels that the new is better and not just the
>>>>>>>> yearly
>>>>>>>> bikeshed style. Because every such change means everyone will have 
>>>>>>>> to
>>>>>>>> update
>>>>>>>> their applications and this is a lot of work when one considers how
>>>>>>>> many
>>>>>>>> applications there are. Not to mention the ones that try to support
>>>>>>>> differnent
>>>>>>>> lav* versions
>>>>>>>>
>>>>>>>
>>>>>>> I need to revive this thread since I've come up with a file that I 
>>>>>>> want
>>>>>>> supported.
>>>>>>>
>>>>>>> I disagree, Y400A is a very bad name since the gray plane is coded
>>>>>>> using
>>>>>>> 0-255 and IMHO is not really similar to a Y plane IMHO in the YUV
>>>>>>> sense,
>>>>>>> if
>>>>>>> you want to call it Y then YJ400A at least.
>>>>>>
>>>>>> the luma range, really is indicated by AVCodecContext.color_range
>>>>>> the J pixel formats are deprecated.
>>>>>
>>>>> Then mark them as so,
>>>>
>>>> done
>>>>
>>>>
>>>>> and start changing the code, because I would
>>>>> personally not remove something that has been in the code so long ;)
>>>>
>>>> changing lavc is not hard but applications need to be changed too
>>>> and i just now marked it as deprecated ...
>>>> maybe we can add YJ400A as an intermediate workaround because the other
>>>> formats where not correctly marked as deprecated as i thought they where
>>>
>>> Whatever, I'm against this name, stefano as well.
>>> Shall we start a vote ?
>>
>> yes of course ;)
>> but first we should wait 48h for people to propose options
>>
>> currently we have
>> YJ400A
>> GRAY8A
>> GRAY8ALPHA8
>> GRAYALPHA8
>
> GRAY8A input support in libswscale :)
[...]

> @@ -1062,6 +1063,14 @@
>      }
>  }
>  
> +static inline void gray8aToA(uint8_t *dst, const uint8_t *src, long width, uint32_t *unused)
> +{
> +    int i;
> +    for (i=0; i<width; i++) {
> +        dst[i]= src[2*i];
> +    }
> +}

extract_even() or yuy2ToY() i think does this

except that it looks ok, i assume its tested
swscale_example based testing would be ideal but hard if we only support input
without output

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100607/2ac3b100/attachment.pgp>