PNG Sequence resulting in garbled image.

[pleribus]

I'm having trouble ingesting any sort of uncompressed inage or video format. I'm not sure if this is an ubuntu / ffmpeg issue or if it resides with the transform process.

Attached is an image showing result of ingesting a PNG 5120 x 5120 360 TB stereo image.

It works fine if we first convert the sequence to JPG or convert the uncompressed QT to H265/H264 before ingesting, but then we are introducing encoding artifacts before running it through this transform process.

Any assistance appreciated.

[susiesu2]

Can you provide the original file you uploaded please?

[pleribus]

I can't provide the original for the one above due to it being for a project in development (under strict NDA), but here is another unrelated sample that exhibits same results.

https://www.dropbox.com/s/17kyd5mmebagyj6/results.zip?dl=1

And command line that is used:
ffmpeg -i ~/in.png -vf transform360="input_stereo_format=TB:cube_edge_length=1280:output_layout=CUBEMAP_23_OFFCENTER:cube_offcenter_z=-0.5" ~/out.png

Again, converting to jpg first then works fine.

[puffpio]

What bit depth is the color of the PNG? transform360 only works on 8bpp at the moment

…

On Wed, Nov 22, 2017 at 4:46 PM pleribus ***@***.***> wrote: I can't provide the original for the one above due to it being for a project in development (under strict NDA), but here is another unrelated sample that exhibits same results. https://www.dropbox.com/s/17kyd5mmebagyj6/results.zip?dl=1 And command line that is used: ffmpeg -i ~/in.png -vf transform360="input_stereo_format=TB:cube_edge_length=1280:output_layout=CUBEMAP_23_OFFCENTER:cube_offcenter_z=-0.5" ~/out.png Again, converting to jpg first then works fine. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALS3VWLoJFKdTbIVqcm6nPxS43gdIWqks5s5MB4gaJpZM4QoHSg> .

[pleribus]

Yeah, image depth is 8bpp

[badtrip987]

Any update on this issue? I'm having the same problem.

[kcircnc]

We are still looking into this. In the mean time please use transform_v1 for png I/O. Confirmed that png works well with ffmpeg -i ~/in.png -vf transform_v1="input_stereo_format=TB:cube_edge_length=1280" out.png

[kcircnc]

If you need features only supported in transform360 but not transform_v1, a temp hack would be to use lossless jpeg to re-wrap your input png into jpg before you feed it into transform360.
You would need either libopenjpeg or j2k enabled in your ffmpeg to encode lossless jpeg.

[badtrip987]

Thank you!

[badtrip987]

Is there any compression applied to the image while it's being transformed? I use the bmp format to output a lossless image and i'm seeing heavy compression blocking. Here's a screenshot.

Source is a DNXHR-HQ 8bit ( shown on the left ) and output is a bmp ( shown on the right )

transform360="input_stereo_format=MONO:cube_edge_length=1536:interpolation_alg=lanczos4:enable_low_pass_filter=1:enable_multi_threading=1:num_horizontal_segments=64:num_vertical_segments=30:adjust_kernel=1"

[kcircnc]

Transform360/transform_v1 are filters that resample pixels from the input image. So there will be quality degrade when the sampling density is lower then the original (the same effect one will find in downscaling an image).

[badtrip987]

Is there a proven workflow that provides the best quality?

[jchwei]

I think the problem is that: Transform360 cannot apply on images which have packed pixel format (e.g. RGB24: 8:8:8 ) . Transform360 generates map based on planar pixel format (e.g. YUV420P: plane[0] for Y, plane[1] for U and plane[2] for V) . RGB24 is packed pixel format, which stores all data in ffmpeg frame->data[0] .

At least, the Transform360/vf_transform360.c should add query_formats for AVFilter, refer to fillborders filter.

static int query_formats(AVFilterContext *ctx)
{
    static const enum AVPixelFormat pix_fmts[] = {
        AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P,
        AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P,
        AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUV420P,
        AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
        AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P,
        AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
        AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
        AV_PIX_FMT_YUV420P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV440P12,
        AV_PIX_FMT_YUV420P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV444P14,
        AV_PIX_FMT_YUV420P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV444P16,
        AV_PIX_FMT_YUVA420P9, AV_PIX_FMT_YUVA422P9, AV_PIX_FMT_YUVA444P9,
        AV_PIX_FMT_YUVA420P10, AV_PIX_FMT_YUVA422P10, AV_PIX_FMT_YUVA444P10,
        AV_PIX_FMT_YUVA420P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA444P16,
        AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10,
        AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,
        AV_PIX_FMT_GBRAP, AV_PIX_FMT_GBRAP10, AV_PIX_FMT_GBRAP12, AV_PIX_FMT_GBRAP16,
        AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9, AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12, AV_PIX_FMT_GRAY16,
        AV_PIX_FMT_NONE
    };
    AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
    if (!fmts_list)
        return AVERROR(ENOMEM);
    return ff_set_common_formats(ctx, fmts_list);
}

AVFilter ff_vf_transform360 = {
    .name        = "transform360",
    .description = NULL_IF_CONFIG_SMALL("Transforms equirectangular input video to the other format."),
    .init_dict   = init_dict,
    .uninit      = uninit,
    .priv_size   = sizeof(TransformContext),
    .priv_class  = &transform360_class,
    .query_formats = query_formats,
    .inputs      = avfilter_vf_transform_inputs,
    .outputs     = avfilter_vf_transform_outputs,
};