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

Baptiste Coudurier baptiste.coudurier
Mon Jun 7 02:41:04 CEST 2010


On 6/6/10 5:33 PM, Michael Niedermayer wrote:
> On Sun, Jun 06, 2010 at 05:30:57PM -0700, Baptiste Coudurier wrote:
>> On 6/6/10 5:15 PM, Michael Niedermayer wrote:
>>> 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
>>
>> Indeed, nice :)
>>
>>> 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
>>
>> Ok, so can I rename to GRAY8A ? :)
>
> you cannot break ABI/API

This is easy I belive:
#define Y400A GRAY8A under if version < in pixfmt.h
ABI is not changed, values are the same.
Is this right ?

> beyond that i dont really care enough about the color

:)

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list