Post Reply 

Color to alpha really weird

Sep 11, 2014, 08:57 (This post was last modified: Sep 11, 2014 09:02 by Sagemode.)
Post: #1
Color to alpha really weird
I generally thought C2A would just generate a transparency value based on the offset of the current colour with the chosen base colour.

That is to say, it would adjust the resulting distance between colour A and colour B in such a way that if we put a background behind the new image of the base colour, the regular alpha calculation stuff would come up with the old values.

And I just assumed that that latter thing would be rather simple. If my background pixel is (0, 0, 255) and my foreground pixel is (0, 255, 0) with an alpha of 10% opaqueness, then 10% of the rbg gets derived from the foreground, 90% from the background, and that is just added together.

Obviously it doesn't work that way lol. At least, I don't think so. The C2A process changes everything, R, G, B, saturation, value, only the hue remains the same. It's just extremely weird.

The reason I consider it weird is because after C2A, you cannot actually do anything with the alpha value or it will produce weird artefacts and strangeness.

I had thought it would be easy to halve the transparency of my pixels and end up with something reasonable. Not so. The only thing that doesn't produce weird stuff is to lower the maximum opaqueness (for example through the levels tool). If you lower the maximum transparency you get very weird results.

ANY form of level adjustment on the alpha channel other then only changing the lower transparency bound in the output (in GIMP this is moving the output slider of the upper value from 255 to something lower) will produce distortion.

I have written a custom level tool (for experimentation mostly) on this address:

http://www.xenhideout.nl/alphamod/alphamod.php

It doesn't take any (outside) parameters as of yet and operates on a fixed image. There are three modes. The first mode is equivalent to changing the 'middle' in the input section of the GIMP levels tool. The second mode is equivalent to changing the 'lower' value in the output section of the GIMP levels tool. The third mode is equivalent to changing the 'upper' value in the output section of the GIMP levels tool.

The image currently shown had a white background and C2A was performed on the entire image excepting the "harddisk" images and the 2 circles. With a feathered selection. If you use mode 2 on my script with a value of 0.5, you will multiply all of the "transparency" values by 50%. This is the result:

[Image: shr_alphamod.png]

The background is now obviously just white with a 50% transparency. Everything else is garbled. There are artefacts everywhere, from all the random pixels to the gradients that suddenly terminate.

I consider the Colour-to-Alpha of GIMP to be a deeply flawed algorithm. You basically cannot do anything with these images. The alpha and the other values have become completely intertwined, dependent on one another. But working with alpha channels as an integral aspect to the pixel value is very difficult in GIMP, you basically cannot do it. Even operating on separated alpha channels is very hard.

I was hoping I could just "fade" the C2A but that was also not possible. So there is not actually any (obvious) way to reduce the effect of the operation. I just wanted to create a partial C2A based on the colour white, but it seems like it is not possible?
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 09:33
Post: #2
RE: Color to alpha really weird
I do not honestly know if it will help with your problem, but have you tried GEGL color-reduction to reduce alpha. http://i.imgur.com/zdpxM1X.jpg

** https://www.gimp-forum.net/ now answering questions**
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 16:07 (This post was last modified: Sep 11, 2014 16:56 by Sagemode.)
Post: #3
RE: Color to alpha really weird
Thanks for your suggestion. I hadn't come across GEGL yet in my explorations, but the operation you have selected there is not in my list.

I have just contented myself with a fully transparent background and unreadable text, with a popup to a FancyBox overlay with a white background, so people can still read it if they want.

I wanted to get something with a semi-transparent white background, and then perhaps fade the background towards the edges, I do not yet know. This graphics work is extremely hard on me. It is the biggest bottleneck in my writing. I try to do things with GIMP and then it fails miserably. The closest I could get to what I wanted, was to create a layer of white and then add a mask to it and fill it with a gray, then put a black layer behind it so I could see the effect. Then export the image without the black layer visible. Perhaps it would have worked if I had used my selection mask while painting/filling the layer mask. Or, it wouldn't have made a difference... But it was too hard. It's good enough for now.

