Issue #873: volume rendering set_background does not work (yt_analysis/yt)
New issue 873: volume rendering set_background does not work https://bitbucket.org/yt_analysis/yt/issue/873/volume-rendering-set_backgrou... Cameron Hummels: I tried to make a VR with different background colors by combining the two cookbook recipes: http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#image-backgrou... http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#simple-volume-... The resulting script is here: http://paste.yt-project.org/show/4978/ Unfortunately, the 'background' keyword for `write_png` doesn't seem to work on real VRs. All of the options end up yielding the original all-black background. When I dug into the code to figure out what was going on, it appears the problem is that the color channels are being normalized by the opacity channel prior to adding in the background color, and then renormalized by 1-opacity afterwards. The VRs produced by the standard recipe yield a opacity=1 uniformly across the image, which essentially wipes out any changes from the renormalization. I can rip out this renormalization, or replace it with a rescale() function, but I wanted to make sure that wouldn't break other things. Maybe this isn't worth changing since VR is getting a makeover soon.
Hi Cameron, this answers a question I've had for a white, since I've been trying to get a white background. Two comments on the new cookbook recipe you just posted -- are you sure that "up" is "up" in those images? When I use write_png, my image is upside down. Secondary, do we want to try to pass the transparent/white background stuff through the draw_domain and save_annotated functions? At the moment, draw_domain forces things to be black, and save_annotated sets the facecolor of the resulting plot to black. Mike On Thu, Jul 31, 2014 at 12:12 AM, Cameron Hummels < issues-reply@bitbucket.org> wrote:
New issue 873: volume rendering set_background does not work
https://bitbucket.org/yt_analysis/yt/issue/873/volume-rendering-set_backgrou...
Cameron Hummels:
I tried to make a VR with different background colors by combining the two cookbook recipes:
http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#image-backgrou...
http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#simple-volume-...
The resulting script is here:
http://paste.yt-project.org/show/4978/
Unfortunately, the 'background' keyword for `write_png` doesn't seem to work on real VRs. All of the options end up yielding the original all-black background.
When I dug into the code to figure out what was going on, it appears the problem is that the color channels are being normalized by the opacity channel prior to adding in the background color, and then renormalized by 1-opacity afterwards. The VRs produced by the standard recipe yield a opacity=1 uniformly across the image, which essentially wipes out any changes from the renormalization.
I can rip out this renormalization, or replace it with a rescale() function, but I wanted to make sure that wouldn't break other things. Maybe this isn't worth changing since VR is getting a makeover soon.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
Hi Michael, There are a few of us who are working on rewriting the entire camera interface. It was originally supposed to go out in 3.0, but there were some delays. I think once 3.0 is out, the new interface won't be too far behind. So as far as modifying the draw_domain and save_annotated functions to work within the new background color stuff, it might make more sense to hold off until we get the new framework up and running. But we'll definitely try to keep this functionality interoperable. About the orientation issue, I'm not sure. Perhaps Matt or Sam can speak to the orientation issues with write_png? I see that when we call "write_png" it does this: return write_bitmap(out.swapaxes(0, 1), filename) But then write_bitmap goes to a different (png_writer) write_png, which then goes to use matplotlib's write_png tools. After all that jumping I'm not sure the orientation, but I think there are still some residual orientation issues, as you can see here with the two plots generated here in the docs from nearly identical recipes (off-axis-projections use the camera interface which also makes the volume renderings): http://yt-project.org/docs/dev-3.0/visualizing/plots.html#off-axis-projectio... Again, though, I think this will be mostly addressed through the new camera interface in the next few months. Cameron On Thu, Jul 31, 2014 at 9:07 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Hi Cameron, this answers a question I've had for a white, since I've been trying to get a white background. Two comments on the new cookbook recipe you just posted -- are you sure that "up" is "up" in those images? When I use write_png, my image is upside down. Secondary, do we want to try to pass the transparent/white background stuff through the draw_domain and save_annotated functions? At the moment, draw_domain forces things to be black, and save_annotated sets the facecolor of the resulting plot to black.
Mike
On Thu, Jul 31, 2014 at 12:12 AM, Cameron Hummels < issues-reply@bitbucket.org> wrote:
New issue 873: volume rendering set_background does not work
https://bitbucket.org/yt_analysis/yt/issue/873/volume-rendering-set_backgrou...
Cameron Hummels:
I tried to make a VR with different background colors by combining the two cookbook recipes:
http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#image-backgrou...
http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#simple-volume-...
The resulting script is here:
http://paste.yt-project.org/show/4978/
Unfortunately, the 'background' keyword for `write_png` doesn't seem to work on real VRs. All of the options end up yielding the original all-black background.
When I dug into the code to figure out what was going on, it appears the problem is that the color channels are being normalized by the opacity channel prior to adding in the background color, and then renormalized by 1-opacity afterwards. The VRs produced by the standard recipe yield a opacity=1 uniformly across the image, which essentially wipes out any changes from the renormalization.
I can rip out this renormalization, or replace it with a rescale() function, but I wanted to make sure that wouldn't break other things. Maybe this isn't worth changing since VR is getting a makeover soon.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
Have to run for a while, but I think the main issue with direct PNG writing
and access is that upper left is pixel 0,0. And then we changed our PNG
engine (John?) which may take different code paths.
As for camera, it's getting there - Sam made a lot of progress, and I even
used it for the final seismodome renders. It's in the "scene" bookmark in
my repo. We only didn't finish it because of a desire for polish.
On Jul 31, 2014 11:23 AM, "Cameron Hummels"
Hi Michael,
There are a few of us who are working on rewriting the entire camera interface. It was originally supposed to go out in 3.0, but there were some delays. I think once 3.0 is out, the new interface won't be too far behind. So as far as modifying the draw_domain and save_annotated functions to work within the new background color stuff, it might make more sense to hold off until we get the new framework up and running. But we'll definitely try to keep this functionality interoperable.
About the orientation issue, I'm not sure. Perhaps Matt or Sam can speak to the orientation issues with write_png? I see that when we call "write_png" it does this: return write_bitmap(out.swapaxes(0, 1), filename)
But then write_bitmap goes to a different (png_writer) write_png, which then goes to use matplotlib's write_png tools. After all that jumping I'm not sure the orientation, but I think there are still some residual orientation issues, as you can see here with the two plots generated here in the docs from nearly identical recipes (off-axis-projections use the camera interface which also makes the volume renderings):
http://yt-project.org/docs/dev-3.0/visualizing/plots.html#off-axis-projectio...
Again, though, I think this will be mostly addressed through the new camera interface in the next few months.
Cameron
On Thu, Jul 31, 2014 at 9:07 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Hi Cameron, this answers a question I've had for a white, since I've been trying to get a white background. Two comments on the new cookbook recipe you just posted -- are you sure that "up" is "up" in those images? When I use write_png, my image is upside down. Secondary, do we want to try to pass the transparent/white background stuff through the draw_domain and save_annotated functions? At the moment, draw_domain forces things to be black, and save_annotated sets the facecolor of the resulting plot to black.
Mike
On Thu, Jul 31, 2014 at 12:12 AM, Cameron Hummels < issues-reply@bitbucket.org> wrote:
New issue 873: volume rendering set_background does not work
https://bitbucket.org/yt_analysis/yt/issue/873/volume-rendering-set_backgrou...
Cameron Hummels:
I tried to make a VR with different background colors by combining the two cookbook recipes:
http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#image-backgrou...
http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#simple-volume-...
The resulting script is here:
http://paste.yt-project.org/show/4978/
Unfortunately, the 'background' keyword for `write_png` doesn't seem to work on real VRs. All of the options end up yielding the original all-black background.
When I dug into the code to figure out what was going on, it appears the problem is that the color channels are being normalized by the opacity channel prior to adding in the background color, and then renormalized by 1-opacity afterwards. The VRs produced by the standard recipe yield a opacity=1 uniformly across the image, which essentially wipes out any changes from the renormalization.
I can rip out this renormalization, or replace it with a rescale() function, but I wanted to make sure that wouldn't break other things. Maybe this isn't worth changing since VR is getting a makeover soon.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Ok, if the new VR will follow shortly, then I agree, we should wait. I
almost figured out all the of hacks needed to get a white background (we
discard alpha in some places, like in show_mpl(), we do:
ax = self._pylab.imshow(nim[:,:,:3]/nim[:,:,:3].max(),
origin='lower')
instead of
ax = self._pylab.imshow(nim[:,:,:]/nim[:,:,:].max(), origin='lower')
but there is more going on. So I'll stick with black for now, and help
test the new renderer when it comes online.
But I do think we should have up be up in all the output for 3.0.
On Thu, Jul 31, 2014 at 12:23 PM, Cameron Hummels
Hi Michael,
There are a few of us who are working on rewriting the entire camera interface. It was originally supposed to go out in 3.0, but there were some delays. I think once 3.0 is out, the new interface won't be too far behind. So as far as modifying the draw_domain and save_annotated functions to work within the new background color stuff, it might make more sense to hold off until we get the new framework up and running. But we'll definitely try to keep this functionality interoperable.
About the orientation issue, I'm not sure. Perhaps Matt or Sam can speak to the orientation issues with write_png? I see that when we call "write_png" it does this: return write_bitmap(out.swapaxes(0, 1), filename)
But then write_bitmap goes to a different (png_writer) write_png, which then goes to use matplotlib's write_png tools. After all that jumping I'm not sure the orientation, but I think there are still some residual orientation issues, as you can see here with the two plots generated here in the docs from nearly identical recipes (off-axis-projections use the camera interface which also makes the volume renderings):
http://yt-project.org/docs/dev-3.0/visualizing/plots.html#off-axis-projectio...
Again, though, I think this will be mostly addressed through the new camera interface in the next few months.
Cameron
On Thu, Jul 31, 2014 at 9:07 AM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
Hi Cameron, this answers a question I've had for a white, since I've been trying to get a white background. Two comments on the new cookbook recipe you just posted -- are you sure that "up" is "up" in those images? When I use write_png, my image is upside down. Secondary, do we want to try to pass the transparent/white background stuff through the draw_domain and save_annotated functions? At the moment, draw_domain forces things to be black, and save_annotated sets the facecolor of the resulting plot to black.
Mike
On Thu, Jul 31, 2014 at 12:12 AM, Cameron Hummels < issues-reply@bitbucket.org> wrote:
New issue 873: volume rendering set_background does not work
https://bitbucket.org/yt_analysis/yt/issue/873/volume-rendering-set_backgrou...
Cameron Hummels:
I tried to make a VR with different background colors by combining the two cookbook recipes:
http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#image-backgrou...
http://yt-project.org/docs/dev-3.0/cookbook/simple_plots.html#simple-volume-...
The resulting script is here:
http://paste.yt-project.org/show/4978/
Unfortunately, the 'background' keyword for `write_png` doesn't seem to work on real VRs. All of the options end up yielding the original all-black background.
When I dug into the code to figure out what was going on, it appears the problem is that the color channels are being normalized by the opacity channel prior to adding in the background color, and then renormalized by 1-opacity afterwards. The VRs produced by the standard recipe yield a opacity=1 uniformly across the image, which essentially wipes out any changes from the renormalization.
I can rip out this renormalization, or replace it with a rescale() function, but I wanted to make sure that wouldn't break other things. Maybe this isn't worth changing since VR is getting a makeover soon.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
participants (4)
-
Cameron Hummels -
Cameron Hummels -
Matthew Turk -
Michael Zingale