[Bug 765927] New: new plugin: ICC (International Color Consortium) correction plugin

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=765927

            Bug ID: 765927
           Summary: new plugin: ICC (International Color Consortium)
                    correction plugin
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: fraxinas at opendreambox.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 327203
  --> https://bugzilla.gnome.org/attachment.cgi?id=327203&action=edit
initial add ICC (International Color Consortium) correction plugin

This is my initial proposal for a plugin that does a color correction
correspondingly to the given source (and optionally destination) ICC profile
file with the desired rendering intent (Perceptual, Relative Colorimetric,
Saturation, Absolute Colorimetric)
This conversion uses the library SampleICC which is the ICC's reference
implementation written in c++-

Since the algorithm is very complex (e.g. needs multiple cubic root operations
per pixel) it runs unsuitably slow for video (on my i7 it needs ~2s for every
full hd frame). Therefore i came up with differend methods to speed up the
lookup while still keeping it 100% correct:
1) uncached: will calculate every pixel on the fly with using SampleICC's
CIccCmm::Apply method.
2) precalculated: Precalculate lookup table (of size 2**24) with every given
color->replacement color combination in the entire color space.
3) cached: Allocate an empty LUT, calculate colors using method 1) as they
appear for the first time, then write them to the LUT and next time, check if
they've already been converted

1) may be suited best for single frames
2) may be suited if you have a lot of time before going into PLAYING available
and is going to be the fastest running for high frame rates and resolutions
3) is a compromise between delay before getting READY and conversion time
needed

I could think of another method 4) which would make us of a pre-calculated
binary lookup table that is specific to the selected combination of source and
destination profile and the rendering intent.

The conversion is aware of different RGB component orders, stride and alpha and
should work with all 24bpp x-video/raw RGB subformats and their permutations.

A thinkable issue could be conversion on big endian systems, I haven't tested
that.
Another thing i haven't considered is what happens to pixels that are out of
gamut.
Implementation of YCbCr/YUV or non-24bpp-RGB formats should be possible.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.