> An: Discussion of the yt analysis package <
yt-users@lists.spacepope.org>
> Betreff: Re: [yt-users] volume rendering
> Hi Maike,
>
> The area of the grid cell in the image plane does not really matter. It
> is
> only the width of the grid cell in the line of sight that factors in.
> Therefore, if you have 10 cells replacing a single cell in the line of
> sight, each of them will contribute 1/10 of the emission. The
> contribution
> of each cell does not go as dx^3, just dx.
>
> Britton
>
> On Tue, Apr 12, 2011 at 11:34 AM, Maike Schmidt
> <
maikeschmidt2@gmx.de>wrote:
>
> > Hi Sam,
> >
> > I still don't understand this. The small ds's will only yield the
> > same integration as the large ds's if the physical width of the
> > isosurface is the same on all refinement levels. If the width is,
> > say, 10 cells on each refinement level, then the smallest ds's
> > will only emit 1/1000 of the contribution of the largest ds's.
> > In fact, if the emission is directly proportional to the RGB value,
> > then even a factor of 100 will make the color so dark that the
> > contribution to the final image is invisible. In this case you
> > would see the isosurface only on the largest scales.
> >
> > Is this what would happen?
> >
> > Cheers,
> > Maike
> >
> >
> >
> > > Hi Maike,
> > >
> > > I think there is some confusion here about how our transfer function
> > > works.
> > > For the ColorTransferFunction, we are really specifying r,g,b
> > > emissivities. For example, let's say that we have chosen to specify
> > that
> > > a
> > > density value of 5 corresponds to rgb = [0.5,0.5,0.5], whatever that
> > color
> > > may be. Now, that does not mean that when the rays pass through an
> area
> > > with a density of 5 that the rgb images will be equal to 0.5,0.5,0.5.
> > > Rather, we will add j*ds to the image plane. If the entire domain
> had a
> > > density of 5, then the resulting image would be (some
> > > factor)*[0.5,0.5,0.5]
> > > where the factor has to do with the integration length. If instead
> the
> > > density=5 region was just in part of the volume, then it would add up
> the
> > > contribution to the final image, and it would be blended along the
> line
> > > of
> > > sight with any other emission from the rest of the volume.
> > >
> > > If you take your example of an AMR sim with 10 levels, then using the
> > > implementation we have written, while the high levels have much
> smaller
> > > ds's, there are many more of them, which will yield roughly the same
> > > integration as had it been down only using the lower resolution data.
> It
> > > is
> > > a lot like an adaptive integration scheme in that sense.
> > >
> > > Does this help? Please let us know.
> > >
> > > Best,
> > > Sam
> > >
> > > On Wed, Apr 6, 2011 at 4:27 AM, Maike Schmidt <
maikeschmidt2@gmx.de>
> > > wrote:
> > >
> > > > Hi Matt,
> > > >
> > > > many thanks for this really nice explanation! But I still
> > > > don't understand how the color transfer function works.
> > > > I thought that, if you add a Gaussian with peak (r,g,b),
> > > > then the intensity that arrives at the camera from cells
> > > > that contain the center of the Gaussian has exactly intensity
> > > > (r,g,b), when I am neglecting absorption. Otherwise I don't
> > > > understand how one can relate the color of the Gaussian
> > > > to the color at the camera.
> > > >
> > > > Now, say I want to visualize an isosurface of density
> > > > on an AMR grid with 10 refinement levels, then the actual
> > > > intensity contribution j * delta s will differ by 3 orders
> > > > of magnitude for cells with the same density but different
> > > > cell size. How do you make all these cells emit the same color?
> > > > This is what I don't understand.
> > > >
> > > > I guess it boils down to the question of how exactly you
> > > > calculate your j in the radiative transfer equation when
> > > > you have a color transfer function, say a single Gaussian
> > > > with peak (r,g,b).
> > > >
> > > > Many thanks,
> > > > Maike
> > > >
> > > >
> > > >
> > > >
> > > > -------- Original-Nachricht --------
> > > > > Datum: Tue, 5 Apr 2011 16:29:02 -0400
> > > > > Von: Matthew Turk <
matthewturk@gmail.com>
> > > > > An: Discussion of the yt analysis package
> > > <
yt-users@lists.spacepope.org>
> > > > > Betreff: Re: [yt-users] volume rendering
> > > >
> > > > > Hi Maike,
> > > > >
> > > > > (I think this is your first post -- welcome to yt-users!)
> > > > >
> > > > > On Tue, Apr 5, 2011 at 11:34 AM, Maike Schmidt
> <
maikeschmidt2@gmx.de
> > >
> > > > > wrote:
> > > > > > Hi together,
> > > > > >
> > > > > > I would like to better understand how the volume rendering
> works.
> > > > > > It is explained here
> > > > > >
> > > > > >
http://yt.spacepope.org/doc/visualizing/volume_rendering.html
> > > > > >
> > > > > > that the user defines transfer functions in terms of RGB values.
> > > > > > From the description of the add_gaussian function, I understand
> > > > > > that these RGB values describe the color value in the interval
> > > > > > [0,1]. Now, in the radiative transfer equation on the above
> > > > > > website, the emissivity gets multiplied by the path length
> > > > > > delta s. I am now wondering how this works: Depending on how
> > > > > > big the step size is, one could get extremely large or extremely
> > > > > > small intensities that are essentially unrelated to the RGB
> > > > > > values that were previously specified. How is it possible that,
> > > > > > for example, the color of a density isosurface depends on the
> > > > > > density only and not on the cell size? I guess I am missing
> > > > > > something.
> > > > > >
> > > > > > Cheers,
> > > > > > Maike
> > > > > >
> > > > >
> > > > > The short answer, I think, is that you are right, you can get very
> > > > > large intensities in large cells that are unrelated to what came
> > > > > before. But, for the most part, this is not an issue because of
> how
> > > > > the weighting and color assignments are typically done.
> > > > >
> > > > > [begin long, rambly answer]
> > > > >
> > > > > There are a couple things in what you ask -- the first is that
> there
> > > > > are two primary methods for volume rendering. The first is to
> tell a
> > > > > story using somewhat abstract visuals; this is typically what
> people
> > > > > think of when they think of volume rendering, and it is supported
> by
> > > > > (and possibly the primary application of) yt. This would be
> what's
> > > > > used when the ColorTransferFunction is used. The other is
> designed
> > to
> > > > > perform a meaningful line integral through the calculation; this
> is
> > > > > what's done with the ProjectionTransferFunction and the
> > > > > PlanckTransferFunction. In all cases, the RT equation *is*
> > > > > integrated, but what varies between the two mechanisms is where
> the
> > > > > emission and absorption values come from.
> > > > >
> > > > > In all cases, while the code may call things RGB, they need not be
> > RGB
> > > > > explicitly. In fact, for the ProjectionTransferFunction, they are
> > > > > not. For the ProjectionTransferFunction, the code simply
> integrates
> > > > > with the emission value being set to the fluid value in a cell and
> > the
> > > > > absorption value set to exactly zero. This results in the
> > > > > integration:
> > > > >
> > > > > dI/ds = v_local
> > > > >
> > > > > Where v_local is the (interpolated) fluid value at every point the
> > > > > integration samples, which defaults to 5 subsamples within a given
> > > > > cell. So the final intensity is equal to the sum of all
> > > > > (interpolated) values along a ray times the (local-to-a-cell) path
> > > > > length between samples. For the PlanckTransferFunction, the local
> > > > > emission is set to some approximation of a black-body, weighted
> with
> > > > > Density for emission, and the absorption is set to an
> approximation
> > of
> > > > > scattering, which we then assign to RGB. The PTF also utilizes a
> > > > > 'weighting' field inside the volume renderer, which I discuss
> briefly
> > > > > below, to allow it to utilize multiple variables at a given
> location
> > > > > to calculate the emission and absorption. (i.e., Temperature
> governs
> > > > > the color, density governs the strength of the emission -- sliding
> > > > > along x and scaling along y, in the plot of the transfer
> function.)
> > > > >
> > > > > When integrating a ColorTransferFunction, the situation is
> somewhat
> > > > > different. I've spent a bit of time reviewing the code, and I
> think
> > I
> > > > > can provide a definite answer to your question. For reference,
> the
> > > > > code that this calls upon is defined in two source files:
> > > > >
> > > > > yt/visualization/volume_rendering/transfer_functions.py
> > > > > yt/utilities/_amr_utils/VolumeIntegrator.pyx
> > > > >
> > > > > Specifically, in the class ColorTransferFunction and in the
> > > > > FIT_get_value and TransferFunctionProxy.eval_transfer functions.
> > > > >
> > > > > The ColorTransferFunction, which is designed for visualizing
> abstract
> > > > > isocontours, rather than computing an actual line integral that is
> > > > > then examined or modified, sets a weighting *table*. (For the
> > > > > PlanckTransferFunction, a weight_field_id is set; this means to
> > > > > multiply the value from a table against a value obtained from
> another
> > > > > field. This is how density-weighted emission is done.) The
> > > > > weight_table_id for CTF is set to the table for the alpha
> emission.
> > > > > Functionally, this means that we accentuate the peaks and spikes
> in
> > > > > the color transfer function, because alpha is typically set quite
> > high
> > > > > at the gaussians included.
> > > > >
> > > > > So in essence, with a color transfer function we accentuate only
> the
> > > > > regions where we have isocontours. I think it's easiest to speak
> > > > > about this in terms of a visualization of Density isocontours. If
> > you
> > > > > place contours in the outer regions, if your emission value is too
> > > > > high, it will indeed obscure completely the inner regions. I have
> > > > > experimented with this and have found that it is extremely easy to
> > > > > create a completely visually confusing image that contains only
> the
> > > > > outer contours and wispy hints of the inner contours.
> > > > >
> > > > > However, even if you do have outer isocontours, if you set the
> > > > > emission and color values lower, you can indeed provide glimpses
> into
> > > > > the inner regions. The inner regions are likely generating
> *higher*
> > > > > emission values (this is certainly how it is done in yt, with the
> > > > > add_layers method on ColorTransferFunction.)
> > > > >
> > > > > Anyway, I hope that helps clear things up a little bit -- but
> please
> > > > > feel free to write back with any further questions about this or
> > > > > anything else.
> > > > >
> > > > > Best,
> > > > >
> > > > > Matt
> > > > >
> > > > > >
> > > > > > --
> > > > > > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> > > > > > gratis Handy-Flat!
http://portal.gmx.net/de/go/dsl
> > > > > > _______________________________________________
> > > > > > yt-users mailing list
> > > > > >
yt-users@lists.spacepope.org
> > > > > >
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> > > > > >
> > > > > _______________________________________________
> > > > > yt-users mailing list
> > > > >
yt-users@lists.spacepope.org
> > > > >
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> > > >
> > > > --
> > > > NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> > > > Jetzt informieren:
http://www.gmx.net/de/go/freephone
> > > > _______________________________________________
> > > > yt-users mailing list
> > > >
yt-users@lists.spacepope.org
> > > >
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> > > >
> >
> > --
> > NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> > Jetzt informieren:
http://www.gmx.net/de/go/freephone
> > _______________________________________________
> > yt-users mailing list
> >
yt-users@lists.spacepope.org
> >
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >