Expose an API about dssim HOT 11 CLOSED

The API is sort-of exposed. Have a look at dssim.h

from dssim.

I did have a look, but I'd rather not need to create a dssim_image, and let all video conversion handling happen in gstreamer, as it will be more optimized and offer more possible conversions.

from dssim.

I'm not sure if I understand.

You can't avoid creating dssim_image structure, because you have to describe image dimensions and pixel layout to dssim.

dssim internally supports only pixels in floating point in range 0..1, and it can't operate on anything else.

I presume you have pixels in 8-bit YCbCr. You can use dssim_create_image_float_callback to convert image on the fly row by row. This will avoid need for a full-screen buffer.

from dssim.

The idea is that gstreamer has all the necessary routines to convert between different formats, the most flexible solution for our use case would be an interface such as

double compare (uint8 * data, uint32 width, uint32 height);

, that would only handle data in the lab colorspace. This means on the gstreamer side we would only need to do one conversion (possibly none if our input data is already in the lab colorspace), and spare us the need for an extra memcpy.

from dssim.

dssim can't be calculated on uint8 pixels. The algorithm needs to apply very precise blur and square the values, and 8 bits is not enough for this.

from dssim.

It's just a fancy way to talk about a bitmap, one pixel would be 4 uint8 in
the lab colorspace if I'm not mistaken

On Thu, Jun 18, 2015 at 8:47 PM, Kornel [email protected] wrote:

dssim can't be calculated on uint8 pixels. The algorithm needs to apply
very precise blur and square the values, and 8 bits is not enough for this.

—
Reply to this email directly or view it on GitHub
#12 (comment).

from dssim.

If your bitmap's pixels are struct {unsigned char l, a, b;} in 0..255 range then dssim won't need to do colorspace conversion, but will still have to convert uint8s to floats. This was theoretically available via dssim_create_image() with DSSIM_LAB color, but buggy - fixed in 0dcfde5.

If your bitmap's pixels are struct {float l, a, b;} in 0..1 range, then dssim can use it without conversion, but will still do memcpy (but only row-by-row, which should fit in cache). This is available via dssim_create_image_float_callback().

It will do chroma subsampling by itself unless you disable it via dssim_set_color_handling. There's no API to specify subsampled bitmap.

If you want to avoid memcpy, then the only way would be for you to provide image as 3 separate bitmaps (dssim doesn't work on interleaved LAB pixels, but on "grayscale" bitmaps for each channel separately).

So the API would be:

dssim_create_image(float luma[], int width, int height, float a[], float b[], int chroma_width, int chroma_height);

from dssim.

OK, I'll go the easy way for now, however one would need to allow for making a dynamic library and ideally offer pkg-config files, would you be OK for an alternate build system using meson (https://github.com/mesonbuild/meson) ?

from dssim.

I haven't used meson, but I don't mind accepting it as an option.

from dssim.

I'm also planning to add a Rust API. If you use Rust/cargo then it'd be another solution.

from dssim.

Cool, I plan to wrap it in C as a gstreamer plugin, I've submitted a pull request @ #13 :)

from dssim.