Learning GIMP is really extremely challenging and takes a lot of time. I sometimes run into life situations where I have to do a certain thing really quick and it is just not possible. Stuff that these teenagers do with smartphone apps, like blending images, fading edges, all that sort of stuff. I tried to fade some edges using GIMP and it was extremely hard and the tools didn't work as expected. It really takes a lot of effort for me to improve my skills and my toolkit. I'm currently still focussing on GIMP before I try to use something more fancy. But maybe I should just check out those easier tools that can do more with much less pain..
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 16:19
Post: #4
RE: Color to alpha really weird
Oh, boy, I tried "Image Blender Instafusion Free". But in order to "crop" a image you have to do some sort of pinch, with two fingers, and the crop window keeps moving around while me not succeeding to change its dimensions. Oh my god. Is this some new sort of skill? Touch-screen operations requiring 30 hours of practice.
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 16:38 (This post was last modified: Sep 11, 2014 16:48 by rich2005.)
Post: #5
RE: Color to alpha really weird
I do not know why you can not find GEGL it is in the Tools menu. I am using PClinuxOS and Gimp 2.8.14

I see from an earlier post that you are Win 7. Why not try the latest Partha Win 64 bit 2.9 build. To a certain extent it has support for 16 and 32 bit files and might suit your requirements.

Just take your time and get to know the way Gimp operates before

Quote:...I have to do a certain thing really quick and it is just not possible...

edit: forgot the link:
http://www.partha.com and
http://www.partha.com/downloads/gimp-2.9...nstall.exe

** https://www.gimp-forum.net/ now answering questions**
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 17:12
Post: #6
RE: Color to alpha really weird
I'm using GIMP 2.8.10. What is Partha? I guess it is a build of GIMP, but there is nowhere on the front page any information as to what it is supposed to be.

I didn't say that I couldn't find GEGL, but that the "color-reduction" operation is not in my list of GEGL operations.

Yeah I know right. All good things take time. It is just frustrating to want to do something simple because someone is crying and you want to offer some meaningful support using a meaningful image or video snippet and it is just impossible to get it done.

LIke, I wanted to cut an MKV file and convert it to a format suitable for my phone and then put it on Instagram. And it was impossible.

I spent like 8 hours getting to the point that I could get ANY thing on my phone that it would play. And the only thing that worked was VLC's convert ability. Which was so flawed that my phone would skip the first keyframe and only start rendering the video file after the first scene change (next keyframe). And the video editor I had downloaded (MPEG Streamclip) then refused to load that file and it also refused basically anything that MeGUI could output.

And MeGUI refused to convert MKV to anything other than MKV. And then I had to learn how to create custom AVISynth jobs, and finally I had MP4 files, but none of them would play on my phone or load into MPEG Streamclip.

And to this day I still haven't made that 10-15 second video clip. That I can put on Instagram. Even though I spent like 15 hours trying to get there. It's just ridiculous. It's like wanting to break a pencil in two and you can't figure out how to do it. And I really needed to be there for that girl and I couldn't do it....

I have mastered every form of text communication and now I get obstructed and frustrated by the most simple of multimedia operations. My first post on this forum of recent times was about writing a paper on the user interface design of the Logitech/SlimDevices Squeezebox platform. And I still can't go on with it because I cannot get the required images. My verbal skills are lightyears ahead of my graphical skills and the like.
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 17:39 (This post was last modified: Sep 11, 2014 17:41 by Sagemode.)
Post: #7
RE: Color to alpha really weird
My current GIMP skills that I am comfortable with....

