Re: [Gimp-user] Layer addition - bug, feature, or user misunderstanding?

2015-10-13 Thread Elle Stone

On 10/13/2015 12:25 AM, Richard wrote:

The problem is that a layer's opacity doesn't add -- it multiplies, like
this:

Result = (opacity) * (this layer) + (100%-opacity) * (result of layers
below)

This formula holds true regardless of the layer's assigned blending mode
(and it's recursive, with the "result of layers below" defined by
inserting the next layer down into the same formula).


Hmm, I tried setting the layer blend mode for the three layers to 
Addition, Normal, Lighten only, and Dodge, and regardless of the chosen 
blend mode, the result was always 79%. But these identical results are 
because each layer is white, R=G=B=1.0f or 255 at 8-bit integer. Change 
to some lower value, such as R=G=B=0.5f or 128 at 8-bit integer, and the 
result of blending the three layers over black does depend on the chosen 
blend mode.




= (22.2% + 55.8% + 1.3%) * (white)
= 79.3% white

Doesn't that 79% look rather familiar? :)


Many thanks! for explaining this math. The math behind Normal blend mode 
isn't exactly intuitively obvious, at least not to me.


But as explained below, I think that's not the right math for Addition 
blend mode. I think something might be wrong in the Addition layer blend 
mode code.



