2017-09-27 15:33 GMT+02:00 Tom Butterworth <bangno...@gmail.com>: > > > > On 27 Sep 2017, at 14:20, Martin Vignali <martin.vign...@gmail.com> > wrote: > > > > 2017-09-27 13:25 GMT+02:00 Tom Butterworth <bangno...@gmail.com <mailto: > bangno...@gmail.com>>: > > > >> > >> > >>> On 27 Sep 2017, at 11:59, Martin Vignali <martin.vign...@gmail.com> > >> wrote: > >>> > >>>> > >>>>> + ctx->tex_fun = ctx->dxtc.rgtc1u_block; > >>>>> + avctx->pix_fmt = AV_PIX_FMT_RGB0; > >>>> > >>>> The rgtc1u_block function places the single channel value in every > >> channel > >>>> except the alpha channel > >>>> The pixel format you have chosen is one which disregards the alpha > >> channel > >>>> > >>>> The output of this alpha-only decoder should be in the alpha channel > of > >> a > >>>> pixel format which carries alpha. Probably other channels should have > >> zero > >>>> values. > >>>> > >>>> > >>> Hi Tom, > >>> > >>> After Carl answer, and thinking about that, > >>> The goal of HapAlphaOnly, is to store alpha, but can also store gray > only > >>> (much better than HAP) > >>> In fact, it can be call HAP Gray ! > >> > >> But it isn’t > >> > >>> For example from my part, i would like to use this codec, for matte, > but > >>> also for gray only layer (use with color blending) > >> > >> This is fine, but let’s concentrate on supporting Hap Alpha Only, not > your > >> non-standard use of it. If you would like this flexibility in Hap, that > >> should be argued for on the Hap project, not within FFmpeg. > >> > >> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and > the > >> implementation in FFmpeg must follow the definition (see > >> https://github.com/Vidvox/hap/blob/master/documentation/ > HapVideoDRAFT.md < > >> https://github.com/Vidvox/hap/blob/master/documentation/ > HapVideoDRAFT.md <https://github.com/Vidvox/hap/blob/master/documentation/ > HapVideoDRAFT.md>> > >> ). > >> > >> The Alpha Only encoder and decoder must ingest and emit a pixel format > >> which carries alpha. It may be that adding a new alpha-only pixel > format is > >> not seen as desirable, in which case an existing format with alpha > should > >> be selected. This allows users to, eg, transcode from an RGBA format to > Hap > >> Alpha Only and have the channel they expect be preserved from the input > >> video. Any other behaviour (eg having RGB converted to grey and then > stored > >> as alpha) is not acceptable. > >> > >>> If a user want to compress a gray picture, it can be done using RGB to > >> Gray > >>> conversion > >>> And if user want to compress only alpha or a specific channel, i think > >>> ffmpeg have a filter for that (extractplanes (untested)), > >> > >> Your non-standard usage can still be achieved by channel switching in a > >> filter, the default behaviour must be according to the standard, which > is > >> to encode and decode the alpha channel. > >> > >> Cheers - Tom > >> <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel < > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>> > >> > > > > > > Ok, in that case, the HAP Alpha Encoding current patch is fine (it take > > alpha from RGBA input) > > I will change the 24 to 32 as requested and send a new patch > > > > Before sending a new patch for the decoding : > > did you think, it's better to have [255,255,255, alpha] or [0,0,0, alpha] > > for RGTC1 alpha decoding in RGBA ? > > Personally I’d think 0 to allow further operations to eg combine the image > with one with colour channels to work as expected. > > Ok, i will do that, so i can have the same decoding func in texture dsp that the one use for hapqa_decoding.
Martin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