...basically come down to using the Fuzzy Select tool, knowing how to add to and substract from selections, I typically know how to turn product images into transparents that I can use on my site. I have a little bit of experience with the Levels tool. My ability to work with saturation and hue and lightness has improved. For example, I know that HSV is not the same as web HSL. If you turn the L of HSL to 100%, you get white. In HSV you get a pure bright colour. To go from V to L you need to divide by 2.

I'm also still frustrated by the fact that everything in Chrome/Opera has way different colours (on my monitor) than in Firefox if I activate its "always use colour profiles" mode. If I open my site on my netbook, or on my phone, everything looks WAY different again....

I tried asking about it in StackExchange but those people are only concerned about winning points by criticizing your questions.

There is so much I need to learn........

My site just looks horrible on my own monitor for longer essays. Something more serious than a diary entry. And only because the background colour comes out so flat. But on my netbook it is not so bad. How on earth can I publish some writing if I can't stand reading it myself? :p.

I think I need to get a new monitor within a month or 6 anyway. But I'll need to learn more about this colour profile stuff so I know what to get. I'm doing so much work on the theme of my WordPress site.. And here I am having been colour blind to a certain extent all my life.

Trying to improve the visuals of basically everything...
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 18:05
Post: #8
RE: Color to alpha really weird
Firefox wasn't using colour management anymore. I think the culprit was not having selected my monitor's "warm" profile as the system default. Finally an option that seems to make a difference.

If you put Firefox (about:config) to "gfx.color_management.mode = 1" (by default it is 2) it will always try to apply I think an sRGB profile to everything while also using the profile set for your monitor. It seems to be both, or neither.

