-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a PNG image output object #13646
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not going to repeat everything in every case. Go ahead and go over this PR and make sure you address each of my comments everywhere where it applies. Let me know if anything doesn't make sense. Nice work!
test/tests/kernels/simple_transient_diffusion/simple_transient_diffusion.i
Outdated
Show resolved
Hide resolved
test/tests/kernels/simple_transient_diffusion/simple_transient_diffusion.i
Outdated
Show resolved
Hide resolved
How about calling this |
PNGObject(const InputParameters & parameters); | ||
|
||
// Method for assigning color values to the PNG | ||
void setRGB(png_byte *rgb, float selection); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this working? You are not including libpng stuff here but use this type in a public interface. Does it have to be public in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably doesn't need to be public. This PR has a ways to go. I'm helping Sam get the right things into the Makefile and then we'll continue to work on the interface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't see a reason any of it should be public except the constructor. Public was just easier to start. Right now I switched everything except the constructor to protected. Not sure if any of it should be private yet. I haven't really thought about what other classes would need from this class, if they'd ever need anything at all.
@Hysrok you might want to look into configuring your editor to automatically run clang-format on save... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - this is my thorough review
@@ -0,0 +1,124 @@ | |||
[Mesh] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Now you need to add the "tests" file so that these actually get run. I'm going to suggest a "CheckFiles" test but we might be able to do better.
@aeslaughter - Can we do a png difference or is that only available within the python testing infrastructure?
@Hysrok - I'm going to recommend that you start your fixes by looking at the non-unity build first. You are missing a lot of headers still... Rule of thumb, if you use a type in your code, include the header (Prefer the .C file unless you have to put it in the .h file). If you want to compile a non-unity build locally set MOOSE_UNITY=false in your environment and rebuild everything. |
@Hysrok - I added one more line to my existing Makefile branch for the include path to the header. We'll need that to make sure we pick up the right version of the |
Just a thought, instead of reinventing the wheel on color output why not use a library like |
Spectrum does look cool - but why does in include QDebug?
On Fri, Jun 28, 2019 at 5:13 PM Daniel Schwen ***@***.***> wrote:
Just a thought, instead of reinventing the wheel on color output why not
use a library like
https://github.com/richardroberts1992/Spectrum
to translate float values into colors taken from a colormap? This might
very well be a follow on PR though.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#13646?email_source=notifications&email_token=AAGUSMMNY4P73K2A5X4TUALP42LJTA5CNFSM4H3NEVWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY3LPIY#issuecomment-506902435>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGUSMIPLMVCVE6NZ542LBTP42LJTANCNFSM4H3NEVWA>
.
--
Sent from my iPhone
|
Yeah, weird. Doesn't seem to use it though. Make a PR? |
b1d1ffc
to
49818fb
Compare
I've been getting this problem a lot today. I found a work around that worked for me, but now it looks like even the moosebuild precheck is having the problem. Is something wrong with GitHub, or am I just doing something wrong? |
If you haven't heard from the MOOSE team. The problem is INL related, not
you. They are still working on a fix as of now. You can use HTTPS instead
of SSH to get around the issue.
…On Wed, Jul 3, 2019 at 7:05 PM Herald of Heraldo ***@***.***> wrote:
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.```
I've been getting this problem a lot today. I found a work around that worked for me, but now it looks like even the moose build checker is having the problem. Is something wrong with GitHub, or am I just doing something wrong?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#13646?email_source=notifications&email_token=AAXFOICC5EF5J6L35NI5XKDP5VEEVA5CNFSM4H3NEVWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZGBB6A#issuecomment-508301560>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAXFOICA2DJ43F2D7MEFRZTP5VEEVANCNFSM4H3NEVWA>
.
|
@Hysrok - Looks like this is failing to build on Linux still. From a quick glance it might be that we are picking up inconsistent headers from libPNG or something. To troubleshoot this, you are going to want to login to a Linux system with the exact same environment as the build systems.
I can help when you get to step #3. I suspect we have some more work todo to get the include and library flags rock solid. |
Job Precheck on 6e158c4 wanted to post the following: Your code requires style changes. A patch was auto generated and copied here
Alternatively, with your repository up to date and in the top level of your repository:
|
Ought oh.... Somehow you have a mess of other peoples commits in here now. Did you forget to rebase? |
Worse yet you clobbered your change you made earlier just before lunch. |
Job Documentation on 985490b wanted to post the following: View the site here This comment will be updated on new commits. |
4488613
to
fb059a3
Compare
- Fixed some formatting errors. - Renamed the classes. - Created tests that don't change the original tests.
-Using inheriting from FileOutput -Input files for the png's aren't worrying about exodus etc -Changed several types -Removed unnecessary hardcoded lines from MakeFile -Fixed naming convention of variables -Added an #IFDEF to the header file
- Added the header files that were missing. - Removed the macros. - Redid filename configurations for created png's. - Using MooseUtils to check file writability.
- Added include path to the header to make sure we get the right version of png.h.
- Added vector to store the row data to help avoid raw memory management. - Revmoved the parameter PNGFile and anywhere it was referenced to. - Added possible blue->red color scheme. Commented out for now.
…select a color scheme - Added additional comments to explain the code
-Wrapped PNGOoutput.C in MOOSE_HAVE_LIBPNG wrapper. -Updated some colors. -Added tranparency options.
-Added PNGOutput.md file -Added "design" parameter in test input files -Set max_parallel parameter to 1 for adv_diff_reaction -Lowered the resolution of created images to avoid getting timed out
Removing duplicates and adding detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! I updated your requirements a bit since we don't accept duplicate requirements anymore. Once this tests successfully I'll get it merged. Let me know when you get in and we can talk about what's next and your poster.
[png] | ||
type = PNGOutput | ||
transparent = true #indicates whether the background will be transparent | ||
resolution = 50 #resolution of each point |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just looking at the documentation strings I have no idea what this number means. The code suggests it is a scale factor to get from MOOSE length units to pixels. I suggest to make this clear in the docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The resolution might be "pixels", except that's not even a great definition with things like retina displays and everything else that complicates rendering sizes. This is the number of "samples" taken in the x and y directions right now but that's not the best solution for resolution, which should be in units per something. Also we need to account for different spacing in x and y. More work to do.
@dschwen - We are going to be working on the next phase of this project now. This capability isn't useful yet on anything but small images because of the extensive use of MeshFunction. It can take minutes to generate a single image on a workstation size run right now. I'm going to merge this in and we will continue to work on documentation and capability as we make this scalable. |
- PNGOutputter restricted to work in dynaimc linkage mode only due to unresolved linkage problem with the library in static mode - Some constness added to member variables - Memory issue fixed refs idaholab#13646
- PNGOutputter restricted to work in dynaimc linkage mode only due to unresolved linkage problem with the library in static mode - Some constness added to member variables - Memory issue fixed refs idaholab#13646
Hmm - I really think pixels is what we want for resolution... ultimately I
want to control the exact size of the PNG.
…On Tue, Jul 16, 2019 at 1:04 PM Cody Permann ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In framework/doc/content/source/outputs/png/PNGOutput.md
<#13646 (comment)>:
> @@ -0,0 +1,18 @@
+# PNGOutput (Outputs)
+
+The PNGOutput object is the class for writing png files from the input files.
+
+Following is an example of all the different input variables that can be used.
+
+```
+[Outputs]
+ [png]
+ type = PNGOutput
+ transparent = true #indicates whether the background will be transparent
+ resolution = 50 #resolution of each point
The resolution might be "pixels", except that's not even a great
definition with things like retina displays and everything else that
complicates rendering sizes. This is the number of "samples" taken in the x
and y directions right now but that's not the best solution for resolution,
which should be in units per something. Also we need to account for
different spacing in x and y. More work to do.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#13646?email_source=notifications&email_token=AAGUSMODS2QS3XYTDOI6WETP7YLTXA5CNFSM4H3NEVWKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB6TU4OQ#discussion_r304072687>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGUSMP64GSPGWMF4U37VMDP7YLTXANCNFSM4H3NEVWA>
.
|
Adds the ability to create PNG files from the data provided by input files.
Can specify desired resolution.
Default output is grayscale, but can be put into color (current color scheme 'low -> high' is 'blue->red->yellow->white')
Can specify to save one specific step PNG (default is to save all steps with filename plus numerical identifier).
Closes #12846