Aside - the left half of your image is totally reproducible on GIMP 2.8
.  (I can't seem to reproduce the right half in 2.8, but I haven't
examined the actual XCF either, so I don't have all the details.)


I uploaded a GIMP 2.8 version of the xcf file:
http://ninedegreesbelow.com/bug-reports/gimp29/layer-addition/gimp28-addition.xcf



Now to fix the values ... first, Red is on top so it can keep the 22.2%;
this leaves a translucency of 77.8% for everything below it.
For Green, below Red, divide its opacity by Red's translucency (above):
Green's opacity should be (71.7% / 77.8%) = 92.1%.  This, in turn,
leaves 7.9% of translucency for Blue below it.
For Blue (which is below both Green and Red), divide its opacity by the
overall translucencies of both Red and Green.  You can do the math if
you want (6.1% / 77.8% / 7.9%), but it conveniently works out to exactly
100% opacity -- i.e. Blue doesn't need any translucency for itself
because with both Red and Green on top of it (at the above opacities)
only 6.1% of Blue will be visible anyway.

To prove it, just plug the new opacities back into the above formula:

Image = 22.2% * (red) + 77.8% * (92.1% * (green) + (100% - 92.1%) *
(100% * blue) )
= 22.2% * (red) + 77.8% * (92.1% * (green) + 7.9% * (blue) )
= 22.2% * red + 71.7% * green + 6.1% * blue


Many, many thanks! I tried your percentages with a real image rather 
than a solid white layer, using Normal blend mode, and your percentages 
produced *exactly* the right black and white image.


Here's why I think there might be a bug in the code for Addition blend 
mode. But maybe you can explain why it's not a bug:


Working in GIMP 2.9, change the color of the three layers that are being 
added together to 0.50f (the same as you'd get if you started with a 50% 
gray layer and dragged the three channels over to the layer stack).


The result of setting the percentages to 22.2% of the Red channel layer, 
71.7% of the Green channel layer, and 6.1% of the Blue channel layer, 
and then setting the layer blend mode for each layer to Addition, is 
exactly 0.50f, which is intuitively what I would expect, and coheres 
with the equations:


(0.222 * Red) + (0.717 * Green) + (0.061 * Blue)

If Red=Green=Blue=0.5, the above equation simplifies to

(0.222 + 0.717 + 0.061) * 0.5 = 1.0 * 0.5 = 0.5

The corresponding Normal blend mode math that you provided produces 0.3965.

I tried the same percentages using GIMP 2.8, using R=G=B=128. Well, 
actually I set the percentages to the "easier to type" 22%, 72%, 6%.


In GIMP 2.8, Addition blend mode for the three layers produces R=G=B=127 
or 50% (rounded by the color picker), pretty close to what I expected 
Addition blend mode to produce. And Normal blend mode produces 
R=G=B=101, or 40%, exactly as you describe the Normal blend mode math above.


In GIMP 2.9, using Addition blend mode as described produces the 
intuitively expected results for all shades of gray less than or equal 
to 55% gray (R=G=B=0.55f, or 140 for 8-bit integer).


But at 56% gray and higher, results are progressively less than I would 
expect, assuming my equations for Addition blend mode are correct. 
Instead results progressively converge on the Normal blend mode results 
as the color of the blended layers approaches solid white.


So does this seem like a bug in the Addition blend mode? Or is there 
something I'm not still not understanding about how Addition layer blend 
mode is supposed to work?


Best,
Elle

As an aside (in case anyone is interested in using stacked channel 
layers to produce a black and white image), although the math is the 
same, the required percentages for converting to Luminance will change 
for other RGB color spaces. And the image needs to be in a linear gamma 
color 

Re: [Gimp-user] Layer addition - bug, feature, or user misunderstanding?

2015-10-13 Thread Elle Stone

On 10/13/2015 10:55 AM, Elle Stone wrote:

So does this seem like a bug in the Addition blend mode? Or is there
something I'm not still not understanding about how Addition layer blend
mode is supposed to work?


Hmm, Krita produces the results I expected, that is, the three layers 
add up to R=G=B=1.0f.


So either GIMP intentionally uses a different algorithm for addition 
blend mode. Or else there's a bug in the code, most likely the same bug 
reported here: https://bugzilla.gnome.org/show_bug.cgi?id=744265. I'll 
add a comment to that bug report.

___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list


Re: [Gimp-user] Crop Marks and Bleed

2015-10-13 Thread Sarah Grant
Thanks both for the reply - very helpful

Sarah Grant
Marketing Director

DD: +44(0) 1928 352 084   |   M: +44(0) 7581 625 097   |   E: 
sarah.gr...@traverseassociates.co.uk 
Vale House, Aston Lane North, Preston Brook, Cheshire, WA7 3PE
   

  
This
 e-mail is for the intended recipient only and contains proprietary information 
some or all of which may be legally privileged. If you have received this email 
in error and are not the intended recipient, please notify the author by 
replying to this e-mail.

If you are not the intended recipient you must not use, disclose, distribute, 
copy, print or rely on this e-mail. E-mails may not be secure and it is the 
responsibility of the recipient to ensure that they are virus free.

The company accepts no responsibility for any loss or damage resulting from the 
receipt or use of this e-mail or attached files.









On 13/10/2015 00:52, "Jehan Pagès"  wrote:

>Hi,
>
>On Sat, Oct 10, 2015 at 1:40 PM, Partha Bagchi  wrote:
>> It's supposed to be in the print dialog box image settings.
>
>There you can add crop marks, but not bleed. Indeed it would be nice
>to have a bleed concept within a GIMP canvas since a lot of GIMP users
>are working with the printing world. Unfortunately as far as I know,
>this does not exist currently.
>
>Right now, your best replacement is to compute yourself the bleed size
>in pixel (depending on your resolution), make your image bigger than
>the finale size and add guides to exact pixel positions where the
>bleeds would be for guiding.
>
>Jehan
>
>> On Fri, Oct 9, 2015 at 8:30 AM, Sarah Grant
>>  wrote:
>>> Hi there
>>>
>>> Is there a way to put crop marks and bleed onto a file in GIMP?
>>>
>>> If you could let me know asap, that would be great.
>>>
>>> Thanks
>>> Sarah
>>> Sarah Grant
>>> Marketing Director
>>>
>>> DD: +44(0) 1928 352 084   |   M: +44(0) 7581 625 097   |   E: 
>>> sarah.gr...@traverseassociates.co.uk
>>> Vale House, Aston Lane North, Preston Brook, Cheshire, WA7 3PE
>>>
>>> This e-mail is for the intended recipient only and contains proprietary 
>>> information some or all of which may be legally privileged. If you have 
>>> received this email in error and are not the intended recipient, please 
>>> notify the author by replying to this e-mail.
>>>
>>> If you are not the intended recipient you must not use, disclose, 
>>> distribute, copy, print or rely on this e-mail. E-mails may not be secure 
>>> and it is the responsibility of the recipient to ensure that they are virus 
>>> free.
>>>
>>> The company accepts no responsibility for any loss or damage resulting from 
>>> the receipt or use of this e-mail or attached files.
>>>
>>>
>>>
>>> ___
>>> gimp-user-list mailing list
>>> List address:gimp-user-list@gnome.org
>>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
>>> List archives:   https://mail.gnome.org/archives/gimp-user-list
>> ___
>> gimp-user-list mailing list
>> List address:gimp-user-list@gnome.org
>> List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
>> List archives:   https://mail.gnome.org/archives/gimp-user-list

___
gimp-user-list mailing list
List address:gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives:   https://mail.gnome.org/archives/gimp-user-list