Question: Licensing, and using this in my own QML photo editor

[CarVac]

Yesterday I tried 30 bit mode on my machine and while window decorations in Unity were horribly ugly, everything else seemed to work fine---except that everything was still in 8-bit mode, including my own photo editor Filmulator (https://github.com/CarVac/filmulator-gui).

So...you don't have a license listed. I'd love to be able to use this for 30-bit support on my GPL editor.

And should license stuff be compatible, how do I make Filmulator use it? Do I need to use your main.cpp as a reference? How does it fall back when used in a 24-bit desktop environment?

I'm on lunch so I haven't tried it in depth; it seems I need to get FreeImagePlus first before it'll compile.

[erikhvatum]

Apologies for not noticing your query earlier. For now, because there is still some copied+paste+modified in the StackStream source, I have to stick with the Qt licensing terms. So, you have your pick of GPL 2.1, GPL 3, or LGPL 2.1 :) I'll add copyright boilerplate my sources soon. If I ever get around to reimplementing the bits lifted from Qt, I'll switch to MIT or BSD license, which would remain compatible with your GPL editor.

I made a series of (sometimes rambling blog posts)[http://esoerik.blogspot.com/2015/12/doing-anything-significant-whatsoever_31.html] as I figured out how to get 30-bit color working in Qt/QML. I'm off to dinner now, but I'd be happy to fill in details or perhaps make a fork of your project with 30-bit support grafted on, if you like.

FYI, KDE5 (or whatever they call it) with compiz as the compositor works quite well. The emerald decorator requires a patch to make shadows work correctly, but even without it, it's pretty serviceable.

[erikhvatum]

Re 24-bit fallback, nothing bad seems to happen if, as you make a QML view or QOpenGLWidget, you specify a QSurfaceFormat that is 30-bpp when only 24-bpp is available. Qt silently falls back to 24. However, specifying 30-bit internal texture formats when uploading texture data to the GPU when 30-bit textures are not supported should cause a GLError (I think).

Using 30-bit textures on a 24-bit display would typically reduce performance without benefit, which may be reason enough to 30-bit mode a compile time setting or to select between 24-bit and 30-bit code paths at run time.

[CarVac]

Thanks for the response.

I've been trying to get StackStream working on my end but FreeImagePlus is eluding me; the version in the Ubuntu repositories is 3.15 (current is 3.17) and is missing some methods, and for some reason compiling that from source isn't working for me.

Any advice?

[erikhvatum]

It might be easiest to chuck out my FreeImagePlus code and use libtiff directly.

Alternatively, build all of FreeImage and FreeImagePlus. Let me try that...

Interesting. FreeImage 3.17 does indeed fail to compile with gcc 5.1+. However, I'm using Arch, which is built with gcc 5.3, and I have freeimage 3.17 installed. Soo....

Ah, looking at the Arch build script reveals their workaround: build with clang:

source=("http://downloads.sourceforge.net/project/freeimage/Source%20Distribution/${pkgver}/FreeImage${pkgver//./}.zip") md5sums=('459e15f0ec75d6efa3c7bd63277ead86')

build() { cp -r FreeImage FreeImagefip

export CFLAGS+=" -O3 -fPIC -fexceptions -fvisibility=hidden -DNO_LCMS" export CXXFLAGS+=" -O3 -fPIC -fexceptions -fvisibility=hidden -Wno-ctor-dtor-privacy"

export CC="clang" export CXX="clang++"

cd FreeImage make

cd ${srcdir}/FreeImagefip CXX=clang++ make -f Makefile.fip }

package() { cd FreeImage make DESTDIR=${pkgdir} install

cd ${srcdir}/FreeImagefip make -f Makefile.fip DESTDIR=${pkgdir} install

install -D -m644 ${srcdir}/FreeImage/license-fi.txt ${pkgdir}/usr/share/licenses/${pkgname}/LICENSE }

PS: Because I need floating point component support, I never even bothered checking whether QImage's 30-bit support extends to loading and/or saving image files. It just might, in which case it may be useful for you, at least for testing. Also, the Image::as10BpcQImage function in here https://github.com/erikhvatum/StackStream/blob/3a35f1aff43c8a73da233f418729a6c07c6568fb/source/Image.cpp might be interesting to you.

[CarVac]

I had tried to write to the 30 bit format of QImage when testing, since I'm mainly interested in just displaying the smoother gradations rather than directly handling floating point formats, but I got weird banding.

I hope that I was just doing the bit manipulation incorrectly, and that when set up as a 30 bit OpenGL context, it'll properly display the 30 bit QImage.

I'll try clang tonight, as well as seeing how Qt Quick in 24 bit display mode handles being given a 30 bit QImage. And if there's enough time I'll reboot in 30 bit and see if I can get the context set up properly.