WOULD YOU CHECK THE DIFFERENCE... :(.

[Image: opera_vs_firefox.png]
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 18:38
Post: #9
RE: Color to alpha really weird
My monitor is set up to equate with printing images (brightness way down) rather than web use but I am sure someone else will comment.

Just for info, the partha win 2.9 64 bit looks like this in a Win7 VM.

A couple of screen shots, the precision settings and some of the GEGL operations have been moved to the color menu. http://i.imgur.com/Dsd9Ui5.jpg

** https://www.gimp-forum.net/ now answering questions**
Find all posts by this user
Quote this message in a reply
Sep 11, 2014, 20:52 (This post was last modified: Sep 11, 2014 20:54 by paynekj.)
Post: #10
RE: Color to alpha really weird
Just to clarify one minor point. Partha is a person. He builds the stable, currently released version of GIMP for various platforms, and also builds the current development version of GIMP: http://www.partha.com/

He does like to bundle in lots of other things with his installers and has decided to default the GIMP theme to a dark theme.

Kevin
Find all posts by this user
Quote this message in a reply
Sep 12, 2014, 05:10
Post: #11
RE: Color to alpha really weird
I'm just utterly flabbergasted by the fact that with a current day Operating System like Windows 7, which probably has had support for colour management for years and years....

..We have the situation where the default colour-space for anything is sRGB, and I've read that most monitors also closely match the sRGB space. And my monitor doesn't. But there are profiles that can fix it. And they are not used. And only Firefox does it, and GIMP if I want it, and IrfanView if I want it.

Naturally, if I now make a screenshot and then show it in GIMP using the color management, it won't show up the same as how I saw it, but that's easy enough to remember.
Find all posts by this user
Quote this message in a reply
Sep 14, 2014, 05:53 (This post was last modified: Sep 14, 2014 09:50 by Sagemode.)
Post: #12
RE: Color to alpha really weird
(Sep 13, 2014 22:49)ofnuts Wrote:  C2A is exactly the same as painting with "Color erase". The "contract" is simple: removing the color C from the color R,G,B,A yields a color R',G',B',A' such as if put in a layer above the removed color C(*) you get back R,G,B,A.

One hitch: there infinitely many ways to do this, depending on the alpha you chose. For instance if you remove White from Gray, you have 50% transparent Black to fully opaque gray, and all the combination of decreasing alpha and decreasing blackness. So to lift the ambiguity, Gimp takes the value with maximum alpha.

(*)The compositing formula is found here.

Thanks. I've studied at least the compositing now:

θ = 1 - (1-α)(1-β)

θ = β + α(1-β)
θ = α + β(1-α)

0 = α/θ.a + (1-α/θ)*b

where θ is the alpha of the result colour, and o is the result colour itself.

Now it is interesting for me to see how this relates to RGBA versus HSLA.

With RGB it is easy to see how you can calculate individual components.

If the alpha applies to all 3 colours identically....

Then obviously the direct hue (when we are still talking about the basic α*A multiplication) does not change. Since both R, G and B are decreasing linearly together, all of them are moving closer to 0. In a colour with a zero component (e.g. (R,0,B)) the colour could not exceed L = 0.5 and the chroma would also linearly decrease. If you then add the G back you still get an addition of three vectors of which the sum linearly decreases. In effect, you are shrinking the entire RGB cube. So chroma decreases linearly as well by the same factor. As Lightness is just a measure of the lowest and highest RGB values, its (absolute) value also decreases linearly by the same factor. Saturation (in HSL) is a value where chroma is scaled to the maximum width, but if the entire cube is shrinking then (relative to the original size) saturation is also shrinking linearly by the same factor.

But what is shrinking is not their distance to black. This is because their distance to white is shrinking by the same amount.

We tend to view RGB as positive values from black up, we could also view them as negative values from white down. Or, from full-expression down. In that system, if you were to do alpha compositing, and your value B would be black (255,255,255) and your value A would be a bright red (0, 255, 255) and your bright red would have a small alpha (0.2) you would end up with very high values for R, which means it would be a very dark colour. That's completely equivalent. The equations for alpha compositing do not care about what the values actually mean.

They are just weighted sums.

So while an alpha of less than 1 would shrink the cube that the colour sits in, you're also just decreasing its 'relevance' or its weight in the sum. In that sense, the weighted component is a smaller cube, the component itself does not really change.

Basically, anything you do to RGB values applies to SL values equally well in a scaling sense. What remains is Hue.

In HSL, hue is the result of the addition of 3 vectors. In the RBG cube--tilted, every addition of any part of R, G, or B, moves the sum 'up' towards white, but in the projection that results in our hexagram, this vertical aspect is left out. What results is the fact that R is a vector of (1,0), G is (-1, √3) and B is (-1, -√3). If we take these as the base vectors they become R = (1,0), G is (-½, ½√3) and B is (-½, -½√3).

Alternatively, they are R = (2,0) G = (-1, √3) and B is (-1, -√3). If (r,g,b) are the scalar values from (for instance) our RGB model (with [0,255]) then our result vector C = simply r·R + g·G + b·B. Which is a simple matrix multiplication (right side).

Since the alpha composition/computation is the weighted sum of two values (x3) it is equally the weighted sum of two vectors C1 and C2 that are just linear mappings of those values. If M is our 2x3 column matrix (R,G,B) and c1 is our vector (r1, g1, b1) and c2 is our vector (r2, g2, b2), then C1 = M*c1, C2 = M*c2, and the output colour of their composition Q is simply M*c1*(α/θ) + M*c2*(1- α/θ) with α/θ being a value from above equations.

It is then equally a simple composition of those result vectors in 2-D Cartesian Euclidean space. And Q is a new vector (x,y) within the hexagram. Whose angle is determined by atan2(y,x).

And a simple test proves that my calculations are correct thus far...

In any case it seems impossible to do hue-to-hue mappings using polar coordinates. The fastest way to go from one hue to another, given two HSLA vectors, would be:

- determine C from S
- calculate (x,y) from (C * cos(hue), C * sin(hue))
- add these two (x,y) you have together using alpha compositing
- the new hue is (arctan(y,x) + 360) % 360, and the new chroma is sqrt(x*x + y*y).

However the new lightness is impossible to calculate without knowing the individual components (vectors). I don't think there can be any form of hue/chromaticity/lightness calculation that can be more meaningful than that.

Nevertheless, the six segments have defined orders of magnitude for the components:

* 0-60 -> (R,G,B)
* 60-120 -> (G,R,B)
* 120-180 -> (G,B,R)
* 180-240 -> (B,G,R)
* 240-300 -> (B,R,G)
* 300-360 -> (R,B,G)

It will prove useful to learn how one form of vector addition will differ from another, based on their segment origins....
Find all posts by this user
Quote this message in a reply
Sep 14, 2014, 06:10
Post: #13
RE: Color to alpha really weird
When I wrote my HSL to RGB script, I was at great pains to discover which of R,G,B was the largest and which was the smallest.

The formulae I had were only able to determine offsets between the two (between each pair).

Particularly, I had to make do with:

α = ½(2R - G - B)
β = ½√3(G - B)

which I still do not understand. But it becomes clear. G is the only positive Y component. B is the only negative Y component. Therefore, their difference scaled by their angle (60°, or rather 30° from the Y-axis) is the Y-distance. The x-components of B and G are half that of R. Therefore, R minus half the sum of G and B, is the X-distance.
Find all posts by this user
Quote this message in a reply
Sep 14, 2014, 09:46
Post: #14
RE: Color to alpha really weird
It is interesting to note that, purely based on the projection on the hexagonal plane (which is Chroma) and the angle (which is Hue) you can determine the actual differences (in absolute terms) between the R, G and B components (as long as you know the maximum range, for example 255 as highest value in a discreet system).

You actually do not need more than that. You do not need lightness.

Lightness then is simply an addition you make to the R, G and B based on their actual offset to the plane of reference (which could be black, white, gray, or any other value).

Typical RGB in [0,255] is offset from black. You could just as easily have [-128, 127] which would be offset from gray. The RGB of any colour moves freely up and down this 'verticle' axis staying the same hue. Therefore, if you take any colour, say rgb(10, 20, 30) and turn it into (110, 120, 130) it stays the same hue!!!!!

You can easily prove this in any colour picker dialog, just as GIMP's default one. :))))

Boy, I'm learning stuff :D. Changing (rotating) the hue changes the relative prevalence of the components based on the 60° segment you are in. The offset towards the edge of the segment or rather simply the radius from the origin to where you are in that segment, is what determines the chroma. Hue and chroma together determine the relative distances between the components. That is to say, the chroma scales the distances such that you can turn them into actual RGB values. (if you used 'saturation' for that, in either HSV or HSL, you would get values that are way out of bounds). (Except for the ideal case where V = 1.0 or L = 0.5, or when the distances are zero (grayscale values).

So, Hue already determines the unscaled relative distances. With Chroma, you know how the distances relate to other colours with a different chromacity. And Lightness then offsets the values to move them up and down the 'vertical' axis to become darker or brighter.

You can see how harmonic the HSL system is. I still don't fully grasp it. The V of HSV can perform this scaling as well. Just use the angle (hue) to find the maximum colour, and that is your V. Then substract the distances that have been scaled by Chroma, and you have the other two values.

So both V and L anchor the actual colour on the vertical dimension/axis. V provides an anchor for the top value. L provides an anchor for both top and bottom. To find them, whereas with V you have the direct value, with L you need to obtain the range between highest and lowest (also easy to do based on angle (hue)) because L actually anchors the colour in the middle between them. The middle point between highest and lowest value is anchored somewhere, so if you were to transform a single (R,G,B) into a 3d-rectangular-volume, with dimensions RxGxB, then tilt the volume on one of its apexes, in an angle of (45°, 45°, 45°), and if you conceptually anchored it dead in the centre of the RGB cube (at 0.5, 0.5, 0.5) which means you would be using offsets from (0.5, 0.5, 0.5) as values for R,G,B, then the Lightness (also offset from L = 0.5) would be +/- values in the range of [-0.5, 0.5] that would move this rectangular cube up and down along the central axis of the larger RGB cube.

You can then conceptually view each colour as offsetting from that centre point (127.5, 127.5, 127.5) which we would call Gray. The Hue then represents an angle which is made up of the distances between the values, that are essentially orthogonal to each other. The Chroma represents the scale of the distances, and the Lightness (or Value) represents one of the actual, absolute values for this colour C. Value represents the top value of C. That is, the absolute value of the largest component (highest value). In a system centred around Gray, that doesn't make sense at all. Lightness represents the smack middle between the highest and lowest point. This is not necessarily the centre of the rectangular cube (because it's not a cube) but vertically speaking (meaning, the axis that is at 45° of every other axis, or the vector (1,1,1)) it does position our shape vertically in the middle of the black-white axis. The actual Lightness value ([-0.5, 0.5]) then moves our shape up or down this axis. This 'shape' is nothing more, actually, than a vector in this 3-d space. If we want to make a rectangular shape out of it, then it is a 3d-rectangle sitting in one of 8 quadrants with its original always anchored at (0,0,0). Our actual RGB values are then not [0,1] but [-0.5, 0.5] and, given regular [255,255,255] sizes, could not have any discrete values with an even range (256 values) but would have to be something like [-127, 127] coming down to 255 distinct values. And resulting not in 24-bit colour, but something a bit smaller. It's all strange.

