Need xyz > RGB conversion for MXFsource avisynth plugin

[sub24ox7]

The only code left undone on this plugin https://code.google.com/p/dcinematools/
Is for xyz to RGB conversion code. Right now it uses openjpeg library if you don't don't own the mainconcept mjpeg2000 dll and that decoder clips blacks with its xyz to rgb conversion. The openjpeg implementation needs the xzy to RGB conversion code. I am sure for some of you this would be trivial to do since it mostly just involves some matrix math and many of you work with avisynth often and this area. This would be a valuable tool if it did this as there is no alternative. I would be VERY appreciative of any of you would be able to help out

[Snowknight26]

Couldn't you use ffmpeg to encode it to RGB? It should be handle MXF files.

[sub24ox7]

Unfortunately there is no support for xyz colorspace in ffmpeg :/ there is literally no option unless someone can work this out

[Yellow_]

yCMS ?

If there was a Openjpeg plugin for Avisynth it would be easy to import video and use yCMS to do YCbCr to xyz to RGB 2.6 gamma in jpeg2000 DCi profiles, using full range levels in video source, where as ffmpeg does a 16 - 235 luma 240 chroma but can do full chroma with necessary swscale flags added.

[sub24ox7]

well right now MXFsource can use openjpeg library if mainconcept isn't present and It fakes the xzy as RGB I believe and that resulting picture isn't clipped its just that teh color is wrong faded looking. Avisynth doesn't support xzy natively:/ will try using ycms matrix on it. If you check in again on this thread post an example yCMS configuration would be great.

ALSO:

I have the correct matrix and Gamma right here to use with the code if someone is ever willing to take on the xyz to (Linear rgb) conversion within MXFSource.cpp

- <color_transformation>
- <transformation name="X'Y'Z' -> Linear RGB" comment="comment line">
  <source color_space="X'Y'Z'" primaries="XYZ" white_point="" gamma="0.3846154" white_projector_luminance="48.0" normalizing_constant="52.37" normalizing_bitrate="12" /> 
  <destination color_space="Linear RGB" primaries="RGB" white_point="" gamma="2.2" /> 
- <matrix>
  <row>3.24096989631653;-1.5373831987381;-0.498610764741898</row> 
  <row>-0.96924364566803;1.87596750259399;0.0415550582110882</row> 
  <row>0.0556300804018974;-0.203976958990097;1.05697154998779</row> 
  </matrix>
  </transformation>
  </color_transformation>

^these parameters are 100% correct

[sub24ox7]

Well I must admit at being surprised at the lack of response here :/ but I know for some of you here coding the color conversion would be trivial. This patch could be used for ffmpeg as well as it lacks the color conversion for mjpeg2000 output as well.

[sub24ox7]

okay code is finished with the help of a friend its perfect code could be used for ffmpeg output of mjpeg2000.

[Mug Funky]

this sounds really exciting actually.

i only just spotted the thread now, but unfortunately can't offer much to it... xyz is a freaky colour space and is not as useful in real life as it is on paper. projectors continue to be mis-calibrated the world over, and even a properly set up projector will change quite quickly as it's bulb(s) die and get dimmer.

adding to this that all film finishing is done in RGB...

[sub24ox7]

Well the Xyz to sRGB is perfect but I have run into some problems I think are to do with the image pitch.
example. It occurs only with 1998 width video as there are only two image widths that are used 2048 and 1998. The 2048 video is displayed correctly, funnily enough avspmod had a bug in version 2.0.8 that looks similar to this bug with mod 2 video except its slanted in the opposite direction and when displayed in 2.0.8 it displays correctly lol. I could just use some hints as to what is causing this and in what direction to look.
<-- bug and the same video displayed correctly -->

[Gavino]

