[FFmpeg-devel] [PATCH] Add FITS Encoder

[Paras Chadha]

On Mon, Jul 24, 2017 at 3:42 AM, Carl Eugen Hoyos <ceffmpeg at gmail.com>
wrote:

> 2017-07-21 20:16 GMT+02:00 Reimar Döffinger <Reimar.Doeffinger at gmx.de>:
> > On 21.07.2017, at 16:26, Paras Chadha <paraschadha18 at gmail.com> wrote:
> >
> >> On Fri, Jul 21, 2017 at 3:27 AM, Carl Eugen Hoyos <ceffmpeg at gmail.com>
> >> wrote:
> >>
> >>> 2017-07-20 21:46 GMT+02:00 Paras Chadha <paraschadha18 at gmail.com>:
> >>>
> >>>> +            case AV_PIX_FMT_RGB24:
> >>>> +            case AV_PIX_FMT_RGBA:
> >>>> +                for (k = 0; k < naxis3; k++) {
> >>>> +                    for (i = 0; i < avctx->height; i++) {
> >>>> +                        ptr = p->data[0] + (avctx->height - i - 1) *
> >>> p->linesize[0] + k;
> >>>> +                        for (j = 0; j < avctx->width; j++) {
> >>>> +                            bytestream_put_byte(&bytestream,
> ptr[0]);
> >>>> +                            ptr += naxis3;
> >>>
> >>> (Sorry if this is nonsense:)
> >>> Shouldn't you be using PIX_FMT_GBRP and PIX_FMT_GBRAP?
> >>>
> >>
> >> No, the current pixel formats are working fine. I have tested using GIMP
> >> too. It is showing all the RGB images (and others too) correctly.
> >
> > I think that's not what he meant.
> > You are explicitly requesting a packed format that has the data in
> > RGBRGBRGB... order, and you then need these loops to split it into
> > RRRR... GGGG... BBBB...
> > He's suggesting you should simply request the format storing the data
> like that
>
> Yes, this makes above code both simpler and (on typical hardware)
> always faster (it will never be slower, no matter the hardware).
>

Yes, done. It has made the code a lot simple, thanks.


>
> > then all you need to do is the unsigned -> signed conversion
>
> Which is not necessary for the above case.
>
> Carl Eugen
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>