In my quest to add alpha capacity to my image blending tools in Matlab, I've come across a bit of a snag. Among others, I've been using these links as my references as to how foreground and background alpha plays into the composition of both the output color data and output alpha.
My original approach was to simply use a a Src-Over composition for "normal" blend mode and Src-Atop composition for other modes. When compared to the output from GIMP, this produced similar, but differing results. The output alpha matches, but the RGB data differs.
Specifically, the foreground's color influence over the background is zero where the background alpha is zero. After spending a few hours looking naively through the GIMP 2.8.10 source, I notice a few things that confuse me.
Barring certain modes and a few ancillary things that happen during export that I haven't gleaned in the code yet, the approach is approximately thus:
if ~normalmode
FGalpha = min(FGalpha, BGalpha); % << why this?
end
FGalpha = FGalpha * mask * opacity;
OUTalpha = BGalpha + (1 - BGalpha) * FGalpha;
ratio = FGalpha / (OUTalpha + eps);
OUT = OUT * ratio + BG * (1 - ratio);
if normalmode
OUT = cat(3, OUT, OUTalpha);
else
OUT = cat(3, OUT, BGalpha);
end
The points of curiosity lie in the fact that I don't understand conceptually why one would take the minimum of layer alphas for composition. Certainly, this approach produces results which match GIMP, but I'm uncomfortable establishing this as a default behavior if I don't understand the reasoning.
This may be best asked of a GIMP forum somewhere, but I figured it would be more fruitful to approach a general audience. To clarify and summarize:
Does it make sense that colors in a transparent BG region are unaffected by multiplication with an opaque foreground color? Wouldn't this risk causing bleeding of unaltered data near hard mask edges with some future operation?
Although I haven't found anything, are there other applications
out there that use this approach?
Am I wrong to use GIMP's behavior as a reference? I don't have PS to
compare against, and ImageMagick is so flexible that it doesn't
really suggest a particular expected behavior. Certainly, GIMP has
some things it does incorrectly; maybe this is something else that
may change.
EDIT:
I can at least answer the last question by obviating it. I've decided to add support for both SVG 1.2 and legacy GIMP methods. The GEGL methods to be used by GIMP in the future follow the SVG methods, so I figure that suggests the propriety of the legacy methods.
For what it's worth, the SVG methods are all based on a Porter-Duff Src-Over composition. If referring to the documentation, the fact that the blend math is the same gets obfuscated because the blend and composition are algebraically combined using premultiplied alpha to reduce the overall computational cost. With the exception of SoftLight, the core blend math is the same as those used by GIMP and elsewhere.
Any other blend operation (e.g. PinLight, Hue) can be made compatible by just doing:
As = Sa * (1 - Da);
Ad = Da * (1 - Sa);
Ab = Sa * Da;
Ra = As + Ad + Ab; % output alpha
Rc = ( f(Sc,Dc)*Ab + Sc*As + Dc*Ad ) / Ra;
and then doing some algebra if you want to simplify it.
Related
I'm using ggez to make a game with some friends, and I'm trying to have our character rotate to face the pointer at all times. I know so far that I need to get an angle value (f32) in radians, and I think I can use atan2 to get this (?) However, I just don't get the behavior that I want.
This is the code I have: (btw, move_data is a struct holding our player character's values, such as position, velocity, angle and rotation speed).
let m = mouse::position(ctx);
move_data.angle = ((m.y - move_data.position.y).atan2(move_data.position.x - m.x)) * (consts::PI / 2.0) as f32;
I think that I'm close, as I'm already able with this to rotate the character, but only in a sort of 'incomplete' way. The player character (pc) can mostly only face to the upper left corner, when I move the mouse there. Otherwise, if the pointer is to the right and/or below the pc, it rotates in a very slow and minor way, and stops facing the pointer. I don't know if this description makes sense.
I think the problem is that I'm not entirely sure what atan2 is doing in the first place (I only remember some basic trigonometry), and I am also not sure if I'm using it correctly, so I don't exactly know what my code is doing. (Here is the documentation I used for atan2: https://doc.rust-lang.org/std/primitive.f64.html#method.atan2)
I've gotten only so far after much trial and error, Googling as much as I can (mostly Unity tutorial results showed up when looking for algorithms to base my code off of) and I've also asked in the unofficial Rust community Discord server, but nothing so far has worked.
I also had this code earlier, but couldn't find how to make it work either.
let m = mouse::position(ctx); // Type Point2
let mouse_pos = Vector2::new(m.x, m.y); // Transformed to Vector2 to be read by Matrix
move_data.angle = Matrix::angle(&mouse_pos, &move_data.position);
So my question is pretty specific, which means it was pretty hard to find anything that could help me on google or stackoverflow.
I want to give users the ability to set the distance/range on their guns. I have almost everything I need to make this happen, I just don't have the angle that I need to add on to the direction angle at which the bullet comes from. I don't know what equation/formula I would need to get this. I am not looking for anything code-specific, just an idea of what/how to do this.
Since I do not know what formula to use, I just started messing around with some numbers with this formula I found:
(This formula applies to actual sniper)
Range = 1000 * ActualTargetHeight/TargetHeightInMils(on the scope)
BulletDrop = BulletDropSpeed*Range^2/2*VelocityOfTheBullet
MilsToRaiseScope = 1000 * BulletDrop * RangeToTarget
I just replaced Range with the whatever zero the user is on.
I have a feeling I would just toss the MilsToRaiseScope into a trigonometry function. But I'm not sure.
If anyone is confused as to what I'm talking about, you can find an example of what I want in Battlefield 4 or any of the Arma games. With snipers, you can zero in the scope on to whatever distance you need so you won't have to adjust for bullet drop on the scope.
Sorry for the long question, just want to make sure everyone understands! :)
Mils corresponds to (military) angular measurement unit of 1/1000 of radian, so it is ready-to-use angle
Second formula looks strange. Height loss depends on time of flight:
dH = g*t^2/2 = g * (Range / VelocityOfTheBullet)^2 / 2
where g is 9.81 m/sec^2
I am using a 2D table look up for this.
I generate the table by doing a whole bunch of test firings at different angles, and record the path of the bullet for each angle.
To analytically determine this, it can get quite complex if aerodynamic drag is involved.
It is also discussed on this game-specific question.
For inspiration, this animated gif is great.
I am working on a project, which is based on optix. I need to use progressive photon mapping, hence I am trying to use the Progressive Photon Mapping from the samples, but the transparency material is not implemented.
I've googled a lot and also tried to understand other samples that contains transparency material (e.g. Glass, Tutorial, whitted). At last, I got the solution as follows;
Find the hit point (intersection point) (h below)
Generate another ray from that point
use the color of the new generated points
By following you can also find the code of that part, by I do not understand why I get black color(.0f, .0f, 0.f) for the new generated ray (part 3 above).
optix::Ray ray( h, t, rtpass_ray_type, scene_epsilon );
HitPRD refr_prd;
refr_prd.ray_depth = hit_prd.ray_depth+1;
refr_prd.importance = importance;
rtTrace( top_object, ray, refr_prd );
result += (1.0f - reflection) * refraction_color * refr_prd.attenuation;
Any idea will be appreciated.
Please note that refr_prd.attenuation should contains some colors, after using function rtTrace(). I've mentioned reflection and reflaction_color to help you better understand the procedure. You can simply ignore them.
There are a number of methods to diagnose your problem.
Isolate the contribution of the refracted ray, by removing any contribution of the reflection ray.
Make sure you have a miss program. HitPRD::attenuation needs to be written to by all of your closest hit programs and your miss programs. If you suspect the miss program is being called set your miss color to something obviously bad ([1,0,1] is my favorite).
Use rtPrintf in combination with rtContextSetPrintLaunchIndex or setPrintLaunchIndex to print out the individual values of the product to see which term is zero from a given pixel. If you don't restrict the output to a given launch index you will get too much output. You probably also want to print out the depth as well.
Imagine an imperative rendering engine that blits sprites to a bitmap that later gets displayed. This heavily relies on the ability to efficiently mutate individual pixels in said bitmap. How would I do such a thing an a language without side effects? I guess a completely different data structure is called for?
You can convert any algorithm that uses mutable state into an algorithm that "strings" the state along with it. Haskell provides a way of doing this such that it still feels like imperative programming with the state Monad.
Although, it seems to me that the basic blit operation could be done in a more functional style. You are basically combining two bitmaps to produce a new bitmap via pixel by pixel operation. That sounds very functional to me.
High quality imperative code is often faster than good functional code, but if you are willing to give up a little speed you can normally create very nice architectures in a pure functional style
Haskell has side effects, and you should use them whenever they're appropriate. A high-speed blit routine that's going to be in your inner loop (and therefore is performance-critical) is certainly one place that mutation is appropriate, so use it! You have a couple of options:
Roll your own in Haskell, using ST(U)Array or IO(U)Array. Not recommended.
Roll your own in C, and call it with the FFI. Not recommended.
Use one of the many graphics toolkits that offers this kind of operation already, and has hundreds of programmer hours spent on making a good interface with high performance, such as Gtk or OpenGL. Highly recommended.
Enjoy!
A natural functional way of representing an image is by using the index function:
Image :: (Int,Int) -> Color
With this representation, blitting an area from one image to another would be achieved with
blit area a b = \(x,y) -> if (x,y) `isInsideOf` area then a (x,y) else b (x,y)
If translation or another transformation is required, it can be directly applied to the coordinates:
translate (dx,dy) image = \(x,y) -> b (x+dx,y+dy)
This representation gives you natural way of working with image points. You can, for example, easily work with non-rectangular areas, and do tricks like making image interpolation as separate function instead of being part of your usual image scaling algorithms:
quadraticInterpolation :: ((Int,Int) -> Color) -> ((Double,Double) -> Color)
The performance might suffer in some cases, such as when you blit multiple images into one and then do calculations with the result. This results in a chain of tests for each pixel for each successive calculation. However, by applying memoization, we can temporarily render the functional representation into an array and transform that back to it's index function, thus eliminating the performance hit for the successive operations.
Note that the memoization can also be used to introduce parallelism to the process.
So I see graphical models expressed in plate notation in research papers and online all the time (for example: http://www.cs.princeton.edu/~blei/papers/BleiNgJordan2003.pdf).
Is there a quick and easy way to produce these?? I've searched and searched but all I've found are solutions like GraphViz which are really way more powerful than what I need (and hence much more difficult to use). PGF/Tikz seems like my best bet, but again it seems like overkill.
Maybe my best bet is to just produce them in Inkscape, or bite the bullet and learn PGF/Tikz. They're just so popular that I thought there would be a simpler way to churn them out, but maybe not... TIA.
GraphViz really isn't that hard to learn. The basic language is really simple for these kinds of graphs. It took me just a few moments to replicate (more or less) the first example from that pdf, and the nice thing about it is that, due to it's simplicity, it's quite easy to generate graphs procedurally from some other data source.
Digraph fig1 {
rankdir = LR; //order things from left to right
//define alpha and beta as existing
α [shape=circle];
β [shape=circle];
//not strictly nescessary but helps if you want to
//assign them specific shapes or colours
subgraph cluster_M //names beginning with "cluster" get a box drawn, an odd hack
{
label = "M"
θ [shape=circle];
subgraph cluster_N
{
label = "N"
z [shape=circle];
w [shape=circle, style=filled]
z->w; //quite literally z points at w
}
θ -> z;
}
α -> θ;
β -> w;
}
compiled with
dot -Tpng input.txt -o graph.png
it comes out looking like this. If having the labels below the bubbles was important, you could do that with a couple of extra lines, similarly if specific placement of nodes is important you can adjust that too. In fact, if you don't specify an image format, the default behaviour of dot is to output a version of the input file with co-ordinates for the position of each element.
Here is a more refined fork of Dietz's scripts: https://github.com/jluttine/tikz-bayesnet
Check out the excellent Tikz-package by Laura Dietz, available from http://www.mpi-inf.mpg.de/~dietz/probabilistic-models-tikz.zip. A pdf with some examples is available at http://www.mpi-inf.mpg.de/~dietz/probabilistic-models-tikz.pdf.
I really like GLE (Graphics Layout Engine). It's what Christopher Bishop used in his book, "Pattern Recognition and Machine Learning". It has a simple syntax with variables, loops, and functions, and it supports TeX equations. Results output as either pdf or eps and look very nice.
Lots of examples are available, including this Bayes net from PRML.
As a complement to other answers: a "low-skills" approach I've used is to draw them in Google Slides, with some add-on for producing the formulas.