Because actual Gray is not defined in [0..255]. (128,128,128) has 128 values below it and 127 values above it, while (127,127,127) has 127 values below it and 128 values above it. There is no real middle value.

Lightness or Value are usually defined as [0..100] ranges which mean they DO have middle value at 50 (fifty). But 128,128,128 gets turned into L = V = 50, as does 127,127,127, but converting back by convention produces 128,128,128, or #808080. It actually produces (127.5, 127.5, 127.5) rounded to 808080. So there is immediately a loss of accuracy in this conversion process. With 360 hues, 101 lightness values and 101/2 chroma values, we have 1836180 possible colours (or if we take chroma as [0..50] they become 1854360), but RGB having 256*256*256, it is 16777216, you can immediately see that rounded values in HSL will produce loss of accuracy when converted back to RGB, and RGB can also not be unambiguously represented in HSL. As long as you don't round your HSL, you get back the same RGB. But if you start out with meaningful HSL, then turn to RGB, and then convert back, you may not get back the same values.

In any case, also interesting to note:

In "real RGB chroma" given that RGB can only span a hexagon (not a circle) using its vectors, the maximum chroma (meaningful in the context of our hexagonal projection) is 1 at the apexes of 0, 60, 120, 180, 240 and 300 degrees, but it is ½√3 at the midpoints of 30, 90, 150, 210 and 270 degrees. In my earlier calculations, I scaled chroma by the maximum chroma for that level irrespective of angle. Typically, chroma is defined by the difference between the largest and lowest (RGB) component. But this turns chroma into a circle instead of a hexagon. This chroma is still maximum at e.g. 30°. Scaling with the max is then no-nonsense and non-problematic. But scaling with the maximum at a certain level simply means that MY chroma will not reach maximum saturation at anything but the 6 apexes. MY maximum chroma at 30° and L = 50% is 86.6% instead of 100%.

