This repository was archived by the owner on Nov 22, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 22, 2021. It is now read-only.
Image manipulation - color transforms does not work #18
Description
On Ginkgo CADx 3.7.1.1573.46 64 bits brightness, contrast modifications and LUT maps does not work at all.
some debug info:
E: error: imagetexture is not a uniform
E: error: lut is not a uniform
E: error: shift is not a uniform
E: error: scale is not a uniform
from glxinfo:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
Activity
gerddie commentedon Apr 13, 2016
Hello,
the original upstream abandoned the project and I'm mostly trying to keep it up to date i.e. to keep it in Debian.
This also means I have not a very deep insight how to use the software, and in this case, how to apply a LUT map. I know that I can change the color scale via the menu Series|Color map, and that these color maps are defined in the "Tools|Settings" dialog in the "Modality settings".
For me this works with some CT data and on the hardware:
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: AMD Radeon HD 6800 Series
OpenGL core profile version string: 4.4.13416 Core Profile Context 8.821
OpenGL core profile shading language version string: 4.40
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
It doesn't work on my laptop though, which uses an Intel GM45 chipset and is at OpenGL 2.1.
Do you happen to see errors in compiling the fragment shader? - because this is what I see on the Intel hardware, and this could mean that the minimum OpenGL shading language version requirement for the used fragment shader is not met.
gerddie commentedon Apr 13, 2016
The fragment shader in question is located in the file cadxcore/vtk/vtkopenglginkgotexture.cpp:997.
Make yet another release. Closes: #18
gerddie commentedon Apr 13, 2016
I will upload a new package of the latest tagged version to Debian unstable the next few days, and also provide a Gentoo ebuild through the imaging overlay. For everything else you're on your own, but compiling is quite straightforward when you have the required dependencies installed.
best,
Gert
boskar commentedon Apr 14, 2016
I'm aware of the extraordinary situation of the project, and I'm willing to help. Unfortunately I can't code.
The original problem occured in Debian on notebook with Intel GPU - the same build is working on nvidia powered Debian, and on the same notebook running Windows 8.1.
I'll try to build current master and use it on my notebook (With Intel's GPU).
gerddie commentedon Apr 14, 2016
Yes, it seems that there is something fishy about the Intel shader compiler on Linux.
Well I already uploaded the new package to Debian unstable. If everything goes well the package should move to Debian/Stretch (i.e. the current testing) within five days.
However, since you reported the bug against 3.7.1 I assume that your are on Debian/Jessie, and I don't think that the packages are sufficiently up-to-date to compile this new version. Specifically, ITK < 4.8 didn't like the -std=c++11 compiler flag that is now required, and certain versions of VTK-6 had a bug which made the creation of the thumbnails impossible.
boskar commentedon Apr 14, 2016
Oh, once again I totally forgot how awesome Debian is and I've been using binary build from http://ginkgo-cadx.com/ .
I downgraded to 3.7.0.1465.37+dfsg-1 from Jessie and it works, although It's slow, much much slower comparing to Windows build (on windows it runs smoothly, on Debian - I need to wait over a second for any brightness update). I'll probably just upgrade to testing or I'll try to backport the package from sid.
gerddie commentedon Apr 14, 2016
I would guess that this older version doesn't use OGL shaders for the color update on linux, because for me on an Intel GM45 chipset a color change happens instantaneously (That laptop is eight years old).
boskar commentedon Apr 14, 2016
.... and It stopped working again in in 3.8.0-1, and I got it back in 3.8.2-1 (Debian/testing with 3.8.2-1 backported). And It's working instantly!
Thanks for Your work! I hope to see the program developped, for my use It lacks just a few very simple features comparing to expensive CE certified client used on workstation (to be specific: SR "modality" viewer and proportions of leght of segments in Cobb angle)
gerddie commentedon Apr 14, 2016
:)
Well, just file issues for each of the features you miss and maybe with a more detailed description. I'm more of a software developer than a medical expert.
I don't know whether I will have time to implement them, but at least they will be recorded, and maybe someone else steps up to implement them. After all the source code is there :)
boskar commentedon Jan 7, 2017
And once again this is an issue in 3.8.3 64 bit in Debian.
I suppose it is because different version was used during compilation and is available on the system.
Probably rebuilding the package on Debian would work.
gerddie commentedon Jan 8, 2017
I can confirm the bug on Gentoo, the shader compiler using the latest version of llvm seems to be more restrictive
E: Fragment shader source compile error
E: 0:1(240): error: no matching function for call to `clamp(float, int, int)'; candidates are:
E: 0:1(240): error: float clamp(float, float, float)
E: 0:1(240): error: vec2 clamp(vec2, float, float)
E: 0:1(240): error: vec3 clamp(vec3, float, float)
E: 0:1(240): error: vec4 clamp(vec4, float, float)
E: 0:1(240): error: vec2 clamp(vec2, vec2, vec2)
E: 0:1(240): error: vec3 clamp(vec3, vec3, vec3)
E: 0:1(240): error: vec4 clamp(vec4, vec4, vec4)
E: 0:1(240): error: int clamp(int, int, int)
E: 0:1(240): error: ivec2 clamp(ivec2, int, int)
E: 0:1(240): error: ivec3 clamp(ivec3, int, int)
E: 0:1(240): error: ivec4 clamp(ivec4, int, int)
E: 0:1(240): error: ivec2 clamp(ivec2, ivec2, ivec2)
E: 0:1(240): error: ivec3 clamp(ivec3, ivec3, ivec3)
E: 0:1(240): error: ivec4 clamp(ivec4, ivec4, ivec4)
E:
E: error: imagetexture is not a uniform
E: error: lut is not a uniform
E: error: shift is not a uniform
E: error: scale is not a uniform
Currect shader call and prepare new release. Closes: gerddie#18