From mxfsource.cpp (function GetFrameOpenJPEG):

    int d_stride = pvf->GetPitch();

    for (int i = 0; i < w * h; i++) {
	unsigned char rc, gc, bc;
	int r, g, b;

	r = image->comps[0].data[w * h - ((i) / (w) + 1) * w + (i) % (w)];
	r += (image->comps[0].sgnd ? 1 << (image->comps[0].prec - 1) : 0);
	rc = (unsigned char) ((r >> adjustR)+((r >> (adjustR-1))%2));
	g = image->comps[1].data[w * h - ((i) / (w) + 1) * w + (i) % (w)];
	g += (image->comps[1].sgnd ? 1 << (image->comps[1].prec - 1) : 0);
	gc = (unsigned char) ((g >> adjustG)+((g >> (adjustG-1))%2));
	b = image->comps[2].data[w * h - ((i) / (w) + 1) * w + (i) % (w)];
	b += (image->comps[2].sgnd ? 1 << (image->comps[2].prec - 1) : 0);
	bc = (unsigned char) ((b >> adjustB)+((b >> (adjustB-1))%2));

	BYTE *pixel = ptr + i * 4;
	pixel[0] = bc;
	pixel[1] = gc;
	pixel[2] = rc;

It looks like it is just writing the pixels one after the other without taking the image pitch into account.
Note that the variable d_stride is not used.

It should be writing the data one row at a time and padding out to the pitch width.

[sub24ox7]

Thank you, this makes since and I have found some information on the subject and should be able to get it to work now
thank you again.

[elmarikon]

Hi guys!

Has anyone got the famous MXFSource to work?!
I found different versions of mxfsource.h & mxfsource.cpp here, but couldn't compile though....

Can anyone help me?
Or has anyone got a working dll=

All the best so long!

SwK

[sub24ox7]

Haha well those were pastebins between my friend and I working on the code to covert the color from XYZ to RGB which is finished. We fixed the bug with non mod 4>= just had to use pitch.
for (int i = 0; i < d_stride/4 * h; i++)
{
if ( i%(d_stride/4) < w )
etc... blah blah.

I will be giving the original code writer the updated code so the page will be updated sometime soon hopefully.
And the source code up there now will not compile unless you comment out the include for the mainconcept jpeg2000 sdk
and all of the places its used. Its all open source now and uses the openjpeg lib.

[hanfrunz]

Hello sub24ox7,

where can i find the latest version of your mxfsource filter? The google code page seems to be outdated. Could you post a working .dll?

regards,
hanfrunz

[elmarikon]

that would be so great!!



pleeeeease!

[StainlessS]

Related thread here:
http://forum.doom9.org/showthread.ph...28#post1576128

[Sparktank]

Really old bump:
But googling, you can see the mxfsource has been forked to GitHub recently:
https://github.com/trollcop/dcinematools

I forked just for archival purposes.

But, looking through some of the files,
it's for old AVS where it still uses YUY2 (no YV16/YV24).

I guess making an ffmpeg lossless intermediate (ffvhuff yuv444p##le) is still the most efficient way?
If I want YV24 output? Or even maybe YCgCo-matrixed output (limited MadVR; etc for things like DS_Kodi, etc etc).
The sacrifice of RGB I can live with.

But the appeal of using Dither_Package is the biggest reason for YV24 output (or YCgCo).

Oooor, would it not be more efficient to convert to RGB with ffmpeg then use Dither_package to get YCgCo.
With 10-bit option (Dither_quantize/Dither_out) ?

Outdated plugins for any type of MXF source (xyz12le, according to ffmpeg) seem deprecated when ffmpeg can do nicely ffvhuff for lossless intermediates.
With ffmpeg_ffvhuff, we also can work easily with ProRes/DVCpro, too.

If anyone were to update mxfsource() to be 2.6 compatible, would that even make a difference at all?
(time not included, given that making a lossless intermediate would, no doubt, take more time)
But, I mean, in terms of efficiency?
Cleaning out bugs to make sure it does what it needs to will take up a developer's time, so I don't want really want to ask anyone to make a proper port for avs2.6/vs.

tl;dr:
Are we happy with ffmpeg_ffvhuff-yv444p##le?

I am, absolutely, all for sharpening my axe twice before hitting that tree once.

[foxyshadis]

Originally Posted by Sparktank

Really old bump:
But googling, you can see the mxfsource has been forked to GitHub recently:
https://github.com/trollcop/dcinematools

I took a look at that; unfortunately, the (custom?) jpeg2000 library the plugin uses was never open sourced, it was just abandoned half-assed and unbuildable.

I wouldn't mind a native plugin, but have you checked whether ffms or lav will work just as well? Assuming j2k, you would want a 16-bit workflow and they should be able to provide. If it's an mpeg2 mxf, it'll always be 8-bit.

Don't bother with YCgCo, unless you specifically need lossless. It's designed to be a high-speed lossless 9-bit colorspace (both chroma channels require one bit more than the RGB input), but true YUV should work better for almost any purpose with a 16-bit workflow. Likewise for using a lossless intermediate codec if you can output to MXF or realtime x264.

[Sparktank]

That is, indeed, unfortunate news.

I haven't tested lates ffms2 builds.
I tried last known 10bit back, but no suitable colorspace can be found.

So far I don't see anything in ffms2 for anything xyz related.

Not much luck googling anything else.