We have re-run a test on our CG246, and the results are exactly as we expect.
We ran a test with both Extended Desktop and with the internal patch generator.

With 'Null Cube' set), and with a Bypass LUT uploaded, both are identical (give or take slight variations due to drift, etc).

I think this proves what we have been saying.
Something looks to be wrong with your workflow - but we have no idea what that would be.

Steve

The reports I sent to you were not as close as your example, but the problem I am seeing on the monitor are not really visible in the report at all. At least for me. Can I somehow measure more greyscale points?

By chance I played around with your free LUTs in Resolve today and I noticed some banding on a shot. Then I applied the "ARRI Log Look LUT based on ACES data" to a ramp to see if it was in the material or an issue with the LUT. Strangely the resulting banding is VERY similar to the banding I get on the Eizo Monitor. Could it be that those things relate to each other somehow?

You can make any profile data set you want using Excel CSV data.
Full info in the on-line User Guides as normal.

See: http://www.lightillusion.com/profiling_manual.html#csv_file
And scroll down a bit to 'USER CUSTOM PATCH SEQUENCES'.

Banding is normally down to the source image not having a large enough bit-depth, combined with changes to the image that exasperate the limited bit depth.

Steve

I will have a look at the custom patches tomorrow.

Just applied the ACES LUT to a 32bit ramp in Nuke. Especially the red channel is very uneven.

All this has nothing to do with the issue you have been describing, where you say a 'Bypass LUT' uploaded into an Eizo that has previously been set to Null via 'Null Cube' upload causes a change in the grey scale?

You seem to have changed tact?
What exactly is the issue you are trying to define?

Steve

I thought the issue with the ACES LUT and the issue with the LUT upload to the monitor might be related, because it looking very similar. And I was hoping that one issue would lead to the answer of the other issue. But if you are sure that they have nothing to do with each other then its fine.

To be honest I am feeling a bit lost. I contacted Eizo for some help and they are reading in this thread as well.
I have no idea what else I could test or change to localize the problem.

No - any creative, or image manipulation LUT will be very different to a Calibration LUT.

The bottom line is that as you can see from the graphs I posted there is no difference at all between the display being set to a 'Null Cube' upload, or having a 'Bypass LUT' uploaded. The results are identical.

For there to be a difference you 'must' have something set incorrectly wither within your image pipeline, or within the display.

Steve

I do no doubt that there is something wrong within our image pipeline or display, but as I said, I am lost at 'what' it could be.
As I wrote in previous posts I tested different setups to localize the issue without success.
Could you give me some hints where else I could look at?
As soon as I have time I will try to write down in detail my setup and all tests I did so far. Maybe that helps to spot the problem

Thanks,
Sönke

Yeah - unfortunately without actually being there, there is not a lot more we can do remotely.

Take everything out of the path, and just use LightSpace directly and focus on just performing a 'Null Cube' Upload, and then upload a Bypass LUT.

Focus on getting the to me no (minimal - as there will be some display change due to drift/heat/etc) changes to the grey scale, or anything else.

All the time you see a change with a Bypass LUT being Uploaded you have an issue that is not normal, as our RGB Balance graphs show.

(Notice there was a difference when we used Extended Desktop compared to the internal Eizo patch generator, due to somethign in the HDMI image path - but both were consistent within themselves - as they should be - with the first two praphs matching, and the last two matching!)

Steve

Hi Steve,
I had/have the same problem with my Eizo CG318-4K, and may have even mentioned it in an e-mail in the past.
I regret to say I gave up on uploading the calibration LUT via LightSpace, and am uploading via Eizo's ColorNavigator NX as a workaround.
In my case as well, Eizo and LightSpace don't play well when it comes to LUT upload...

That makes no sense...
Have you discussed this with Eizo?
Do you have the same issue that a Bypass LUT uploaded after performing a Null Cube cause a change?
The problem Soenke has is very specific in that the above happens to him, which just makes no sense.

Steve

Hello again!
I am still in contact with Eizo. They are asking for a LUT file, that they would like to upload via Colornavigator as a test.
But Colornavigator only reads .3dl and .cub files in 12bit, which I can't export from Lightspace as far as I know.
Is there a way to convert the LUT? Would it be correct if I scale the LUT via Lattice to a range from 0 to 4096?

Thanks,
Sönke

LightSpace exports LUTs in just about all known formats...
Have you checked through them?

Steve

I exported all .3dl variants LS is giving me and sent them to Eizo and I got the feedback that Colornavigator is expecting values between 0 - 4096.

Sönke

And LS will do that...

Steve