If I want that to become something different (a saturation that becomes a complete circular cylinder, instead of a hexagonal cylinder) I would have to also scale it by something of the inverse of ½√3 depending on actual angle... OR, scale it simply by the real maximum for that angle at that lightness.

The routines I have written, if you feed them a saturation of 1 at an angle of 30°, then the resulting chroma would be too large and you'd get too big values for RGB, possibly beyond 255 (for regular RGB).

I believe most or all computing software (like for the web) uses the fake chroma. It is easier and thus much faster to compute, not requiring any trigon. And it easily extends the hexagon into a circle, and the circle into a real cylinder. Nevertheless, that chroma is not an actual projection of the RGB onto the reference plane. And the hues for that chroma are not actual angles.

Those fake hues are computed by taking an apex, say 60°, then taking some measure of difference between R and G values, or likewise, as relevant for that section, and then using that value as the "angular offset" from 60°. But that is just a linear value, not something polar. Basically, at the apexes (of 60 multiples) your angle is correct, as well as at their midsections (30°), but in the midsections of THOSE (15° ) the differences can be as much as 1.12°. Not so much for hue. But obviously for chroma, the difference becomes 2/√3 which is 15%.

Meaning, if you have chromatic values based on proper RGB values, and then you go and do calculations on those values, where you compare them, relate them to, or treat them in the same way as the non-distorted values, your computations no longer respect the actual relationships that are present in the RGB system. And you lose all sense of harmony in those computations. This is the same for basic HSV. Which is obviously even worse, if you were to do computations based on Value (which is a meaningless number).

