Quote:
Originally Posted by cyberbeing
Can you add more format support for applycal?
CAL data from a TI3 file (Argyll Device Calibration State)?
|
I never realized this differed from the .cal file. I'll add support for it soon enough.
Note: As a “feature” of the current coding, all you have to do is change the first line of a .ti3 file to “CTI3” to “CAL” and applycal will accept it.
Would depend on the format in question. If I don't have access to a freely available documentation and a few sample cases for it, it's unlikely.
I'm probably adding ICC profile support sometime around version 1.0.
Quote:
|
The currently loaded CLUT?
|
I don't know how to access those.
Quote:
|
applycal from version 0.4 is now extremely slow. Is that because of working in 64-bit floating point or is it a bug? After 30 minutes went by I just gave up and killed it. If it's going to be that slow, I hope you can optimize or multi-thread it. Maybe you could port it to OpenGL GLSL shader code and run it on the GPU.
|
That has to be a bug, it runs in a few seconds on my CPU. How many entries does your .cal file have?
Quote:
Originally Posted by madshi
Yeah, an 8bit 3dlut is probably not good enough. yCMS also internally uses 64bit floats for calculation and then rounds that down to 16bit integer for output. I wouldn't use anything less than 16bit integer output. It's debatable, though, whether input must be 8bit. madVR/yCMS can also use 7bit or 6bit input, to save space and improve performance, on the cost of a very small (probably not visible) drop in quality.
|
How do you properly pull down to a limited range 6-bit or 7-bit integer? I can't right shift 235 any further without cutting bits off. Is that just what I should do?