| Welcome, Guest |
You have to register before you can post on our site.
|
|
|
Linear color profile not working as expected |
|
Posted by: QuackDilly - 7 hours ago - Forum: General questions
- Replies (1)
|
 |
Windows 11, GIMP 3.2.4
I'm trying to use mathematically correct linear sRGB color in a GIMP project I'm working on, however, when I put a project on linear light (which I'm guessing is the same as linear color?) via Image > Encoding > Linear Light, middle grey does not change, and neither do most of the other colors I'm working with. I'm not much of a super technical artist or photographer or image maker or whatever, but based on what I know, linear light is the simplest option for my project. Could somebody help me understand what is going on here??
For those of you that want more backstory in order to better understand my predicament (if not, skip to the next horizontal rule):
I dabble in creating 2D clothing for characters on the game platform known as Roblox as a hobby. Though I do this mostly for myself and my own Roblox character, I still like to share my work for others to use and enjoy. However, due to the newly implemented system in which users of the platform must pay for a subscription to keep 2D clothing on sale and on the 'Marketplace' for others to see and use, I, in my not-soon-to-end state as a minor with no money of my own, have been forced to resort to a different method of distribution involving uploading each of my clothing textures as a decal asset to the Roblox 'Creator Store', where users can download my decal as a file, convert to PNG, and then upload it to their own inventory as their own clothing for them to use, albeit for the base clothing upload fee to Roblox (I have the freedom to not care about profiting off of such clothing, which is why I am letting users download my clothing for free and use it at their own discretion).
From what I know, this method does not violate or circumvent their platform's ToS.
Recently, I have made a clothing design for a black cargo/tactical pant in GIMP (my program of choice for designing clothing assets). It went perfectly fine, and my system worked as intended, aside from perhaps an excessive darkness in color. However, my completionist drive has been urging me to create multiple color variants for this item (among all my other clothing items), particularly OD Green and Ranger Green, and also to create a 'fixed' version with slightly lightened colors of the original variant.
Unfortunately, my attempted recolorations haven't been going too well, looking very ugly and unnatural and dissimilar to the original in terms of color proportion. I decided I would instead come up with a new system to roughly automate my current method in an attempt to cut out the trial and error. The way in which it is planned to work is as follows:
- Open the original clothing texture in GIMP
- Calculate the color multipliers that would be required for multiplying with the base color of the clothing asset to result in the desired shades for all parts of the texture
- Make a new project of a multiplier map image of all of these color multipliers, intended to represent the desired differences in shades of color relative to an arbitrary base color following the pattern of the original clothing texture (NOT a luminosity map, as this multiplier map is intended specifically to work with ANY color, not just hue and saturation of a color)
- This multiplier map would serve as a template for the intended shades of each part of a clothing item relative to its coloring
- The multiplier map can then be used with a base color layer for each differently color-schemed part of the clothing item to achieve the correct shades of color relative to that base color, appearing like the original clothing item, just in any different color (since the clothing is 2D, the only way to achieve detail and overall appearance is by, essentially, pixel art)
- I can automate this process by coding this whole system onto a website, once I have a proof of concept down with GIMP of course
The problem there, however, is that my original pant texture was created in a project using non-linear color, before I knew anything about the existence of gamma or linear color and whatnot. This means the differences in shades of color in my pant texture will not convert neatly into a universal, standardized multiplier map that will work the same across every color due to the non-linearity of how colors interact in that color profile, and if I used such a multiplier map, the differences in shades of color would be different across every color... And even if I could make an image that appears different based on specific colors (which, as far as I'm aware, wouldn't be too easily feasible), it would still be a nightmare to use properly and code.
So I need to add an extra step before I start my multiplier calculations, that being converting the colors from subjection to the math of a non-linear color profile to that of a linear one. Now, seeing as I have only just realized while writing this paragraph that the reason my excessively darkly colored original black pant texture seems to mush all into one color when switching it to linear color is probably because of the lower color fidelity in the darker ranges of an 8-bit linear color system compared to the non-linear system it was originally created in, my original root problem of being simply that I just needed to calculate the correct color code that would accurately display the same color shown in the non-linear system while using the linear system may not be as needed as I once thought.
Irregardless, this was never the problem I needed assistance with on this forum post anyway, but rather, understanding why, when I tested the linear system to see what was going on with my color (before I had that whole realization yada yada yada), middle grey (non-linear sRGB (127, 127, 127) or also either non-linear sRGB (128, 128, 128), I tested with both) remained the same color when I switched between linear sRGB and nonlinear sRGB?
From what I understand about linear color vs non-linear (gamma) color, linear color is physically accurate, while non-linear gamma color is perceptually accurate. Our perception has greater fidelity in viewing darkness than in brightness, which is why non-linear color has much more fidelity in the darker range compared to linear color. Conversely, specifically because our perception has greater fidelity in darkness than in brightness, the linear color range appears overtly bloated with unnecessary amounts of brighter colors, with little space allocated to darker colors. This means that the perceptual middle grey (sRGB (127, 127, 127) in a non-linear color profile) is located in the smaller portion of the linear color profile, and should be located at a lower part of the range (specifically, approximately sRGB (46, 46, 46), at least according to the math of around 18% (physically accurate reflectance/brightness value of middle grey) of 255).
However, when I test these expected results against GIMP by opening two separate projects, one with a canvas filled with sRGB (127, 127, 127) in a linear color system, and the other with a canvas filled with sRGB (127, 127, 127) in a non-linear color system... THEY ARE THE SAME DISPLAYED COLOR!! WHY?? IS MY GIMP BROKEN?? GIMP still says when I color pick the colors, in both systems, that they're the same color code (#7f7f7f); even PowerToys' color picker agrees!! If the linear color system was being accurate, it should be displaying a lighter shade of grey, not middle grey!!
I'm aware that GIMP probably changes the underlying color values of pixels when switching from non-linear color to linear color and vice versa, which is why both 'middle greys' look the same, but that does not explain why the heck the color picker says its the same color code!! If it changed the color code, then, well, it should show me the changed color code!! The color codes should be different even for the same displayed colors, at least for most every color in each system (maybe some exceptions like pure white and pure black). Point is, they're allowed to look like the same color perceptually, as long as they have color codes that are internally consistent with their color profile!!
I'm starting to have a hunch that maybe, in an effort to keep the color selecting system intuitive to the average user in both linear and non-linear color systems, GIMP is keeping the same color codes for the same colors in a non-linear color system for both systems, but, held back by the lower color fidelity of the darker ranges of the linear system, GIMP is forced to band the now lower-fidelity colors into their closest-color neighbors. BUT I DON'T WANT GIMP TO BE HELPFUL! LET ME DO THE WORK! I KNOW HOW TO HANDLE THIS!
If this were true, I guess my question is no longer "why is GIMP doing this", as GIMP clearly has its own internal set of rules it is following to the letter, but rather, my question now is "how do I make it NOT"? I'd prefer to understand GIMP in theory before I learn it in practice, which is why, even though this is currently irrelevant to my new problem I discovered halfway through writing this post regarding the whole backstory I have, I still care.
But if this is not true, of course, my question remains the same... Why, and what do I do?
Am I missing something?
|
|
|
| Plugins & Scripts not found by GIMP Version 3.2.4 |
|
Posted by: ajax - Yesterday, 04:02 PM - Forum: General questions
- Replies (4)
|
 |
I'm accustomed to using both plugins & scripts that are provided by third parties for use in GIMP. Have been doing this for quite a while with many different versions of GIMP. While I have not used them yet in GIMP Version 3.0.2 they do appear on the menu when I start Ver3.0.2. Plugins are on the menu item named Filters and scripts are on the menu item named Tools. However, both are absent when I start Ver3.2.4. Also, I have checked and have the corresponding folders in Preferences set to the same values in both versions.
It does occur to me that something might have been changed with respect to how they are invoked but if so I definitely need some help in figuring that out.
|
|
|
|
| Langage français de l'interface |
|
Posted by: cwibal - 05-06-2026, 06:47 PM - Forum: OSX
- Replies (1)
|
|
iMac M1 24" 2021 OS 26.4.1
Bonjour à tous,
Je viens d'installer GIMP 3.2.4 et son emploi pour un néophyte est parfois compliqué. Aussi, j'ai voulu utiliser l'interface en français, le langage système tenant parfois des propos "étranges".
Je suis donc passé naturellement par les préférences où j'ai pu constater que le français qui aurait dû se placer entre Euskara et Gaeilge était absent.
Un coup d'oeil dans '/Volumes/Extension_HD/APPLICATIONS/LOGICIELS LIBRES/GIMP324.app/Contents/Resources/share/locale' permet de voir un dossier 'fr' qui contient LC_MESSAGES et LC_TIME.
Quelqu’un peut-il me dire où se trouve le problème et comment y remédier ?
Merci,
Christian
|
|
|
|
| Locally Installed Help is NOT Working |
|
Posted by: ajax - 05-05-2026, 05:47 PM - Forum: General questions
- Replies (3)
|
|
I'm running GIMP Version 3.2.4 on Windows 10. Both the Windows Installer and Help Installer have been run. The preferences do say to "Use a locally installed copy" however that is not happening. I do notice that the file name for the file I installed is "gimp-help-3.0.2-en-setup.exe", which does imply that the help is a bit older version than 3.2.4. As best I can tell that is the newest one available. Is it possible that has something to do with the problem?
Also, it looks like the Help Installer does not count as an installed program in terms of how the Programs & Features section of the Control Panel. I'm afraid I don't know what files to look for in order to verify that it did get installed. If that is something I should be able to do I could use some help.
|
|
|
|
| Image spacing on display screen |
|
Posted by: ajax - 05-03-2026, 05:23 PM - Forum: General questions
- Replies (2)
|
|
When GIMP opens an image file the view includes an X & Y axis with a scale that shows width and height in different units. It seems that the default positioning preserves some number of negative units which causes the image to use only a portion of the space available on the display screen. While it is understandable that this might be useful for some operations, when I know that there no intention of enlarging the image it has the affect of preventing that space from being used to get a larger view of the image.
I'd like to eliminate that blank space but after spending quite of bit of time looking in the user manual have not succeeded. I'm thinking this should be simple and hope someone can explain how without having to waste the time I already have. PLEASE!
|
|
|
|
|