There is not a lot of harmony in this world, I tell ya ;-). Except at the soul level, obviously.

But we are not concerned with the soul level, because the soul level is immutable and self-resolving. It takes care of itself. No issues there.

So to summarize a bit before I start on a new trail of my explorations:

* Real hue/chroma are hexagon-limited values based on the real projection of the addition of 3 vectors.
* Fake hue/chroma are simplified calculations based only on the difference between RGB values, where chroma is M - m (maximum minus minimum value in RGB tuple) and hue is an offset from apex angles which comes down to being nothing other than the distance (or proportion thereof) that you have to travel along the edge of the hexagon to get to that (projected) point on its edge.
* RGB 24 bit does not have enough accuracy to measure regular 360x101x51 discrete HSL values.

In summary, we can say that: Hue is determined by distances between R, G and B (that can be normalized) and Chroma defines the scaling back (denormalisation) of those distances, and Lightness/Value translates those differences into actual absolute values by anchoring them somewhere along the vertical black-white axis.

We can also say that chroma for two alpha-composited values cannot be easily computed based on chroma levels alone, neither can lightness, neither can hue. These vector additions can cause the resulting new colour to end up anywhere within the spectrum, or rather, within the hexagon. There is really no other recourse than go back to RGB, do the compositing, and then go back to HSL.

RGB remains the foundation. The HSL bi-hexa-cone is a derivative of the RGB cube, as is the HSV hexa-cone.
Find all posts by this user
Quote this message in a reply
Sep 16, 2014, 05:49 (This post was last modified: Sep 16, 2014 06:00 by Sagemode.)
Post: #15
RE: Color to alpha really weird
My AlphaMod mode 4 currently translates alpha into 66% lightness and then lightness back into alpha. Every time you turn lightness into alpha, the image becomes fully harmonious. You can also turn alpha into 100% lightness, but then everything that is oblique would become fully white AND oblique. Not very useful at this point but very promising.

link

One of the images:
[Image: oblique-to-gray.png]

Oblique to white:
[Image: oblique-to-white.png]

Oblique to white with threshold of alpha not being fully opaque:
[Image: oblique-to-white-threshold.png]
Find all posts by this user
Quote this message in a reply
Post Reply 


Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Desaturate to color KWiK 2 91 Oct 9, 2017 22:14
Last Post: KWiK
  Removing color from multiple images Aquilo 6 2,897 Sep 28, 2017 12:56
Last Post: angel0sdh
  remove alpha channel on export? peekofartertainment 1 196 Jul 22, 2017 08:08
Last Post: ythgilb
  Image color vs color picker YalithKBK 1 212 Jul 7, 2017 11:45
Last Post: ythgilb
  Change transparent background color Firion 1 245 Jun 14, 2017 05:24
Last Post: ythgilb

Forum Jump:


GIMP ForumPortalArchiveContactTermsRSS