GIMP AppImage (continuous integration)

@Eduardo_Bohoyo : downloading the zip file from github also downloads the already-made ICC profiles, so that people can use the profiles without first building the code. But I completely failed to mention this in the “how-to” file. Sometime in the next week I’ll update that file, and also put in a note that it’s OK to put the profiles in a convenient location such as in a .color home folder. And per Carmelo_DrRaw’s advice I’ll remove the file extension in the sample compile command. Thanks! for letting me know about these issues.

@Carmelo_DrRaw : I just downloaded and spent some time using the 20161128 gimp-cce appimage. Everything seems to work just fine, except that g’mic crashes. I’ll send you a private email with the terminal output.

2 Likes

I have updated the CCE AppImage package with a patched G’MIC plug-in version that does not crash. For this, I simply replaced all instances of R’G’B’ with RGB, as R’G’B’ is not defined in the CCE version of BABL…

I can confirm it works to me too :+1:

1 Like

Also confirmed - everything works perfectly - thanks!

1 Like

One of the next steps in the CCE development will be to modify the G’MIC plug-in so that the input data from GIMP is internally converted to sRGB before it is processed by G’MIC, and then converted back to the GIMP working profile when the processing is finished.

However, this needs to be discussed with @David_Tschumperle to see if he agrees on the proposed modifications…

I clarify that I speak from a great ignorance of this subject: how can this internal operation affect the chromatic quality or, if you want, the final tone accuracy for printing, taking total advantage of the professional orientation of this CCE version?

Maybe I am mixing apples and oranges :confused:

Shortly speaking, many color conversions in G’MIC assume that the input pixel data is in sRGB colorspace. If you feed RGB values from a different colorspace (and working in colorspaces other than sRGB is one of the key possibilities offered with full support by the CCE GIMP version), the results of the G’MIC processing can be more or less wrong…

This is particularly true if the working profile used in GIMP is in linear RGB and not in gamma-encoded RGB.

Thanks, Carmelo.

Yes, I had assumed vaguely this need, and I can understand better its convenience after your explanation (BTW, I wil have a look at the gamma-encoded RGB vs linear RGB. Thanks). But, really, my hesitation was more about the sort of probable chromatic degradation with this G’MIC caveat, even when I could keep your answer in mind in my work with the CCE version. In other words: has the conversion wide-gamut/narrow-gamut/wide-gamut again some influence over the chromatic precision eventually?

Depending on the possible hints in your hypothetical answer, I pledge to research more over this matter in order to avoid my, sometimes, erratic remarks.

You question is absolutely legitimate, and far from being simple… to answer, let me fitrst opena little parenthesis to explain what happens when colors are out of the gamut of the destination colorspace.

Let’s suppose that the in-gamut pixel values are normalized to the [0…1] range. If you convert from a large-gamut colorspace to a small-gamut one, highly saturated colors that are outside of the gamut of the destination colorspace will have at least one of the RGB channels that is either larger than 1 or smaller than 0.

If the conversion is performed in integer precision, the out-of-gamut colors channels be clipped, and this will introduce a “color distortion” in the form of a shift in hue and/or saturation.
The same happens if the conversion is performed in floating-point precision, but the output is clipped to the [0…1] range.

On the other hand, if the conversions are performed in unbounded floating-point mode, the channel values smaller than 0 or larger than 1 will be preserved, and the out-of-gamut colors will not be “distorted”.
For example, if you take an highly saturated yellow in Rec.2020 and you convert it to sRGB, the blue channel will have a negative value. However, if the color is converted back to Rec.2020 in unbounded mode (without clipping), the original highly saturated yellow will be preserved.

To summarize, as far as only colorspace conversion are considered and if they are performed in unbounded mode, smaller gamuts are not a real problem.

The real issue is that we are not just doing colorspace conversions. Once we are in the small-gamut sRGB colorspace, G’MIC will perform complex manipulations of the RGB values, to achieve various types of color edits. And that’s where channel values below 0 or above 1 can become a problem… for example when multiplying RGB values, or when computing the Luminance that might become negative as well.

If you want to dig further on this topic (and I highly recommend you to do so if you want to leverage all the potential offered by the CCE GIMP version), I suggest you to look into some of @Elle’s articles, for example:

Edit: Elle pointed me to another very useful article that explains, among other things, the terminology used to define colorspaces and color profiles: The Importance of Terminology and sRGB Uncertainty | Colour Science

2 Likes

I disagree :wink:: I got you almost at a glance thanks to your explanatory answer.

Of course, I appreciate very much the links too :slight_smile:

Many thanks for building these images. I’m a Linux novice but want to use GIMP. I looked at the building procedures at gimp.org and thought what a lot of work. Martin Nordholts’ process looked comprehensive but a steep curve for me. So v2.9.5 and the CCE version are a godsend.

I’ve installed CCE and made a start. This is on a new good spec PC running Ubuntu 16.10. I tried RawT. first and it seemed quite snappy, 3x faster than my old PC (Win7 64bit). But Gimp seemed a bit sluggish. So I installed windows Gimp on the old PC and it was… about 3x slower! So I’m assuming for now that’s how GIMP is. (I opened a 17Mb jpeg, set 32bit floating point resolution, then changed the middle slider in Levels with preview off, and timed how long from “ok” to finishing. About 6s. I think GIMP is set up reasonably, I haven’t changed anything, the Tile value is 16Gb (got 32Gb of decent ram and an SSD) and I think only a few Gb were being used.

I seem to have a few gremlins though. I installed the image rather than just run it, as you recommended in the video. I locked it to the Launcher. But on re-booting, it’s no longer on the Launcher. And now the “Search” app can’t even find “gimp”. To run it now I’m double-clicking the appimage. I can then lock it to the L. but if I exit GIMP and try to invoke from the L. the icon pulses for a while then stops, but won’t launch.

There is a bit of a theme regarding re-booting - RT forgets the folder I was previously browsing from.

Any thoughts very welcome of course.

I should have mentioned the version - I recently downloaded from the
Community-built software page and have
gimp-cce-2.9.5-20161130.glibc2.15-x86_64 and
gimp-2.9.5-20170103.glibc2.15-x86_64

It’s the CCE version I’ve been using (though not the actual CCE “hack” so far).

Did you mean GIMP?

What was the resolution in pixels of the image you have edited? I can try to do some profiling on my system just for comparison…

I will try to see if I can reproduce this behaviour, but honestly I’ve never seen such a problem.

By the way, it is almost time to make a new version!!!

hi, thanks for the above. The jpeg resolution is 5488 x 3662, so 20Mpxl.

I expect I’ve somehow got a screwy system. Do you think this could have anything to do with it? - the appImage is in a different partition to the Ubuntu system (but both on the SSD). I made a separate partition to keep my work on. I’m intending to keep the system partition just for system stuff.

That’s great… thanks again.

No, RT is losing the folder, defaulting to home - (username) - Pictures after a re-boot.
The folder Iast used, the one it’s forgetting, is in a separate partition, as just mentioned in my DrRaw reply, in case that might be the cause. Otherwise RT seems to be working nicely so far.

Ah, ok. You’re using RT AppImage?

No, well I don’t think so, I’m using the Darius Duma PPA as on the RT download page and then “sudo apt-get install rawtherapee-unstable”. If I do “apt search rawth” I get :-
Sorting… Done
Full Text Search… Done
rawtherapee/yakkety 5.0-1dhor~yakkety amd64
RAW file processor
rawtherapee-data/yakkety,yakkety 4.2-4build1 all
raw image converter and digital photo processor (data files)
rawtherapee-unstable/yakkety,now 1:4.3+git20170124-486~ubuntu16.10.1 amd64 [installed]
RAW file processor
Thanks.

Looks like you’re using an older version of RT.

Thanks folks for the comments @heckflosse, @paperdigits. Re. RT, let me see if I understand the “apt search” info above…

  • available to install is a stable version 5.0 - so bang up to date?,
  • installed is the development version at ?4.3? but has there ever been a 4.3.?,
  • and the data bit at 4.2.
    I don’t know where to go with this. Do you think I should try removing what I have now and then installing the “5.0”?
    Hi @Dariusz_Duma, what do you recommend please?