[FFmpeg-devel] [PATCH] grayalpha pixfmt + support in pngdec
Baptiste Coudurier
baptiste.coudurier
Tue Sep 28 00:25:22 CEST 2010
On 06/06/2010 05: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
>
> 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
Changed and applied. Let's forget about the rename to GRAY8A for now.
I'll come back to that when I feel like it.
--
Baptiste COUDURIER
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel
mailing list