Sumagna Das (Jul 31 2020 at 18:38): Sumagna Das (Jul 31 2020 at 18:38):Sean said:
If we had implemented png support for VOL, that would be sufficient
cant the code convert the png file into bw and before that get the dimensions so that the user doesnt have to input anything(or input the neccesary details only)?
Sean (Jul 31 2020 at 18:40):it certainly could for an ebm. or it could if you specified a series of png files (or maybe if you happened to have a multilayer png which I think is pretty rare?)
Sean (Jul 31 2020 at 18:41):absolutely possible and it would be particularly effective for a 'vol' command that specialized in supporting different data formats
Sumagna Das (Jul 31 2020 at 18:41):what data formats does vol support?
Sean (Jul 31 2020 at 19:17):internally, only one: unsigned char data
Sumagna Das (Jul 31 2020 at 19:17):externally?
Sean (Jul 31 2020 at 19:18):well you can convert pretty much any data to that
Sean (Jul 31 2020 at 19:18):using external tools, like in thusal's example -- he converted png to uchar
Sean (Jul 31 2020 at 19:18):he used png-bw but he just as well could have used photoshop
Sumagna Das (Jul 31 2020 at 19:19):i was thinking about feeding the vol primitive (command or function, whatever it is inside the code) a png file, it will get converted to .bw file inside the code and then use that data
Sean (Jul 31 2020 at 19:20):a .bw file is simply a raw data file. if you have intensity values in a C char array (0-255 valued), that's bw data
Sumagna Das (Jul 31 2020 at 19:20):ohh
Sean (Jul 31 2020 at 19:20):if you have 8-bit rgb data in a char array, that's our .pix file
Sumagna Das (Jul 31 2020 at 19:21):Sumagna Das said:
i was thinking about feeding the
volprimitive (command or function, whatever it is inside the code) a png file, it will get converted to .bw file inside the code and then use that data
you understand the way i talked about? (i might have over-complicated the thing in the message)
Sumagna Das (Jul 31 2020 at 19:21):or couldnt tell you what i mean
Sean (Jul 31 2020 at 19:25):oh, I know exactly what you mean
Sean (Jul 31 2020 at 19:25):yes, there's absolutely no problems doing that.
Sumagna Das (Jul 31 2020 at 19:26):so in which file is the code for vol
Sean (Jul 31 2020 at 19:26):we even have a library for doing exactly that (libicv) that would make it pretty easy to support nearly any image format
Sean (Jul 31 2020 at 19:27):note that there are several objects that have this exact problem -- VOL, EBM, and DSP
Sumagna Das (Jul 31 2020 at 19:27):i will try with one, then try to implement in the others
Sean (Jul 31 2020 at 19:28):vol and ebm take uint8, dsp takes uint16
Sumagna Das (Jul 31 2020 at 19:28):that might make a difference
Sean (Jul 31 2020 at 19:29):there's also texture mapping and projection mapping that take 3-channel uint8
Sean (Jul 31 2020 at 19:29):there's also uv-maps
Sean (Jul 31 2020 at 19:30):typically also 3-channel uint8
Sean (Jul 31 2020 at 19:30):Sumagna Das said:
that might make a difference
if all data access is routed through a library object, it shouldn't matter
Sumagna Das (Jul 31 2020 at 19:30):i wiil try to do that
Sean (Jul 31 2020 at 19:31):this is going to distract from you GUI goals though :)
Sumagna Das (Jul 31 2020 at 19:31):GUI goals?
Sean (Jul 31 2020 at 19:31):oh, I thought you were helping with testing gui stuff
Sumagna Das (Jul 31 2020 at 19:32):naah
Sumagna Das (Jul 31 2020 at 19:32):i am sitting around doing stuff that i can do
Sumagna Das (Jul 31 2020 at 19:32):apart from studying
Sean (Jul 31 2020 at 19:32):that's cool
Sean (Jul 31 2020 at 19:52):you know @Sumagna Das , instead of teaching the vol primitive about images, I would suggest approaching this from a different perspective -- either create a vol command or create a gcv plugin that turns images into geometry
Sumagna Das (Aug 28 2020 at 11:28):Sean said:
you know Sumagna Das , instead of teaching the vol primitive about images, I would suggest approaching this from a different perspective -- either create a vol command or create a gcv plugin that turns images into geometry
any tutorials on gcv plugins?
Sumagna Das (Aug 28 2020 at 11:31):ok found it
Sumagna Das (Aug 28 2020 at 11:38):if i have any problem while making the plugin, i will tell you
Sumagna Das (Aug 28 2020 at 13:42):what should be the mime type?
Sean (Aug 28 2020 at 13:45):depends on what inputs/outputs it's going to handle
Sumagna Das (Aug 28 2020 at 13:45):i used image/png png png
Sumagna Das (Aug 28 2020 at 13:45):but probably its already used
Sean (Aug 28 2020 at 13:45):you can see a list of them in your build_dir/include/bu/mime_types.h
Sean (Aug 28 2020 at 13:45):that's okay
Sumagna Das (Aug 28 2020 at 13:45):i saw them
Sean (Aug 28 2020 at 13:45):so BU_MIME_IMAGE_PNG
Sumagna Das (Aug 28 2020 at 13:45):model/png?
Sumagna Das (Aug 28 2020 at 13:47):will it work?
Sumagna Das (Aug 28 2020 at 13:47):or it doesnt sound right?
Sean (Aug 28 2020 at 13:47):i mean it depends what it is you're creating
Sean (Aug 28 2020 at 13:48):if you're creating a plugin that reads in png files, then it's going to be a GCV_FILTER_READ and it's input is a BU_MIME_IMAGE_PNG
Sumagna Das (Aug 28 2020 at 13:48):right now, it reads in png files. might change the method later if it doesnt work
Sean (Aug 28 2020 at 13:50):the output side of that plugin, assuming it creates geometry, is going to be a GCV_FILTER_WRITE plugin and it'll make BU_MIME_MODEL_VND_BRLCAD_PLUS_BINARY but that plugin already exists as a built-in so you don't have to describe it
Sumagna Das (Aug 28 2020 at 13:50):so do i need to add anything to the mime_cad.types if dont change the input?
Sean (Aug 28 2020 at 13:50):if you wanted to output something different, that'd be a different plugin
Sean (Aug 28 2020 at 13:50):not unless you're creating a new CAD file format ;)
Sumagna Das (Aug 28 2020 at 13:51)::wink:
Sumagna Das (Aug 28 2020 at 13:52):so what do i have to do for png support at least for vol?
Sean (Aug 28 2020 at 13:52):if you expand to additional image types, you'd probably change the image type to BU_MIME_IMAGE_AUTO -- with that you define a validation function that lets the plugin decide if it's something it can handle.
Sean (Aug 28 2020 at 13:52):you should be able to start with just the PNG mime
Sumagna Das (Aug 28 2020 at 13:53):for now, i want it to handle atleast the PNG mime
Sean (Aug 28 2020 at 13:53):and that's BU_MIME_IMAGE_PNG
Sean (Aug 28 2020 at 13:53):that way, someone will be able to run: gcv myfile.png myfile.g
Sean (Aug 28 2020 at 13:54):and gcv will recognize myfile.png as a BU_MIME_IMAGE_PNG and pass it on to your plugin (as nothing else handles that mime)
Sean (Aug 28 2020 at 13:57):you're only the second person to create a gcv plugin, so really curious to see what is and isn't clear. don't know if you're keeping notes or could write up an example, but pretty cool if you can get it figured out
Sumagna Das (Aug 28 2020 at 14:01):I tried following the gcv plugin example in the wiki but couldn't understand much
Sumagna Das (Aug 28 2020 at 14:02):If this example works out, then I might improve the tutorial if I can
Sumagna Das (Aug 28 2020 at 17:45):hey @Sean what header files i need and any reference i can see for the plugin development because i didnt find any good examples or code with proper documentation of what each part is doing
Sumagna Das (Aug 28 2020 at 20:00):do you have any inbuilt gcv plugins in the repo which has got good documentation
Sean (Aug 28 2020 at 20:04):let me see if I can locate a report I have that goes into detail
Sean (Aug 28 2020 at 20:05):other thing is to simply look at what the other plugins are doing, use them as examples
Sumagna Das (Aug 28 2020 at 20:06):which one is the most easiest to understand?
Sean (Aug 28 2020 at 20:06):probably stl or asc
Sumagna Das (Aug 28 2020 at 20:07):ok
Sumagna Das (Aug 28 2020 at 20:12):before looking into them, i have to get the macros and functions understood so will have to look into them after the exams.
Sean (Aug 28 2020 at 20:43):yeah, there are some macros and functions that we take for granted that are used ALL OVER brl-cad, so we're used to seeing them. but by-large I think what's needed most is shell of an example that works.
Sean (Aug 28 2020 at 20:44):maybe we can make one together.. I've actually been meaning to learn the interface more concretely.
Sumagna Das (Aug 29 2020 at 16:51):Sean said:
yeah, there are some macros and functions that we take for granted that are used ALL OVER brl-cad, so we're used to seeing them. but by-large I think what's needed most is shell of an example that works.
after lookng into the macros and functions, i will try to make at least the shell of the example(more like an "hello world" one).
Sumagna Das (Aug 29 2020 at 17:58):any place where i can start looking what a macro or a function is used for?
Sean (Aug 29 2020 at 21:06):all public macros and functions "should" be documented in the top-level include/ directory. that's where all the public api exists for libraries like BU_* and RT_* and BN_* etc. All libs (e.g., libbu) should have a corresponding main header (e.g., include/bu.h) and most have subheaders in subfolders (e.g., include/bu/vls.h).
Sean (Aug 29 2020 at 21:08):feel free to make changes / improvements to the headers for gcv -- that's one of the newest libs so it doesn't have as much documented as the other libs. just submit the changes separate -- do you have commit on the main repo?
Sumagna Das (Aug 30 2020 at 05:13):Sean said:
feel free to make changes / improvements to the headers for gcv -- that's one of the newest libs so it doesn't have as much documented as the other libs. just submit the changes separate -- do you have commit on the main repo?
i havent committed to the main repo ever
Sean (Aug 30 2020 at 05:25):okay, so easiest way to get set up for that is to submit a simple patch -- like if you find some code to clean up, or something you fix, however simple. even submitting this new gcv plugin would work -- submit a patch with a new empty file that is just compiled but doesn't actually have/do anything yet.
Sean (Aug 30 2020 at 05:27):basically the process is that you have to submit a patch so it's clear 1) that you know how to communicate via patches and 2) can provide useful patches that are adequately tested (i.e., no flaws) and 3) that you can adhere to the HACKING dev guide.
Sumagna Das (Aug 30 2020 at 06:54):All I want to say is that I never ever submitted a patch so might need a little help there
Sumagna Das (Aug 30 2020 at 08:41):Sean said:
basically the process is that you have to submit a patch so it's clear 1) that you know how to communicate via patches and 2) can provide useful patches that are adequately tested (i.e., no flaws) and 3) that you can adhere to the HACKING dev guide.
the 2nd and 3rd one i think i can understand but i need help with the 1st one
Sumagna Das (Sep 01 2020 at 07:35):exams finished so i can look into the api now
Sean (Sep 01 2020 at 07:35):woo hoo!
Sean (Sep 01 2020 at 07:35):congratulations @Sumagna Das :)
Sumagna Das (Sep 01 2020 at 07:36):is there any place where it is documented properly except for the header files?
Sean (Sep 01 2020 at 07:37):I'll send you what I have directly
Sumagna Das (Sep 01 2020 at 07:37):ok
Sumagna Das (Sep 01 2020 at 09:57):i saw the api but some macros and definitions are used all over brlcad for which i want to look into their documentation
Sumagna Das (Sep 01 2020 at 09:58):so is their any standalone documentation available for those "everyday use" api or are they documented in the header files?
Sumagna Das (Sep 01 2020 at 11:51):hey @starseeker can you tell me where i can find documentation for BRL-CAD api which is used nearly everywhere?
Sumagna Das (Sep 01 2020 at 11:54):is there a way i can use doxygen to generate their documentation?
starseeker (Sep 01 2020 at 11:56):The "dox" target should generate doxygen output
starseeker (Sep 01 2020 at 11:56):I'm not sure what state it is in though - it's been a while since anyone has checked it.
Sumagna Das (Sep 01 2020 at 11:57):then while trying to build, it will be somewhat checked
Sumagna Das (Sep 01 2020 at 11:59):our lelectricity is gone for some reason so i thought i would check if there's an offline way to see the api as with the electricity, my wifi is gone too
starseeker (Sep 01 2020 at 12:01):Ah. Yes, if you have the necessary tools installed the "make dox" target will produce the Doxygen output in <build_dir>/doc/doxygen_output
Sumagna Das (Sep 01 2020 at 12:05):it is giving some warnings
Sumagna Das (Sep 01 2020 at 12:10):Build Time: Tue Sep 1 17:34:24 2020
Built target timestamp
Scanning dependencies of target dox
Generating ../../doc/doxygen_output/html/index.html
warning: Tag 'PERL_PATH' at line 1799 of file '/mnt/sda2/github/brlcad/build/CMakeTmp/Doxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
warning: Tag 'MSCGEN_PATH' at line 1820 of file '/mnt/sda2/github/brlcad/build/CMakeTmp/Doxyfile' has become obsolete.
To avoid this warning please remove this line from your configuration file or upgrade it using "doxygen -u"
/mnt/sda2/github/brlcad/include/bu/dylib.h:75: warning: end of file while inside a group
/mnt/sda2/github/brlcad/include/bu/mime.h:96: warning: unbalanced grouping commands
/mnt/sda2/github/brlcad/include/bu/process.h:166: warning: unbalanced grouping commands
/mnt/sda2/github/brlcad/include/bn/vectfont.h:85: warning: unbalanced grouping commands
/mnt/sda2/github/brlcad/include/bn/vlist.h:328: warning: unbalanced grouping commands
/mnt/sda2/github/brlcad/include/brep/curvetree.h:36: warning: include file map not found, perhaps you forgot to add its directory to INCLUDE_PATH?
/mnt/sda2/github/brlcad/include/brep/util.h:38: warning: include file cstring not found, perhaps you forgot to add its directory to INCLUDE_PATH?
/mnt/sda2/github/brlcad/include/rt/calc.h:185: warning: unbalanced grouping commands
/mnt/sda2/github/brlcad/include/bn/dvec.h:756: warning: documented symbol 'typedef fastf_t pt2d_t' was not declared or defined.
warning: Included by graph for 'defines.h' not generated, too many nodes (63), threshold is 50. Consider increasing DOT_GRAPH_MAX_NODES.
warning: Included by graph for 'vls.h' not generated, too many nodes (51), threshold is 50. Consider increasing DOT_GRAPH_MAX_NODES.
warning: Included by graph for 'common.h' not generated, too many nodes (238), threshold is 50. Consider increasing DOT_GRAPH_MAX_NODES.
warning: Include graph for 'raytrace.h' not generated, too many nodes (86), threshold is 50. Consider increasing DOT_GRAPH_MAX_NODES.
warning: Included by graph for 'vmath.h' not generated, too many nodes (98), threshold is 50. Consider increasing DOT_GRAPH_MAX_NODES.
/mnt/sda2/github/brlcad/include/common.h:469: warning: explicit link request to 'define' could not be resolved
/mnt/sda2/github/brlcad/include/common.h:479: warning: explicit link request to 'define' could not be resolved
/mnt/sda2/github/brlcad/include/common.h:489: warning: explicit link request to 'define' could not be resolved
/mnt/sda2/github/brlcad/include/common.h:493: warning: explicit link request to 'define' could not be resolved
/mnt/sda2/github/brlcad/include/common.h:503: warning: explicit link request to 'define' could not be resolved
/mnt/sda2/github/brlcad/include/common.h:515: warning: explicit link request to 'define' could not be resolved
/mnt/sda2/github/brlcad/include/bu/vls.h:680: warning: The following parameters of bu_vls_incr(struct bu_vls *name, const char *regex_str, const char *incr_spec, bu_vls_uniq_t uniq_test, void *data) are not documented:
parameter 'uniq_test'
parameter 'data'
/mnt/sda2/github/brlcad/include/bu/file.h:168: warning: explicit link request to 'define' could not be resolved
/mnt/sda2/github/brlcad/include/wdb.h:477: warning: The following parameters of mk_bot_w_normals_and_uvs(struct rt_wdb *fp, const char *name, unsigned char mode, unsigned char orientation, unsigned char flags, size_t num_vertices, size_t num_faces, const fastf_t *vertices, const int *faces, const fastf_t *thickness, struct bu_bitv *face_mode, size_t num_normals, fastf_t *normals, int *face_normals, size_t num_uvs, fastf_t *uvs, int *face_uvs) are not documented:
parameter 'num_uvs'
parameter 'uvs'
parameter 'face_uvs'
Built target dox
these are the warnings
starseeker (Sep 01 2020 at 12:12):It shouldn't matter too much as long as the output gets generated.
Sumagna Das (Sep 01 2020 at 12:14):it was generated but all i want to know is that are these warnings going to tamper the generated output?
starseeker (Sep 01 2020 at 12:19):I wouldn't expect them to.
Sumagna Das (Sep 01 2020 at 12:20):then its ok for me
starseeker (Sep 01 2020 at 12:20):A few are issues to fix - I'm looking at it now - but you'll mostly still be able to see what you need, if it is there to begin with.
starseeker (Sep 01 2020 at 12:20):I don't know that GCV has had a lot of attention for doxygen formatting
starseeker (Sep 01 2020 at 12:21):The API was largely experimental when it was originally written, and doxygen documenting is usually done once an API is considered more stable.
Sumagna Das (Sep 01 2020 at 12:21):i got gcv reference material. all i wanted was at least some api reference
Sean (Sep 01 2020 at 18:02):I fixed the first half of those issues just now. Pretty simple typos and copy-paste errors for the most part.
Sean (Sep 01 2020 at 18:03):@Sumagna Das if you update, you should see many of them disappear with the recent commits. would you like to try tackling the rest? or stay focused on gcv? no wrong answer. ;)
Sumagna Das (Sep 01 2020 at 18:04):i havent really ever tried doxygen. this was my first time. so i think it would take me more time to try fix them
Sumagna Das (Sep 01 2020 at 18:04):so i think i would stay focused on gcv
Sean (Sep 01 2020 at 18:05):okay, no worries, just fixed two more.
Sumagna Das (Sep 01 2020 at 18:05):ooh
Sean (Sep 01 2020 at 18:06):if you are curious, you can run"svn diff -cREV" to see what changes have been made, for example, svn diff -c77024 shows how I handled the two lines for vectfont.h and vlist.h that said "warning: unbalanced grouping commands"
Sumagna Das (Sep 01 2020 at 18:07):i might have to update my local copy
Sean (Sep 01 2020 at 18:07):you can see similar changes in the last few commits
Sean (Sep 01 2020 at 18:08):basically, each one of those warnings is pretty much a mistake, but nothing critical so it keeps processing
Sumagna Das (Sep 01 2020 at 18:08):it did generate the documentation
Sean (Sep 01 2020 at 18:09):as is expected, yes
Sean (Sep 01 2020 at 18:10):there's a chance it might get a dependency graph wrong or might put some symbols into the wrong group is all that might have gone wrong
Sean (Sep 01 2020 at 18:10):should all still be there
Sumagna Das (Sep 01 2020 at 18:10):this documentation was the reference i needed before making the plugin
Sumagna Das (Sep 02 2020 at 14:09):in the first example, i see that it "filters"
Sumagna Das (Sep 02 2020 at 14:10):by filtering, does it mean that it just finds out that is there capabilities available for import and export of a specific file or mime type?
Sean (Sep 02 2020 at 15:18):no
Sean (Sep 02 2020 at 15:19):there's three types of plugins
Sean (Sep 02 2020 at 15:19):[import] –> [filter] –> [export]
Sean (Sep 02 2020 at 15:23):{file} –> [import_plugin] –> {geometry}, i.e., an importer typically reads from a file or other source and converts it into gcv's geometry format
Sean (Sep 02 2020 at 15:24):a filter processes gcv geometry, i.e., {geometry} –> [filter_plugin] –> {geometry'}
Sean (Sep 02 2020 at 15:25):and lastly, an exporter typically does the opposite of an importer, {geometry} –> [export_plugin] –> {file}
Sean (Sep 02 2020 at 15:30):so in the case of vol png support, that could take several forms.
Sean (Sep 02 2020 at 15:30):option A: there could specifically be a [vol_from_png_import_plugin] that reads a png file and outputs vol geometry.
Sean (Sep 02 2020 at 15:33):option B: there could be a general [icv_import_plugin] that reads a png (and any other icv format) and outputs binunif data object(s) and a [img_to_vol_plugin] that turns binunif(s) into a vol.
Sumagna Das (Sep 02 2020 at 21:04):I followed the example and built a so called plugin
Sumagna Das (Sep 02 2020 at 21:04):But how do I test it?
Sumagna Das (Sep 02 2020 at 21:11):@Sean i tried to build it but these errors came up
Sumagna Das (Sep 02 2020 at 21:11):Scanning dependencies of target libgcv_vol-obj
[100%] Building C object src/libgcv/plugins/vol/CMakeFiles/libgcv_vol-obj.dir/png_read.c.o
/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:51:34: error: enum conversion from ‘int’ to ‘enum <anonymous>’ in initialization is invalid in C++ [-Wc
++-compat]
51 | "PNG Reader", GCV_FILTER_READ, BU_MIME_IMAGE_PNG,
| ^~~~~~~~~~~~~~~~~
/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:51:34: note: (near initialization for ‘gcv_conv_png_read.mime_type’)

/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:52:3: error: initialization of ‘int (*)(const char *)’ from incompatible pointer type ‘void (*)(struct
bu_opt_desc **, void **)’ [-Wincompatible-pointer-types]
52 | create_opts, free_opts, png_read
| ^~~~~~~~~~~
/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:52:3: note: (near initialization for ‘gcv_conv_png_read.data_supported’)
/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:52:16: error: initialization of ‘void (*)(struct bu_opt_desc **, void **)’ from incompatible pointer ty
pe ‘void (*)(void *)’ [-Wincompatible-pointer-types]
52 | create_opts, free_opts, png_read
| ^~~~~~~~~
/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:52:16: note: (near initialization for ‘gcv_conv_png_read.create_opts_fn’)
/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:52:27: error: initialization of ‘void (*)(void *)’ from incompatible pointer type ‘int (*)(struct gcv_c
ontext *, const struct gcv_opts *, const void *, const char *)’ [-Wincompatible-pointer-types]
52 | create_opts, free_opts, png_read
| ^~~~~~~~
/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:52:27: note: (near initialization for ‘gcv_conv_png_read.free_opts_fn’)
/mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:53:1: error: missing initializer for field ‘filter_fn’ of ‘const struct gcv_filter’ [-Werror=missing-fi
eld-initializers]
53 | };
| ^
In file included from /mnt/sda2/github/brlcad/src/libgcv/plugins/vol/png_read.c:3:
/mnt/sda2/github/brlcad/include/gcv/api.h:190:18: note: ‘filter_fn’ declared here
190 | int (* const filter_fn)(struct gcv_context *context, const struct gcv_opts *gcv_options, const void *options_data, const char *target);
| ^~~~~~~~~
cc1: all warnings being treated as errors
make[3]: *** [src/libgcv/plugins/vol/CMakeFiles/libgcv_vol-obj.dir/build.make:63: src/libgcv/plugins/vol/CMakeFiles/libgcv_vol-obj.dir/png_read.c.o] Error 1
make[2]: *** [CMakeFiles/Makefile2:24415: src/libgcv/plugins/vol/CMakeFiles/libgcv_vol-obj.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:23798: src/libgcv/plugins/CMakeFiles/libgcv_plugins.dir/rule] Error 2
make: *** [Makefile:4149: libgcv_plugins] Error 2
png_read.c The example plugin
Sumagna Das (Sep 02 2020 at 21:18):I'mma go to sleep
Sumagna Das (Sep 02 2020 at 21:18):Please check it and tell me what the problem is
Sean (Sep 02 2020 at 21:18):will do @Sumagna Das
Sean (Sep 02 2020 at 21:19):at a glance, it looks like you've got your arguments wrong
Sumagna Das (Sep 02 2020 at 21:19):I mostly followed the GCV reference
Sean (Sep 02 2020 at 21:19):your option callback functions aren't right either
Sumagna Das (Sep 02 2020 at 21:20):Hmm
Sean (Sep 02 2020 at 21:20):it can't be taken literally, it's just a guide and is out of date on little details
Sean (Sep 02 2020 at 21:20):notice the date on it
Sumagna Das (Sep 02 2020 at 21:20):Yea
Sumagna Das (Sep 02 2020 at 21:20):I was taking it literally
Sean (Sep 02 2020 at 21:20):the code has continued to evolve and improve. the existing headers have to be used for the exact signatures and types
Sumagna Das (Sep 02 2020 at 21:21):Then if there is any errors while following the guide, they can be fixed
Sumagna Das (Sep 02 2020 at 21:21):In the guide
Sean (Sep 02 2020 at 21:21):and I mean the error messages say exactly what the problem is too :smile:
Sean (Sep 02 2020 at 21:21):of course, yes
Sumagna Das (Sep 02 2020 at 21:22):I mean yea they tell me what the problem is but I can't fix it on my own obviously
Sean (Sep 02 2020 at 21:22):that's part of the reason it wasn't posted when it was first written. problems were seen while reviewing it and the code was improved, but then ran out of time to go back to the document
Sean (Sep 02 2020 at 21:23):Sumagna Das said:
I mean yea they tell me what the problem is but I can't fix it on my own obviously
sure you can :)
Sumagna Das (Sep 02 2020 at 21:23):I might fix it while trying to make the plugin accordingly
Sean (Sep 02 2020 at 21:23):take them one at a time -- the first one, for example, says you provided an int and it wants an enum
Sumagna Das (Sep 02 2020 at 21:23):I can't fix them if don't get at least some help I mean
Sumagna Das (Sep 02 2020 at 21:24):I will do it tomorrow
Sumagna Das (Sep 02 2020 at 21:24):I just shut down my laptop
Sean (Sep 02 2020 at 21:24):no worries
Sean (Sep 02 2020 at 21:24):happy to help. post your code when you can.
Sumagna Das (Sep 02 2020 at 21:24):It is there
Sumagna Das (Sep 02 2020 at 21:25):png_read.c The example plugin
Sumagna Das (Sep 02 2020 at 21:25):Here it is again
Sean (Sep 02 2020 at 21:25):oh, great. yeah, I missed that.
Sumagna Das (Sep 02 2020 at 21:25):Bye for now
Sean (Sep 02 2020 at 21:25):cya tomorrow!
Sean (Sep 02 2020 at 21:26):yeah, this looks good. super close.
Sean (Sep 02 2020 at 21:28):yeah, main issue is looks like an additional callback was added to struct gcv_filter, so all your callbacks are in the wrong position
Sean (Sep 02 2020 at 21:29):which is in that list of errors as "error: missing initializer for field ..."
Sean (Sep 02 2020 at 21:31):it's saying you're missing the last one (filter_fn) and then displaying errors on all the ones before it because it's missing the "can read" function.
Sean (Sep 02 2020 at 21:31):4th position in struct gcv_filter
Sumagna Das (Sep 03 2020 at 05:37):hey @Sean you there?
Sean (Sep 03 2020 at 05:37):maybe
Sean (Sep 03 2020 at 05:41):did you have a question @Sumagna Das ? :smile:
Sumagna Das (Sep 03 2020 at 05:42):yea let me get my editor ready
Sumagna Das (Sep 03 2020 at 05:46):now tell me what were the problems
Sumagna Das (Sep 03 2020 at 05:53):i mean which callback function is causing the problems
Sumagna Das (Sep 03 2020 at 06:07):I see it's missing the data_supported callback function
Sean (Sep 03 2020 at 06:50):right, that is what caused like 5 of the errors displayed
Sean (Sep 03 2020 at 06:50):the enum one is new, probably caused by c++ compilation, so may just need a cast.
Sean (Sep 03 2020 at 06:58):@Sumagna Das your new test filter actually exposes a flawed assumption in the filter API. it is presently expecting a bu_mime_model_t type. Instead of "BU_MIME_IMAGE_PNG", just leave that in a comment and use BU_MIME_MODEL_UNKNOWN instead.
Sumagna Das (Sep 03 2020 at 07:52):Ok
Sumagna Das (Sep 03 2020 at 07:53):So what should be there for data_supported
Sumagna Das (Sep 03 2020 at 10:46):Sean said:
the enum one is new, probably caused by c++ compilation, so may just need a cast.
what should it be casted to?
Sumagna Das (Sep 03 2020 at 10:46):Sean said:
Sumagna Das your new test filter actually exposes a flawed assumption in the filter API. it is presently expecting a bu_mime_model_t type. Instead of "BU_MIME_IMAGE_PNG", just leave that in a comment and use BU_MIME_MODEL_UNKNOWN instead.
will do that
Sumagna Das (Sep 03 2020 at 10:59):Sumagna Das said:
Sean said:
the enum one is new, probably caused by c++ compilation, so may just need a cast.
what should it be casted to?
casting it to bu_mime_model_t worked quite well
Sumagna Das (Sep 03 2020 at 10:59):all that is left is data_supported
Sumagna Das (Sep 03 2020 at 11:21):made a placeholder data_supported function (all of the functions are placeholders anyways)
Sumagna Das (Sep 03 2020 at 11:21):now it is working
Sumagna Das (Sep 03 2020 at 11:21):building successfully
Sumagna Das (Sep 03 2020 at 11:28):how to test if the example plugin is atleast working?
Sumagna Das (Sep 03 2020 at 11:54):the plugin is building successfully but probably it is resulting in a segfault
Sumagna Das (Sep 03 2020 at 12:51):what should be the command for testing it out?
Sumagna Das (Sep 03 2020 at 14:02):the plugin is building successfully but probably it is resulting in a segfault
This is unnecessary (I was testing it inappropriately)
Sumagna Das (Sep 03 2020 at 17:45):@Sean what next? the build part is successful
Sean (Sep 03 2020 at 18:41):Sumagna Das said:
casting it to bu_mime_model_t worked quite well
Except that will be wrong. That's forcing one enum type to another, so casting will actually make it mean something else. BU_MIME_MODEL_UNKNOWN gave an error?
Sumagna Das (Sep 03 2020 at 18:41):lemme try
Sean (Sep 03 2020 at 18:41):Sumagna Das said:
how to test if the example plugin is atleast working?
print statements in the callback functions is always a good start
Sumagna Das (Sep 03 2020 at 18:42):how to call the plugin or run it?
Sean (Sep 03 2020 at 18:43):I'd have to consult that doc I sent you myself, I don't recall
Sean (Sep 03 2020 at 18:43):man page might have an example
Sumagna Das (Sep 03 2020 at 18:43):for gcv?
Sean (Sep 03 2020 at 18:43):yes
Sumagna Das (Sep 03 2020 at 18:44):BU_MIME_MODEL_UNKNOWN doesnt give an error
Sumagna Das (Sep 03 2020 at 18:48):Sean said:
man page might have an example
cant access man page
Sumagna Das (Sep 03 2020 at 20:49):man page is giving some "nearly impossible to read" language
Sean (Sep 03 2020 at 21:48):how are you trying to read it?
Sean (Sep 03 2020 at 21:51):man pages are a form of troff, a really old markup language and macros. you don't read them directly, you read them with manual page apps. run "man rt" for example. that said, I just checked and gcv doesn't have a manual page
Sean (Sep 03 2020 at 21:51):he doc I sent you is the most up-to-date, and it's obviously not ;)
Sumagna Das (Sep 04 2020 at 06:06):the installed gcv binary has no manual entry
Sean (Sep 04 2020 at 06:07):hence "I just checked and gcv doesn't have a manual page" :)
Sumagna Das (Sep 04 2020 at 06:08):The gcv that is present in the build directory has some serious problems regarding man page
Sean (Sep 04 2020 at 06:09):what do you mean?
Sumagna Das (Sep 04 2020 at 06:09):I used man bin/gcv
Sumagna Das (Sep 04 2020 at 06:09):And it showed some random characters which don't know the meaning of
Sean (Sep 04 2020 at 06:09):ah, that's not how man works
Sumagna Das (Sep 04 2020 at 06:09):Oo
Sean (Sep 04 2020 at 06:10):rather -- if you're providing a full path to a man page to the 'man' command, it's (apparently) going to assume it's a manual page
Sean (Sep 04 2020 at 06:11):That's probably a behavior of the linux 'man' command.
Sean (Sep 04 2020 at 06:11):BSD 'man' does this:
agua:.build morrison$ man bin/gcv
No manual entry for bin/gcv
Hmm
Sean (Sep 04 2020 at 06:11):still, proper usage would just be "man [command]"
Sean (Sep 04 2020 at 06:11):"man gcv" for example
Sumagna Das (Sep 04 2020 at 06:12):it has no manual entry on my laptop too
Sean (Sep 04 2020 at 06:12):yes....
Sean (Sep 04 2020 at 06:13):because as I've said... "gcv doesn't have a manual page"
Sean (Sep 04 2020 at 06:13):it does not exist
Sean (Sep 04 2020 at 06:13):there isn't one
Sean (Sep 04 2020 at 06:13):no entry, not going to work
Sean (Sep 04 2020 at 06:14):so ... you can see examples of commands that do work if you like, since it sounds like you're new to man?? but that won't help you with gcv.
Sean (Sep 04 2020 at 06:14):like "man find" or "man gcc" or "man cat" to see a variety
Sean (Sep 04 2020 at 06:15):inside mged, there is a manual page for 99% of commands (but again, NOT gcv apparently), so you can run "man rt" and "man search" and "man in" etc
Sean (Sep 04 2020 at 06:15):on the mged> command line that is
Sumagna Das (Sep 04 2020 at 10:47):I have used man but not so often
Sumagna Das (Sep 05 2020 at 13:36):so what should be the way to test the example plugin?
Sumagna Das (Sep 05 2020 at 17:56):couldnt find anything anywhere
Sean (Sep 06 2020 at 05:12):If it compiles, pull a patch together and post it here or to our patches tracker and I can test it, see if I can figure it out more directly.
Sean (Sep 06 2020 at 05:12):be sure to svn add your new files so they're included when you run "svn diff > my_changes.patch"
Sumagna Das (Sep 06 2020 at 05:13):yea it compiles
Sumagna Das (Sep 06 2020 at 05:16):see if this patch works
Sumagna Das (Sep 06 2020 at 05:16): Sean (Sep 06 2020 at 05:18):applied cleanly
Sean (Sep 06 2020 at 05:29):compiled cleanly, but the plugin gets quickly disabled for not having registered itself (I think)
Sean (Sep 06 2020 at 05:30):agua:.build morrison$ bin/gcv -i ./share/tclscripts/mged/mike-tux.png -o mike_tux.g
Input file format: AUTO
Output file format: BU_MIME_MODEL_VND_BRLCAD_PLUS_BINARY
Input file path: ./share/tclscripts/mged/mike-tux.png
Output file path: mike_tux.g
dlsym(0x7fb7b28006f0, gcv_plugin_info): symbol not found
Unable to load symbols from '/Users/morrison/brlcad.trunk/.build/lib/libgcv_plugins/libgcv_vol.dylib' (skipping)
Could not find 'gcv_plugin_info' symbol in plugin
Setting PROJ_LIB to /Users/morrison/brlcad.trunk/.build/share/proj
Driver: PNG/Portable Network Graphics
Files: ./share/tclscripts/mged/mike-tux.png
Size is 370, 376
Coordinate System is `'
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 376.0)
Upper Right ( 370.0, 0.0)
Lower Right ( 370.0, 376.0)
Center ( 185.0, 188.0)
Band 1 Block=370x1 Type=Byte, ColorInterp=Red
Band 2 Block=370x1 Type=Byte, ColorInterp=Green
Band 3 Block=370x1 Type=Byte, ColorInterp=Blue
Elevation Minimum/Maximum: 0.000000, 255.000000
zone: 31
epsg: 2147483647
ERROR 1: The transformation is already "north up" or a transformation between pixel/line and georeferenced coordinates cannot be computed for ./share/tclscripts/mged/mike-tux.png. There is no affine transformation and no GCPs. Specify transformation option SRC_METHOD=NO_GEOTRANSFORM to bypass this check.
Segmentation fault: 11
It was handed over to the 'gdal' plugin, which can also handle image data (it creates DSP displacement map geometry i.e., height field objects i.e., terrain geometry)
Sean (Sep 06 2020 at 05:50):since it was clean/flawless, I applied your patch. this is definitely in the right direction.
Sean (Sep 06 2020 at 06:01):as you can hopefully see, it tried to load the plugin, but failed... "dlsym(0x7fb7b28006f0, gcv_plugin_info): symbol not found""
Sean (Sep 06 2020 at 06:02):that symbol is not found because you didn't provide it or export it. it's the line that has COMPILER_DLLEXPORT
Sean (Sep 06 2020 at 06:15):there, if you svn up , you should see the update where I fixed it so it at least is loading now.
Sumagna Das (Sep 06 2020 at 06:46):Thanks for fixes
Sumagna Das (Sep 06 2020 at 10:53):Sean said:
that symbol is not found because you didn't provide it or export it. it's the line that has COMPILER_DLLEXPORT
where to include that?
Sean (Sep 06 2020 at 14:14):@Sumagna Das if you updated, you can see it in the file
Sean (Sep 06 2020 at 14:14):can also run svn log and svn diff to see the edits made
Sumagna Das (Sep 06 2020 at 15:43):lemme see
Sumagna Das (Sep 06 2020 at 16:06):saw the part where you added it
Sumagna Das (Sep 06 2020 at 17:44):sumagnadas@hp-laptop:/mnt/sda2/github/brlcad/build$ bin/gcv -i ./share/tclscripts/mged/mike-tux.png -o ./mike_tux.g
Input file format: AUTO
Output file format: BU_MIME_MODEL_VND_BRLCAD_PLUS_BINARY
Input file path: ./share/tclscripts/mged/mike-tux.png
Output file path: ./mike_tux.g
Setting PROJ_LIB to /mnt/sda2/github/brlcad/build/share/proj
Driver: PNG/Portable Network Graphics
Files: ./share/tclscripts/mged/mike-tux.png
Size is 370, 376
Coordinate System is `'
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 376.0)
Upper Right ( 370.0, 0.0)
Lower Right ( 370.0, 376.0)
Center ( 185.0, 188.0)
Band 1 Block=370x1 Type=Byte, ColorInterp=Red
Band 2 Block=370x1 Type=Byte, ColorInterp=Green
Band 3 Block=370x1 Type=Byte, ColorInterp=Blue
Elevation Minimum/Maximum: 0.000000, 255.000000
zone: 31
epsg: 2147483647
ERROR 1: The transformation is already "north up" or a transformation between pixel/line and georeferenced coordinates cannot be computed for ./share/tclscripts/mged/mike-tux.png. There is no affine transformation and no GCPs. Specify transformation option SRC_METHOD=NO_GEOTRANSFORM to bypass this check.
ERROR 1: No source dataset specified.
ERROR 10: Pointer 'hDS' is NULL in 'GDALGetProjectionRef'.
ERROR 6: No translation for an empty SRS to PROJ.4 format is known.
Finalized dataset info:
ERROR 10: Pointer 'hDS' is NULL in 'GDALGetRasterBand'.
ERROR 10: Pointer 'hBand' is NULL in 'GDALGetRasterMinimum'.
ERROR 10: Pointer 'hBand' is NULL in 'GDALGetRasterMaximum'.
ERROR 10: Pointer 'hBand' is NULL in 'GDALComputeRasterMinMax'.
Elevation Minimum/Maximum: 0.000000, 0.000000
ERROR 10: Pointer 'hDS' is NULL in 'GDALGetRasterBand'.
ERROR 10: Pointer 'hBand' is NULL in 'GDALGetRasterBandXSize'.
ERROR 10: Pointer 'hBand' is NULL in 'GDALGetRasterBandYSize'.
ERROR: alloc size=0 (cnt=0, sz=2) unsigned short array
ERROR: bu_malloc(0)
ERROR: bu_malloc(0)
Saving stack trace to gcv-44121-bomb.log
bu_semaphore_free(): pthread_mutex_destroy() failed on [6] of [10]
@Sean i dont know if you know this but it failed and it outputted this thing
Sean (Sep 06 2020 at 18:54):yes, if you step through in a debugger, you'll see that it goes through each plugin, tries your png_read plugin, and the plugin callback that determines if it can handle that type reports "no", so it proceeds
Sean (Sep 06 2020 at 18:55):it then asks the gdal plugin which also supports any type, it's routine says it can handle png, and then the gdal plugin fails to actually handle it
Sumagna Das (Sep 06 2020 at 18:58):the next part is going to be handled in the plugin itself which is not yet done
Sumagna Das (Sep 06 2020 at 19:35):can gdal be taken as an example for this plugin as it also handles png files
Sean (Sep 06 2020 at 19:38):not really
Sean (Sep 06 2020 at 19:39):gdal is a system that reads a ton of terrain formats so it can create terrain geometry. it handles a dozen different image formats internally, one of them being png. the plugin doesn't interact directly with png, it all goes through the gdal library.
Sean (Sep 06 2020 at 19:39):i mean all the converters are worth looking at as examples in some sense.
Sumagna Das (Sep 06 2020 at 19:40):any plugin which directly interacts with png?
Sean (Sep 06 2020 at 19:40):I also think you'd probably have better luck reading in via our libicv instead of directly writing libpng code
Sumagna Das (Sep 06 2020 at 19:41):can do that
Sumagna Das (Sep 06 2020 at 19:41):i will have to get acquainted with libicv then
Sean (Sep 06 2020 at 19:43):lots of fairly simple examples of it in src/util
Sean (Sep 06 2020 at 19:43):for example src/util/bwfilter.c or src/util/pix-bw.c
Sumagna Das (Sep 06 2020 at 20:48):Thanks for giving me some suggestions
Sumagna Das (Sep 06 2020 at 20:48):Won't have time tomorrow so I will look into that the day after tomorrow.
Sumagna Das (Sep 08 2020 at 13:04):can i make a very extremely simple documentation for libicv?
Sumagna Das (Sep 08 2020 at 13:04):if it is needed
Sean (Sep 08 2020 at 14:54):@Sumagna Das haha, of course! Please do. Anything you write is appreciated. Simple way to get started is a google doc or wiki page, of course, but if you want to hook it into the repo, can add a doc/docbook/system/man3/libicv.xml or could write it all up as doxygen comments and commit.
Sean (Sep 08 2020 at 16:20):@Sumagna Das if you need any help or pointer, let me know -- it'll help if you submit it as a patch since that's our essential onboarding in order to obtain commit access (have to have 2 pristine patches).
Sean (Sep 08 2020 at 16:20):if you do the wiki route or something else, no worries.
Sean (Sep 08 2020 at 16:20):still useful and helpful!
Sumagna Das (Sep 08 2020 at 17:45):Sean said:
Sumagna Das if you need any help or pointer, let me know -- it'll help if you submit it as a patch since that's our essential onboarding in order to obtain commit access (have to have 2 pristine patches).
what do you mean by pristine patches?
Sumagna Das (Sep 08 2020 at 17:52):(deleted)
Sean (Sep 08 2020 at 18:05):typically that means patches that don't have some quality or maintenance issue that has to be undone or corrected in order to apply it.
Sumagna Das (Sep 08 2020 at 18:06):ooh
Sean (Sep 08 2020 at 18:06):small patches that do simple things is ideal, harder to mess anything up
Sean (Sep 08 2020 at 18:11):if it communicates a code change without causing additional work for others (e.g. not calling some function HACKING requires, or throwing an error/warning when compiling , or expressing some obvious bug / broken behavior, or having inconsistent code style, etc), that's generally the measure for a pristine patch.
Sumagna Das (Sep 08 2020 at 18:12):understood
Sean (Sep 08 2020 at 18:12):note that does not preclude "works in progress" patches -- those are fine so long as they don't have other issues.
Sean (Sep 08 2020 at 18:14):for example, you could submit a one-sentence doc/docbook/system/man3/libicv.xml file (with corresponding CMakeLists.txt edit to either ignore it or compile it) -- that'd be one patch that's unequivocally forward progress even if it's not practically useful yet.
Sean (Sep 08 2020 at 18:14):then could submit a second patch that fills in the doc with more detail. that would pass as well and satisfy commit criteria.
Sean (Sep 08 2020 at 18:15):again, assuming no other mistakes are made (e.g., if it doesn't compile, then it wouldn't count as pristine)
Sumagna Das (Sep 08 2020 at 18:16):ooh
Sumagna Das (Sep 08 2020 at 18:21):i dont know much about xml
Sean (Sep 08 2020 at 18:21):do you know the gist of html?
Sean (Sep 08 2020 at 18:21):how tags work
Sumagna Das (Sep 08 2020 at 18:21):i know html
Sumagna Das (Sep 08 2020 at 18:21):yea
Sean (Sep 08 2020 at 18:22):then you know xml
Sumagna Das (Sep 08 2020 at 18:22):the tags are different in xml, right?
Sean (Sep 08 2020 at 18:22):just different tag names are used, but the structure is one in the same
Sumagna Das (Sep 08 2020 at 18:22):ooh
Sean (Sep 08 2020 at 18:23):so in the case of libicv, look at one of the others like doc/docbook/system/man3/libfb.xml
Sumagna Das (Sep 08 2020 at 18:23):if they were the same, then that would have been easier
Sumagna Das (Sep 08 2020 at 18:23):i was looking at librt.xml
Sean (Sep 08 2020 at 18:23):you really only need to know about a couple tags
Sumagna Das (Sep 08 2020 at 18:24):let me get acquainted with some of the basic xml tags
Sean (Sep 08 2020 at 18:24):I mean, outside of some boilerplate stuff at the beginning and end, you could get away with just one <para></para>
Sumagna Das (Sep 08 2020 at 18:24):then
Sean (Sep 08 2020 at 18:24):which is same as <p></p> in html
Sumagna Das (Sep 08 2020 at 18:24):ooh
Sean (Sep 08 2020 at 18:25):and if you put it into the CMakeLists.txt file and run make, the xml will get compiled and it'll tell you if there's a syntax error
Sumagna Das (Sep 08 2020 at 18:25):let me try making one
Sean (Sep 08 2020 at 18:26):run "brlman librt" in a terminal (or "man librt" in mged) to see that librt.xml file rendered
Sumagna Das (Sep 08 2020 at 19:33):hey Sean i am getting these issues while making libicv.xml file
Sumagna Das (Sep 08 2020 at 19:33):Screenshot-from-2020-09-09-00-50-16.png
Sumagna Das (Sep 08 2020 at 19:34): Sumagna Das (Sep 08 2020 at 19:34):this is the file :up:
Sean (Sep 08 2020 at 19:34):yeah, so it looks like you missed a little bit of that boilerplate that I mentioned
Sumagna Das (Sep 08 2020 at 19:34):see the file and tell me what i missed
Sean (Sep 08 2020 at 19:35):Well it's right there in the error message.
Sean (Sep 08 2020 at 19:36):it says you have a refentry, but that tag requires either a refsection or refsect1 tag inside it
Sumagna Das (Sep 08 2020 at 19:36):ok
Sean (Sep 08 2020 at 19:37):search the other examples for refsection or refsect1 and you'll see what's missing.
Sumagna Das (Sep 08 2020 at 19:38):fixed it
Sean (Sep 08 2020 at 19:38):easy peasy ;)
Sumagna Das (Sep 08 2020 at 19:59):the libicv thing is working
Sumagna Das (Sep 08 2020 at 19:59):next?
Sumagna Das (Sep 08 2020 at 20:13):@Sean what should i do now?
starseeker (Sep 08 2020 at 20:48):So your gcv plugin is now working?
Sumagna Das (Sep 08 2020 at 21:11):Not the GCV plugin but the document thing which Sean was talking about
starseeker (Sep 08 2020 at 21:11):ah
Sean (Sep 09 2020 at 02:24):@Sumagna Das submit it as a patch if it's compiling cleanly now, use https://sourceforge.net/p/brlcad/patches/
Sean (Sep 09 2020 at 02:24):make sure your svn is up-to-date before running svn diff so that it applies cleanly
Sean (Sep 09 2020 at 02:25):always a good idea to take a look at the patch file to make sure it only includes the changes you intended
Sean (Sep 09 2020 at 02:25):if you have that libicv manual page compiling, that'd be great to submit as a patch too
Sumagna Das (Sep 09 2020 at 05:33):I have the manual page compiling actually
Sumagna Das (Sep 09 2020 at 09:46):Hey @Sean I submitted the patch
Sumagna Das (Sep 09 2020 at 09:46):Don't know if I did that correctly or not
Sean (Sep 09 2020 at 13:15):Awesome @Sumagna Das, taking a look now
Sean (Sep 09 2020 at 13:24):@Sumagna Das that was a perfect patch. BRL-CAD now has a libicv manual page stub because of you. thank you!
Sean (Sep 09 2020 at 13:27):now if you svn up, you should see it in your tree, possibly with an M for merged. and from there, you can fill out the page with more details, submit that svn diff as a separate patch. Feel free to put in there whatever documentation you feel would be useful to you or others. Can continue to use the other manual pages as a reference, or do your own thing. There's a nice overview of Docbook here: https://opensource.com/article/17/9/docbook
Thusal Ranawaka (Sep 09 2020 at 13:29):Congrats and Thank you!! @Sumagna Das
Sumagna Das (Sep 09 2020 at 13:34):Thanks for letting me know that :smiling_face:️
Sumagna Das (Sep 09 2020 at 18:36):i should start with calling icv_read, shouldnt i?
Sumagna Das (Sep 09 2020 at 18:41):Or should I start with something else?
Sean (Sep 09 2020 at 18:44):For the manual?
Sean (Sep 09 2020 at 18:44):or for the plugin?
Sumagna Das (Sep 09 2020 at 18:44):plugin
Sean (Sep 09 2020 at 18:45):You're on Windows right?
Sumagna Das (Sep 09 2020 at 18:45):linux(precisely ubuntu)
Sean (Sep 09 2020 at 18:46):Oh, great. Then I would recommend creating a simple stand-alone test.c
Sumagna Das (Sep 09 2020 at 18:46):where?
Sean (Sep 09 2020 at 18:46):anywhere, this is just so you can create a little test program that demonstrates you're calling things correctly
Sumagna Das (Sep 09 2020 at 18:47):hmm
Sean (Sep 09 2020 at 18:47):it's not something that'd go into the repo, it's just for you
Sumagna Das (Sep 09 2020 at 18:47):i was just asking where i can add them
Sean (Sep 09 2020 at 18:47):I know
Sean (Sep 09 2020 at 18:48):I'm saying it doesn't matter at all because this is a test program for you to compile by hand
Sean (Sep 09 2020 at 18:48):int main(int ac, char *av[]) { ...; return 0;} gcc test.c ; ./a.out
Sumagna Das (Sep 09 2020 at 18:49):hmm
Sean (Sep 09 2020 at 18:49):put an icv_init in there for starters
Sean (Sep 09 2020 at 18:49):and then compil it
Sumagna Das (Sep 09 2020 at 18:49):then include the libraries which i want
Sean (Sep 09 2020 at 18:49):right, that all just goes on the gcc call
Sean (Sep 09 2020 at 18:51):so it'll be something like: gcc -Ipath/to/build/include -Ipath/to/src/include test.c -Lpath/to/build/lib -Wl,-rpath=path/to/build/lib -licv -lbu
Sean (Sep 09 2020 at 18:51):can walk you through it
Sumagna Das (Sep 09 2020 at 18:52):not tonight
Sumagna Das (Sep 09 2020 at 18:52):very tired today
Sean (Sep 09 2020 at 18:52):what time is it?
Sean (Sep 09 2020 at 18:52):this should take 5 min tops :)
Sumagna Das (Sep 09 2020 at 18:52):12 22 am
Sumagna Das (Sep 09 2020 at 18:54):Sean said:
this should take 5 min tops :smile:
i also have school tomorrow onwards so my parents are telling me to sleep early
Sean (Sep 09 2020 at 18:54): Sumagna Das (Sep 09 2020 at 18:54):Sean said:
thanks for that
Sean (Sep 09 2020 at 18:55):agua:~ morrison$ gcc -Ibrlcad.trunk/.build/include -Ibrlcad.trunk/include test.c -Lbrlcad.trunk/.build/lib -Wl,-rpath -Wl,brlcad.trunk/.build/lib -lbu
agua:~ morrison$ ./a.out
hello world
Here's an update with a few quick icv calls, still does nothing: test.c
Sean (Sep 09 2020 at 18:59):agua:~ morrison$ gcc -Ibrlcad.trunk/.build/include -Ibrlcad.trunk/include test.c -Lbrlcad.trunk/.build/lib -Wl,-rpath -Wl,brlcad.trunk/.build/lib -licv -lbu
had to add -licv
Sean (Sep 09 2020 at 19:01):With something like that, you can test opening a png image -- maybe print the image's dimensions using ICV (tomorrow of course)
Sumagna Das (Sep 10 2020 at 02:53):Sean said:
With something like that, you can test opening a png image -- maybe print the image's dimensions using ICV (tomorrow of course)
might do that. i saw a function which did that actually.
Sumagna Das (Sep 10 2020 at 03:20):what should bu_mime_image_t be for png in icv_image_size()?
Sean (Sep 10 2020 at 03:32):try auto
Sumagna Das (Sep 10 2020 at 03:33):ok
Sean (Sep 10 2020 at 03:33):have you looked at the list of mime types?
Sumagna Das (Sep 10 2020 at 03:33):i had seen some of them
Sean (Sep 10 2020 at 03:33):they're in yourbuilddir/include/bu/mime_types.h
Sean (Sep 10 2020 at 03:34):generated during compilation
Sumagna Das (Sep 10 2020 at 03:34):wait
Sumagna Das (Sep 10 2020 at 03:35):saw that
Sumagna Das (Sep 10 2020 at 03:35):and thats a lot of them
Sumagna Das (Sep 10 2020 at 03:37):but its outputting them wrongly
Sean (Sep 10 2020 at 03:37):it's auto-generated off of the official list from IANA -- can see them in misc/mime.types
Sumagna Das (Sep 10 2020 at 03:37):i mean the width and height
Sumagna Das (Sep 10 2020 at 03:38):i saw that one
Sean (Sep 10 2020 at 03:40):@starseeker so an issue you might be able to help sort out... ran into a problem creating an image-to-geometry plugin for libgcv that hadn't been fully considered when the mime stuff was put in place. gcv's interface technically only handles "bu_mime_model" types or "unknown"/"auto". that type/grouping limitation is technically wrong, and is compounded considering one might want to create geometry off of other types (e.g., excel spreadsheet or something).
Sean (Sep 10 2020 at 03:41):@Sumagna Das it's outputting the wrong width/height?
Sean (Sep 10 2020 at 03:41):what's the code?
Sumagna Das (Sep 10 2020 at 03:41):let me check it
Sumagna Das (Sep 10 2020 at 03:47): Sumagna Das (Sep 10 2020 at 03:47):this is the file
Sean (Sep 10 2020 at 03:51):ahh, I see what's going on
Sean (Sep 10 2020 at 03:52):icv_image_size() has no awareness of PNG files, only of PIX and BW files
Sumagna Das (Sep 10 2020 at 03:52):ohh
Sean (Sep 10 2020 at 03:52):so it's entirely trying to guess the size based on the file
Sean (Sep 10 2020 at 03:52):based on the number of bytes in the file
Sean (Sep 10 2020 at 03:52):which is of course wildly wrong for png
Sean (Sep 10 2020 at 03:54):if the function were written to take an icv_image_t it would have worked
Sean (Sep 10 2020 at 03:54):but it was merely a code migration of some other tool into the codebase
Sean (Sep 10 2020 at 03:54):i.e., bad luck on a routine to pick
Sean (Sep 10 2020 at 03:56):oooooh, I see -- you fed av[1] but it doesn't even read the file
Sumagna Das (Sep 10 2020 at 03:56):thats why it is wrong?
Sean (Sep 10 2020 at 03:56):the input parameters are data -- so that size value is wrong
Sumagna Das (Sep 10 2020 at 03:57):because i fed it directly instead of opening it
Sean (Sep 10 2020 at 03:57):you didn't feed anything other than an unrelated number
Sumagna Das (Sep 10 2020 at 03:59):int icv_image_size ( const char * name,
size_t dpi,
size_t file_size,
bu_mime_image_t type,
size_t * widthp,
size_t * heightp
)
yeah, it looks like the intention is to call icv_read which will store the number of pixels read in the height parameter
Sumagna Das (Sep 10 2020 at 03:59):according to doxygen it should taking be taking a name
Sumagna Das (Sep 10 2020 at 03:59):so i passed the file name
Sean (Sep 10 2020 at 03:59):you could then pass the number from icv_read to icv_image_size and it'll guess
Sean (Sep 10 2020 at 04:00):yes a name -- but it doesn't say that's a filename
Sean (Sep 10 2020 at 04:00):it's just a label
Sumagna Das (Sep 10 2020 at 04:00):hmm
Sean (Sep 10 2020 at 04:00):"String identifying a particular size"
Sean (Sep 10 2020 at 04:00):it's just a label, presumably for debug printing
Sumagna Das (Sep 10 2020 at 04:01):thats why variable name shouldnt be taken very seriously
Sean (Sep 10 2020 at 04:01):yeah, it should be more clear
Sean (Sep 10 2020 at 04:01):/me changes it to "label"
Sean (Sep 10 2020 at 04:04):oh I see... it actually recognizes official dimension names and uses it as a hint for determining the image size
Sumagna Das (Sep 10 2020 at 04:04):where?
Sean (Sep 10 2020 at 04:05):For example, if you made the name "8K_FUHD", it would know the image "should" be 7680x4320
Sumagna Das (Sep 10 2020 at 04:05):ooh
Sean (Sep 10 2020 at 04:05):and it'll report 0 or 1 if the datasize fits
Sean (Sep 10 2020 at 04:06):"VGA" implies 640x480, etc
Sean (Sep 10 2020 at 04:06):whole list of them in src/libicv/size.c
Sumagna Das (Sep 10 2020 at 04:06):the photo i was giving it was 1080x1080
Sumagna Das (Sep 10 2020 at 04:07):one of my renders from blenders( i dont have many pictures lying around)
Sean (Sep 10 2020 at 04:07):handles paper sizes too, so you could say the image is A4 and it'll figure out the appropriate width/height pixel ratio given the number of pixels in the image
Sean (Sep 10 2020 at 04:08):that's a bit of a complicated construct to document... I get why the person that migrated it from a utility to libicv didn't bother to put anything in the doxygen
Sumagna Das (Sep 10 2020 at 04:08)::grinning_face_with_smiling_eyes:
Sean (Sep 10 2020 at 04:08):it is/was probably documented in a manual page for some other tool
Sean (Sep 10 2020 at 04:09):both icv and gcv started as hundreds of independent utilities like png-pix and pix-bw and bwthresh and hundreds of others
Sean (Sep 10 2020 at 04:10):instead of hundreds, we started migrating towards a single geometry and single image conversion binary using plugins instead for each of the input/output/filter operation one typically wants to perform
Sean (Sep 10 2020 at 04:10):obviously not a polished interface
Sean (Sep 10 2020 at 04:13):but that's how these things get created, incremental progress. we still have more conversion capability than any other open source CAD software that I'm aware of... GCV has incredible potential
Sean (Sep 10 2020 at 04:14):icv and gcv should probably / eventually merge into just "cv" so you can convert any 2D into 2D, 2D into 3D, 3D into 3D, and 3D into 2D.
Sean (Sep 10 2020 at 04:21):updated the doxygen to hopefully clarify -- @Sumagna Das would you svn up and see if it makes enough sense (see include/icv/io.h)
Sumagna Das (Sep 10 2020 at 04:23):i used libpng to get the width and height from just the image
Sumagna Das (Sep 10 2020 at 04:24):it worked
Sumagna Das (Sep 10 2020 at 04:27):here's the file after using libpng test.c
Sumagna Das (Sep 10 2020 at 04:28):what do you think?
Sean (Sep 10 2020 at 04:29):well, I think you're wanting to call libpng or you wouldn't have tried that :)
Sumagna Das (Sep 10 2020 at 04:30):i saw one of the files in src/util using libpng so i also wanted to try it alongside trying libicv
Sean (Sep 10 2020 at 04:32):yes, like I said -- we had/have lots of utilities that do all sorts of image and geometry editing operations stand-alone. developed in a unix style, chainable, extensive. you'll find a dozen or so image formats buried in there including png.
Sean (Sep 10 2020 at 04:33):do whatever you want to do for this plugin -- I have no doubt you can get png or icv to work
Sean (Sep 10 2020 at 04:33):icv will mean you could automatically support any icv image type including png, pix, bw, ppm, etc .. and turn them into a VOL
Sumagna Das (Sep 10 2020 at 04:34):i can use libpng for some parts where lbicv cant work
Sean (Sep 10 2020 at 04:34):if you make it png specific, the code will undoubtedly be a little easier to implement because libpng is very well documented, but will obviously be limited to some subset of the PNG format
Sumagna Das (Sep 10 2020 at 04:35):can extend it later
Sean (Sep 10 2020 at 04:35):Sumagna Das said:
i can use libpng for some parts where lbicv cant work
you don't need or want to use both... if you rely on libpng, then the input must be png.
Sumagna Das (Sep 10 2020 at 04:35):for now, it should at least work for png
Sumagna Das (Sep 10 2020 at 04:35):Sean said:
Sumagna Das said:
i can use libpng for some parts where lbicv cant work
you don't need or want to use both... if you rely on libpng, then the input must be png.
hm
Sumagna Das (Sep 10 2020 at 04:43):hey @Sean the file right now is standing here test.c
Sumagna Das (Sep 10 2020 at 04:44):after compiling when i try to run it, it shows this
bu_malloc: Insufficient memory available
bu_malloc: malloc failure
bu_malloc: malloc failure
Saving stack trace to test-26241-bomb.log
bu_semaphore_free(): pthread_mutex_destroy() failed on [6] of [10]
by the way, I added img = icv_read(av[1], BU_MIME_IMAGE_PNG, 0, 0); to your test.c and it correctly recorded the width and height
Sumagna Das (Sep 10 2020 at 04:45):0, 0 works for the last two arguments
Sumagna Das (Sep 10 2020 at 04:46):?
Sean (Sep 10 2020 at 04:47):for reading, yes -- docs say that's just a hint if the input is a raw image stream
Sumagna Das (Sep 10 2020 at 04:47):Oh then its fine
Sumagna Das (Sep 10 2020 at 04:49):but its doesnt give correct info in its width and height variable, does it?
Sean (Sep 10 2020 at 04:50):that way at least, you can go through icv instead of png, but make the plugin still require png for now until libicv improves
Sean (Sep 10 2020 at 04:51):Sumagna Das said:
but its doesnt give correct info in its width and height variable, does it?
it worked correctly for me on a 1280x720 image
Sumagna Das (Sep 10 2020 at 04:51):i am using a 1080x108 as i said earlier
Sumagna Das (Sep 10 2020 at 04:53):and i am getting
width:357920, height:1
from
bu_log("width:%d, height:%d\n", img->width, img->height);
what's your icv_read() line?
Sean (Sep 10 2020 at 04:53):it does that on AUTO
Sumagna Das (Sep 10 2020 at 04:54):it is using AUTO
Sean (Sep 10 2020 at 04:54):I think the file is getting parsed by a different plugin
Sean (Sep 10 2020 at 04:54):yeah, use BU_MIME_IMAGE_PNG instead
Sumagna Das (Sep 10 2020 at 04:54):worked perfectly
Sean (Sep 10 2020 at 04:55):like I said, that makes the plugin limited to PNG just as if you were using libpng, but it will be easy to convert that to AUTO later as AUTO gets improved
Sean (Sep 10 2020 at 04:55):there are a bunch of plugins that say they're read anything and I think it just picks the first one
Sean (Sep 10 2020 at 04:56):whereas here it should obviously prefer png because of the filename and file contents
Sumagna Das (Sep 10 2020 at 04:56):hmm
Sean (Sep 10 2020 at 04:59):next, you'll want to call icv_rgb2gray(img, color, rweight, gweight, bweight);
Sumagna Das (Sep 10 2020 at 05:02):should i assign the last 3 arguments 0?
Sean (Sep 10 2020 at 05:02):yeah, that's right
Sean (Sep 10 2020 at 05:03):if you were writing out a png or something, you might want to assign perceptive weights, but not for something like this where the values are intentional
Sean (Sep 10 2020 at 05:03):last call should be icv_data2uchar(img); to get the image buffer in unsigned char format (i.e., bw/vol data)
Sumagna Das (Sep 10 2020 at 05:10):i will try it after a few minutes
Sumagna Das (Sep 10 2020 at 05:29): Sumagna Das (Sep 10 2020 at 05:29):after converting it to gray, then uchar, then wrote it into this file
Sean (Sep 10 2020 at 05:32):either you have a dimension not specified somewhere, or there's a bug somewhere in what you ran
Sumagna Das (Sep 10 2020 at 05:32): Sumagna Das (Sep 10 2020 at 05:33):this is the file
Sean (Sep 10 2020 at 05:33):Screen-Shot-2020-09-10-at-1.33.03-AM.png
Sean (Sep 10 2020 at 05:33):image is 1080x530 for some reason
Sumagna Das (Sep 10 2020 at 05:33):ooh
Sumagna Das (Sep 10 2020 at 05:33):dont know
Sumagna Das (Sep 10 2020 at 05:34):
Sumagna Das (Sep 10 2020 at 05:34):this is the real png
Sean (Sep 10 2020 at 05:34):oh, fprintf(fp, "%s", vol_data);
that's wrong
Sumagna Das (Sep 10 2020 at 05:35):i couldnt think of any other way so i used that
Sean (Sep 10 2020 at 05:35):basically mean it's going to stop wherever it encounters a particular byte
Sean (Sep 10 2020 at 05:35):icv_write() :)
Sean (Sep 10 2020 at 05:35):for your plugin, you don't need to write it out
Sean (Sep 10 2020 at 05:35):but for testing, it's useful to verify what you did
Sumagna Das (Sep 10 2020 at 05:36):iwanted to test it out so i wanted to write it out
Sumagna Das (Sep 10 2020 at 05:36):any other way
Sean (Sep 10 2020 at 05:36):fprintf() is going to stop on the first '\0' byte or '\n' newline byte.. which is trivial to encounter in image data
Sean (Sep 10 2020 at 05:36):that's just a black and near-black pixel
Sean (Sep 10 2020 at 05:37):to write it out manually using stdio, the system call would typically be fwrite() or write().
Sean (Sep 10 2020 at 05:37):but icv_write() is going to be simplet
Sean (Sep 10 2020 at 05:38):it's just icv_write(img, out_file, BU_MIME_IMAGE_BW);
Sumagna Das (Sep 10 2020 at 05:54):used that
Sumagna Das (Sep 10 2020 at 05:58):How did you render the file in mged?
Sean (Sep 10 2020 at 05:59):bw-fb -w1080 -n530 ~/Downloads/random.bw
Sean (Sep 10 2020 at 05:59):bw is raw data, so can just divide file size by 1080 to discover it stopped after 530 lines
Sumagna Das (Sep 10 2020 at 06:01):Ooh
Sumagna Das (Sep 10 2020 at 06:16): Sumagna Das (Sep 10 2020 at 06:16):this time it worked perfectly
Sumagna Das (Sep 10 2020 at 06:18):see what it outputs
Sumagna Das (Sep 10 2020 at 06:19):i cant use that command because it took up the remaining part of my ram as zoom took a lot of ram
Sean (Sep 10 2020 at 07:10):o.O
Sumagna Das (Sep 10 2020 at 15:56):
Sumagna Das (Sep 10 2020 at 15:56):can anyone tell me why this window was translucent
starseeker (Sep 10 2020 at 16:23):If you're using a modern desktop on Linux, up until very recent trunk builds the windows being created for opengl rt outputs were translucent
Sumagna Das (Sep 10 2020 at 16:23):i am using ubuntu and the most recent build (probably r77092)
Sumagna Das (Sep 10 2020 at 16:27):did until the data2uchar conversion but what should be done next
Sumagna Das (Sep 10 2020 at 16:28):make a vol with that data?
Sumagna Das (Sep 10 2020 at 16:28):but whom to pass that data for making a vol?
Sumagna Das (Sep 10 2020 at 17:47):@Sean what next
Sumagna Das (Sep 10 2020 at 19:12): Sumagna Das (Sep 10 2020 at 19:12):this is the test.c file after cleaning it up
Sean (Sep 11 2020 at 03:29):@Sumagna Das great! so yeah, now you successfully read a png, created a bw, so last step would be to make a vol (see mk_vol)
Sumagna Das (Sep 11 2020 at 03:29):but mk_vol needs a bw file
Sean (Sep 11 2020 at 03:30):that should be super easy, so then the next task is to turn this demo into gcv plugin
Sean (Sep 11 2020 at 03:34):vol primitives require an external data file still -- ebm and dsp will read directly from an object, but not yet vol
Sean (Sep 11 2020 at 03:39):extending vol to read from db objects would be an easy patch for someon
Sean (Sep 11 2020 at 03:42):I think ebm was extended in a day
Sumagna Das (Sep 11 2020 at 04:43):ooh
Sumagna Das (Sep 11 2020 at 05:07):Sean said:
extending vol to read from db objects would be an easy patch for someon
i would have done that but i dont get the laptop for more than an hour after the online classes so cant do it
Sumagna Das (Sep 11 2020 at 17:46):@Sean what next?
Sumagna Das (Sep 11 2020 at 18:06):Sumagna Das said:
Sean said:
extending vol to read from db objects would be an easy patch for someon
i would have done that but i dont get the laptop for more than an hour after the online classes so cant do it
can you guide me throught this Sean? i am sitting with the laptop doing nothing anyways
Sean (Sep 11 2020 at 18:32):@Sumagna Das there's a patch on sourceforge recently that added in-database support for EBM objects -- you could start by reading that patch
Sean (Sep 11 2020 at 18:32):the code for VOL will be very similar and in some places identical
Sumagna Das (Sep 11 2020 at 18:32):i will see to that then
Sean (Sep 11 2020 at 18:34):you can see what this support currently looks like too in the EBM and DSP codes (include/rt/geom.h and src/librt/primitives/ebm and src/librt/primitives/dsp)
Sumagna Das (Sep 11 2020 at 18:34):is it patch no 539?
Sean (Sep 11 2020 at 19:12):that sounds right
Sumagna Das (Sep 12 2020 at 10:57):I downloaded the patch on my laptop and will see to that tonight
Sumagna Das (Sep 12 2020 at 11:02):I downloaded the patch on my laptop and will see to that tonight
Sumagna Das (Sep 12 2020 at 20:27):Sean said:
the code for VOL will be very similar and in some places identical
which files do i have to change at most?
Sumagna Das (Sep 12 2020 at 20:34):trying to make it work looking at the ebm patch
Sumagna Das (Sep 12 2020 at 21:56):cant do it right now
Sumagna Das (Sep 12 2020 at 21:56):one change results in a cascade of failures
Sumagna Das (Sep 12 2020 at 21:57):so you might wanna do it
Sumagna Das (Sep 12 2020 at 21:58):i cant work on it for much time this week so can you please do it
Sumagna Das (Sep 12 2020 at 21:59):if i dont complete a thing by one day, i might forget it by the next day so..
Sumagna Das (Sep 13 2020 at 18:45):so my temporary workaround for a problem in the atom package for cmake building in atom somehow doesnt work for some reason right now
Sumagna Das (Sep 13 2020 at 18:46):so it might take days to fix it
Sumagna Das (Sep 13 2020 at 18:46):if anyone can help me with regex, then it might be fixed sooner
Sumagna Das (Sep 13 2020 at 18:46):it was a regex related problem
Sumagna Das (Sep 13 2020 at 18:52):/\*?\s+(\S.*)\s+=\s+Generates?\s(\S.+\.)(\s+Optional\s\[arch\]\scan\sbe\s("\S.*")\.)?/g
was a regex which extracted the cmake generator from the first line. (atleast thats what i needed)
Sumagna Das (Sep 13 2020 at 18:53):it gave the file which runs the cmake command Unix Makefiles before but now it gives * Unix Makefiles
Sumagna Das (Sep 13 2020 at 18:54):this asterisk is causing problems
Sumagna Das (Sep 13 2020 at 18:55):can anyone fix this regex so as not to include the asterisk?
starseeker (Sep 13 2020 at 20:56):What problem are you working around?
Sumagna Das (Sep 14 2020 at 03:02):the regex was not fixed to get the generator when i installed the package so i had to manually change the regex to fix it
Sumagna Das (Sep 14 2020 at 03:02):Sumagna Das said:
it gave the file which runs the cmake command
Unix Makefilesbefore but now it gives* Unix Makefiles
now this regex is yielding this error
Sumagna Das (Sep 14 2020 at 03:03):the asterisk is also included from the line in help message of cmake
Sumagna Das (Sep 14 2020 at 03:10):Sumagna Das said:
the regex was not fixed to get the generator when i installed the package so i had to manually change the regex to fix it
the atom package i installed for cmake building insiide of atom
Sumagna Das (Sep 14 2020 at 17:47):hey @Sean i just added a function for the vol data checking which temporarily prints the file name and the .g file in mged right now
Sumagna Das (Sep 14 2020 at 18:01):i was checking the mk_ebm function
Sumagna Das (Sep 14 2020 at 18:03):how to pass the data object to ebm?
Sumagna Das (Sep 14 2020 at 18:23):is vol_from_file the function for extracting vol data from bw file?
Sean (Sep 14 2020 at 20:15):Sumagna Das said:
/\*?\s+(\S.*)\s+=\s+Generates?\s(\S.+\.)(\s+Optional\s\[arch\]\scan\sbe\s("\S.*")\.)?/gwas a regex which extracted the cmake generator from the first line. (atleast thats what i needed)
I'm not understanding what you're doing or where this regex is coming from. It's not anything in BRL-CAD as far as I can tell. Is that maybe some regex in Atom? in CMake? in something else??
Sean (Sep 14 2020 at 20:22):Sumagna Das said:
it gave the file which runs the cmake command
Unix Makefilesbefore but now it gives* Unix Makefiles
Also "Unix Makefiles" is not a cmake command, so i'm not sure what you're saying here too. That regular expression doesn't match either of those two.
Sumagna Das (Sep 14 2020 at 20:26):That is fixed
Sumagna Das (Sep 14 2020 at 20:26):It was not related to BRL-CAD
Sean (Sep 14 2020 at 20:27):okay
Sumagna Das (Sep 14 2020 at 20:27):I was just asking for help
Sumagna Das (Sep 14 2020 at 20:27):It was regex meant to extract the generator
Sean (Sep 14 2020 at 20:27):no problem, I just didn't understand the context
Sumagna Das (Sep 14 2020 at 20:27):From cmake
Sean (Sep 14 2020 at 20:27):sure, but a regex FROM WHAT? :)
Sean (Sep 14 2020 at 20:27):you haven't provided context
Sean (Sep 14 2020 at 20:27):from you?
Sumagna Das (Sep 14 2020 at 20:28):From an atom package
Sumagna Das (Sep 14 2020 at 20:29):Sorry for not providing enough info :sweat:
Sean (Sep 14 2020 at 20:29):part of atom, or some atom plugin -- how'd you find this regex?
Sumagna Das (Sep 14 2020 at 20:30):It was in the package I installed while converting atom to a somewhat ide
Sumagna Das (Sep 14 2020 at 20:30):It gives me cmake build options in atom
Sean (Sep 14 2020 at 20:33):AHhhhhhhhhhhhhh......
Sean (Sep 14 2020 at 20:33):now that's context
Sean (Sep 14 2020 at 20:34):So it was probably hard-wired to a specific version of cmake and either needed an update or just had a bug. got it.
Sumagna Das (Sep 14 2020 at 20:35):Its a bug actually and the creator hasn't even seen to issue created on it
Sumagna Das (Sep 14 2020 at 20:35):On GitHub
Sean (Sep 14 2020 at 20:52):/me nods
Sumagna Das (Oct 25 2020 at 21:34):@Sean somewhat done on this. i readied the idea of the gcv plugin implementation.
here's the test.c file i was making before the "in-db support for vol" patch work
test.c
Sumagna Das (Oct 25 2020 at 21:34):the png files are same.
Sumagna Das (Oct 25 2020 at 21:34):i didnt change them but will try with new pictures later.
Sumagna Das (Oct 25 2020 at 21:35):here are the png files if you dont have them
front.png
middle.png
back.png
Sumagna Das (Oct 25 2020 at 21:35):see if it works on your end.
Sumagna Das (Oct 25 2020 at 21:40):the file does the work that the gcv plugin will do probably.
1) read png file(s)
2a) convert them to bw data(inside the program)
2b) (if there is more than one png file) concatenate the bw data of all the files into one variable.
3a) make a binunif(?)
3b) make a vol using the in-db object(binunif)
Sumagna Das (Oct 25 2020 at 21:46):A much more organized test.c
Sumagna Das (Oct 26 2020 at 15:41):Updated the test.c
Now it gets the files as command-line arguments.
Sumagna Das (Oct 26 2020 at 15:42):@Sean Can you check if this is what is going to be implemented in the GCV plugin?
Sean (Oct 26 2020 at 18:29):definitely, will look at this and test it out tonight
Sumagna Das (Oct 26 2020 at 18:41):BTW, the code needs the "in-db support for vol" patch to be applied.
Sean (Oct 26 2020 at 18:52):yep, got it
Sumagna Das (Oct 27 2020 at 20:38):Cleaned up the code a little bit. test.c
Sumagna Das (Oct 30 2020 at 06:22):@Sean does it work as expected?
Sumagna Das (Nov 07 2020 at 18:05):with in-database support for vol primitive, this will be much more easier now.
Sumagna Das (Nov 07 2020 at 20:10):@Sean Something i want to ask, Can we pass multiple files to gcv?
Sean (Nov 10 2020 at 15:05):I agree @Sumagna Das ! much easier. Now that all the major object types support in-database, the next priority will probably be creating "image" objects and allowing VOL, DSP, EBM, etc refer to those in addition to binunif objects for their data. So one could, for example, directly import a png as an object and refer to it for its data.
Sean (Nov 10 2020 at 15:07):Sumagna Das said:
Sean Something i want to ask, Can we pass multiple files to
gcv?
Depends what you mean by that, but probably "yes and no". gcv does have a concept of an "input" and an "output" and it probably would be easy to make either of those be a directory. it's also possible to introduce some sort of list syntax so that input could be a list of input files.
Sean (Nov 10 2020 at 15:08):It's undoubtedly very simple right now, probably mostly assumes inputfile outputfile.
Sumagna Das (Nov 10 2020 at 15:15):Sean said:
I agree Sumagna Das ! much easier. Now that all the major object types support in-database, the next priority will probably be creating "image" objects and allowing VOL, DSP, EBM, etc refer to those in addition to binunif objects for their data. So one could, for example, directly import a png as an object and refer to it for its data.
that is a great idea. We can directly import the PNG files now.
Sean (Nov 10 2020 at 15:16):what do you mean?
Sean (Nov 10 2020 at 15:16):you mean with gcv right?
Sumagna Das (Nov 10 2020 at 15:17):Sean said:
you mean with gcv right?
yea...but i have encountered only one problem until now.
Sumagna Das (Nov 10 2020 at 15:18):gcv takes in only one inputfile but that only works for EBM. To make it work for VOL either I have to pass in a directory or think of another way.
Sean (Nov 10 2020 at 15:21):yeah, I think GCV needs to be modified to handle this
Sean (Nov 10 2020 at 15:23):list syntax and/or a directory plugin that auto-converts a directory into a list
Sean (Nov 10 2020 at 15:25):gcv could also just be made aware internally when there's a clear pattern in the argv list
Sean (Nov 10 2020 at 15:28):for example, I think the intent is clear with: gcv input.stl output.g
but it's also clear with: gcv *.stl output.g (which to gcv will be an argv[] that looks like ["file1.stl", "file2.stl", "file3.stl", "output.g"])
Sumagna Das (Nov 10 2020 at 16:28):Sean said:
list syntax and/or a directory plugin that auto-converts a directory into a list
I will modify as per this only for the plugin because changing this can create problems in the other plugins.
Sumagna Das (Nov 10 2020 at 17:52):last thing i want to ask. in which function are the command-line arguments from the gcv command passed or processed
Daniel Rossberg (Nov 10 2020 at 18:29):They are processed in bu_opt_parse(), but you are probably more interested in the options array. The column with the (void *)& gives you the variables where the arguments are written to.
Sumagna Das (Nov 10 2020 at 18:30):yea, i needed the variable actually
Sumagna Das (Nov 10 2020 at 19:02):sumagnadas@hp-laptop:/mnt/sda2/github/brlcad/build$ bin/gcv -i ./share/tclscripts/mged/mike-tux.png -o mike_tux.g
Input file format: BU_MIME_MODEL_UNKNOWN
Output file format: BU_MIME_MODEL_VND_BRLCAD_PLUS_BINARY
Input file path: ./share/tclscripts/mged/mike-tux.png
Output file path: mike_tux.g
No filter for BU_MIME_MODEL_UNKNOWN
Conversion failed
@Sean getting this when trying to run gcv. It doesnt identify PNG
Sean (Nov 10 2020 at 20:29):that's because another plugin is claiming it
Sean (Nov 10 2020 at 20:30):iirc, I remember seeing the gdal plugin claiming it, so you might want to disable that one temporarily
Sean (Nov 10 2020 at 20:30):i'll take a look here in a little bit
Sumagna Das (Nov 11 2020 at 05:40):how to disable a certain plugin? do i remove it from the cmakefiles.txt?
Sumagna Das (Nov 11 2020 at 19:21):@Sean i commented everything in src/libgcv/plugins/gdal/CMakeLists.txt but still it gives the same error.
Sumagna Das (Nov 11 2020 at 19:47):i was tryng to use the --input-format=png but it isnt taking it either. BUt when i use --input-format=stl, it is getting the input format as BU_MIME_MODEL_STL. this input-format issue is also happening with other image formats. I tested it with --input-format=jpeg and --input-format=bw and it identifies both of them as BU_MIME_MODEL_UNKNOWN
Sean (Nov 13 2020 at 12:48):@Sumagna Das it's going to pull plugins dynamically (that have already been compiled) from the build dir plugins directory
Sean (Nov 13 2020 at 12:50):OH! I forgot .. yes, there's an issue because it's specifically looking for geometry mime types and doesn't know about image types...
Sorry about that. That's a deeper issue in how mime types were set up. We have to change them so that it iterates over all possible types, not just geometry.
Sumagna Das (Nov 13 2020 at 16:39):Sean said:
OH! I forgot .. yes, there's an issue because it's specifically looking for geometry mime types and doesn't know about image types...
Sorry about that. That's a deeper issue in how mime types were set up. We have to change them so that it iterates over all possible types, not just geometry.
the plugin was working perfectly before i guess......
i didnt change the plugin file.
Sumagna Das (Dec 24 2020 at 16:03):the plugin is working now and converting (only one) png file to a .g file.
Would've been better if gcv took more than one file as input....
Sumagna Das (Dec 24 2020 at 16:05):the only thing i dont know about is if the other parts of BRL-CAD works with the change in the "mime types" generating area.
Sean (Dec 26 2020 at 17:06):@Sumagna Das awesome! can you show it in action?
Sumagna Das (Dec 26 2020 at 18:05):Sean said:
Sumagna Das awesome! can you show it in action?
bin/gcv -i ./share/tclscripts/mged/mike-tux.png -o mike_tux.g yielded mike_tux.g
Sumagna Das (Dec 26 2020 at 18:10):in that file, test was the sphere which was being made before it worked.
Sumagna Das (Dec 26 2020 at 18:14):as for now, the plugin can take only one value because gcv doesnt support multiple files input
Sean (Dec 27 2020 at 06:03):Awesome!
Screen-Shot-2020-12-27-at-1.01.12-AM.png
Sean (Dec 27 2020 at 06:03):(I set low/hi values to something more narrow like 40/80)
Sean (Dec 27 2020 at 06:05):@Sumagna Das so that's awesome, I think the plugin is probably in good enough shape to commit if the changes weren't disruptive to other code -- at a minimum, should be good to commit the gcv changes.
Sean (Dec 27 2020 at 06:06):what do you think it'd take to make gcv take multiple files? thoughts on how to accomplish that best?
Sumagna Das (Dec 27 2020 at 06:43):will have to see to that
Sumagna Das (Dec 27 2020 at 06:45):but the thing is that some changes have been made to gcv.c for the mime types issue and if some changes are made to the file right now then it would be impossible to differentiate the "mime types" changes from the "multiple files" changes
Sumagna Das (Dec 27 2020 at 06:46):anything you can suggest for overcoming this issue?
Sean (Dec 27 2020 at 06:46):Hm
Sumagna Das (Dec 27 2020 at 06:46):Sean said:
Sumagna Das so that's awesome, I think the plugin is probably in good enough shape to commit if the changes weren't disruptive to other code -- at a minimum, should be good to commit the gcv changes.
i guess it isnt disruptive to other code but cant tell because i have no way to test it.
Sean (Dec 27 2020 at 06:47):You should be able to just make the gcv changes -- and the plugin just won't work. If it's a type that doesn't exist, just might have to #define it to commit then make the mime changes, then remove the define, something like that.
Sean (Dec 27 2020 at 06:47):It's disruptive if compilation fails. ;)
Sumagna Das (Dec 27 2020 at 06:48):Sean said:
It's disruptive if compilation fails. :wink:
that hasnt happened the last time i compiled
Sean (Dec 27 2020 at 06:49):Users of the mime types interface are rt, rtwizard, a few utilities like bw-pix and pix-bw, and the overlay command in mged
Sean (Dec 27 2020 at 06:49):so maybe make sure rt, bw-pix and the overlay command work without crashing. can also run "make test" as there do appear to be some unit tests.
Sumagna Das (Dec 27 2020 at 06:49):i changed the files accordingly because it caused some errors during compilation...
Sean (Dec 27 2020 at 06:50):If you can post a full svn diff from your top-level, I can take a look at it in a few hours on Sun
Sumagna Das (Dec 27 2020 at 06:50):Sean said:
so maybe make sure rt, bw-pix and the overlay command work without crashing. can also run "make test" as there do appear to be some unit tests.
rt worked for me for the mike_tux.g, i think.....but it displayed as a grey platform....dont know why that happened
Sumagna Das (Dec 27 2020 at 06:50):Sean said:
If you can post a full svn diff from your top-level, I can take a look at it in a few hours on Sun
let me do that
Sean (Dec 27 2020 at 06:52):Sumagna Das said:
rt worked for me for the mike_tux.g, i think.....but it displayed as a grey platform....dont know why that happened
It's a gray platform because you created a vol where any non-zero value was to be treated as solid. You made low=1 and high=255.
Sean (Dec 27 2020 at 06:52):which was the whole image, so you got a box
Sean (Dec 27 2020 at 06:53):if you set low to 40 (adjust yourvol low 40) and high to something closer (adjust yourvol hi 80), you'll see something closer to my screenshot.
Sumagna Das (Dec 27 2020 at 06:53):Sean said:
Sumagna Das said:
rt worked for me for the mike_tux.g, i think.....but it displayed as a grey platform....dont know why that happened
It's a gray platform because you created a vol where any non-zero value was to be treated as solid. You made low=1 and high=255.
i guess the plugin should be able to do something about that...
Sean (Dec 27 2020 at 06:53):yeah, that can be the next step after getting everything committed properliy.
Sean (Dec 27 2020 at 06:54):it's fine as it is for now, should work fine if you feed it a black and white file
Sumagna Das (Dec 27 2020 at 07:20):Sean said:
If you can post a full svn diff from your top-level, I can take a look at it in a few hours on Sun
Sumagna Das (Dec 27 2020 at 19:18):Sean said:
what do you think it'd take to make gcv take multiple files? thoughts on how to accomplish that best?
i was thinking about this and want to suggest a thing. We can make a setting if the plugin takes one file as input, multiple files as input or both of the types of inputs.
Sumagna Das (Mar 17 2021 at 18:15):i was just going to try to do the vol plugin work again
Sumagna Das (Mar 17 2021 at 18:16):but i came across one problem
Sumagna Das (Mar 17 2021 at 18:17):it seems like GCV only takes model mime type and no other type
Sumagna Das (Mar 17 2021 at 18:19):so any idea how the plugin can be used again?
Sean (Mar 18 2021 at 04:19):@Sumagna Das it has the mime type and the file path... what other type information are you thinking about?
Sean (Mar 18 2021 at 04:32):I think a first question we should ask is what the command-line usage should look like for a desired conversion goal. Like, what end-state would be ideal? If we're talking about converting a bunch of images into a vol, what could you like "gcv ..." to look like?
Sumagna Das (Mar 18 2021 at 19:43):sorry for the delay in reply but i was building brlcad again because of some issues.......will start working on it after the rebuild
Sumagna Das (Mar 18 2021 at 19:44):Sean said:
Sumagna Das it has the mime type and the file path... what other type information are you thinking about?
IIRC i saw ....._MODEL_UNKNOWN as the mime type for the plugin and i think it didnt work with png the last time i tried
Sumagna Das (Mar 18 2021 at 19:45):Sumagna Das said:
Sean said:
Sumagna Das it has the mime type and the file path... what other type information are you thinking about?
IIRC i saw ....._MODEL_UNKNOWN as the mime type for the plugin and i think it didnt work with png the last time i tried
(because of which i tried to flatten the mime types)
Sean (Mar 19 2021 at 03:04):Sumagna Das said:
sorry for the delay in reply but i was building brlcad again because of some issues.......will start working on it after the rebuild
No worries.
Sean (Mar 19 2021 at 03:20):Sumagna Das said:
IIRC i saw ....._MODEL_UNKNOWN as the mime type for the plugin and i think it didnt work with png the last time i tried
that's what's confusing me though about what you were saying/asking. In the previous code, MODEL_UNKNOWN was the mime type -- it was unknown because of the limitation/assumption that the input would be a 3D type yet we we're feeding images. We couldn't feed it a proper mime type. But that's why I didn't understand what you meant about "no other type".
That problem is/was fixed by flattening the namespace. I didn't dig into the changes that happened since your patch, though, so there may be a merge or update needed.
Sumagna Das (Mar 19 2021 at 19:04):i have the patch but it isnt updated for the recent code
Sumagna Das (Mar 19 2021 at 19:06):was scrolling thru the patch and remembered that most prominent changes were in the mime.cmake files
Sumagna Das (Mar 19 2021 at 19:07):should i try and apply those changes and see what has to be changed?
Sumagna Das (Mar 19 2021 at 20:46):got the changes back up and got it building.
Sumagna Das (Mar 19 2021 at 20:46):should I open a PR for this?
Sumagna Das (Mar 19 2021 at 20:46):the changes for gcv can be added later in a commit
Sumagna Das (Mar 20 2021 at 19:49):and also i was thinking about this
there should also be like a BU_MIME_AUTO for searching all types and returning -1 if there is no such type
Sumagna Das (Mar 22 2021 at 05:35):made kind of an experimental BU_MIME_AUTO which works right now
Sumagna Das (Mar 22 2021 at 05:36):made it work with gcv
Sumagna Das (Mar 22 2021 at 19:40):https://github.com/sumagnadas/brlcad/tree/flatten_mime_namespace
this branch contains the changes to the mime type and gcv
Sumagna Das (Mar 22 2021 at 19:41):i havent opened a PR or something as one thing is left with the vol plugin
after that is done, if you want, i can open a PR
Sumagna Das (Mar 23 2021 at 18:25):hey
i just wanted to ask something
Sumagna Das (Mar 23 2021 at 18:27):is there a way to split "/path/a/b;rpath/h/i;/path/y/z" to ["/path/a/b", "rpath/h/i", "/path/y/z"] using the functions available in BRL-CAD?
Daniel Rossberg (Mar 23 2021 at 18:41):You mean with TCL?
Sumagna Das (Mar 23 2021 at 18:42):no
Sumagna Das (Mar 23 2021 at 18:42):i mean with C functions
Daniel Rossberg (Mar 23 2021 at 18:51):I don't know about a general string splitting function in BRL-CAD. You had to do it "the C way".
Sumagna Das (Mar 23 2021 at 18:53):i was thinking about bu_argv_from_string() function because it somewhat does what i want
Sumagna Das (Mar 23 2021 at 18:53):but it only works for whitespace seperated words.
Sumagna Das (Mar 23 2021 at 18:54):so if i can replace all the ; with whitespace, this might work.
Sumagna Das (Mar 23 2021 at 19:13):so it seems like giving path/a/b;path/d/c as an argument doesnt work libbu
Sean (Mar 24 2021 at 03:56):Sumagna Das said:
should I open a PR for this?
@Sumagna Das you earned committer rights, so you can commit+push with or without creating a pull request.
Sean (Mar 24 2021 at 03:57):I would suggest creating a pull request whenever you want someone to double-check or otherwise review your work, or if there's discussion that you'd like to have before it's merged.
Sean (Mar 24 2021 at 04:13):Sumagna Das said:
https://github.com/sumagnadas/brlcad/tree/flatten_mime_namespace
this branch contains the changes to the mime type and gcv
Hey this looks good to me for the most part. Only things I'm seeing that's maybe an issue is 1) whether it's worth keeping the 2nd-level grouping (e.g., image vs model vs ...) and if it's kept does this change break anything. The lesser 2) issues is wanting to shorten/simplify the api symbols (e.g., bu_mime_t instead of bu_mime_context) so the default usage is more terse.
Sumagna Das (Mar 24 2021 at 04:19):i kept the 2nd-level grouping as i thought that removing it might break stuff which i didnt want.
Sumagna Das (Mar 24 2021 at 04:20):and the renaming can be easily done. there's no problem
Sumagna Das (Mar 24 2021 at 04:29):also, if you have noticed, i added a BU_MIME_AUTO for searching for all the namespace as i wasnt sure about removing the second level grouping.
Sean (Mar 24 2021 at 04:34):Sumagna Das said:
is there a way to split
"/path/a/b;rpath/h/i;/path/y/z"to["/path/a/b", "rpath/h/i", "/path/y/z"]using the functions available in BRL-CAD?
There's not because it's just a one-liner with the standard C strsep() function. Example:
test.c
Sumagna Das (Mar 24 2021 at 04:35):Sean said:
Sumagna Das said:
is there a way to split
"/path/a/b;rpath/h/i;/path/y/z"to["/path/a/b", "rpath/h/i", "/path/y/z"]using the functions available in BRL-CAD?There's not because it's just a one-liner with the standard C strsep() function. Example:
test.c
thanks for that. i will use it later.
Sean (Mar 24 2021 at 04:35):But you certainly could add a separator argument to bu_argv_from_strings() (pointer to a string of potential separators, defaulting to all whitespace chars)
Sean (Mar 24 2021 at 04:37):if you use that snippet, I left out a free(str);
Sumagna Das (Mar 24 2021 at 04:37):Sean said:
But you certainly could add a separator argument to bu_argv_from_strings() (pointer to a string of potential separators, defaulting to all whitespace chars)
can add that but right now, i am focusing only on the gcv and mime types part
Sumagna Das (Mar 24 2021 at 04:39):and also the seperator approach didnt work for multiple files showing either that the file doesnt exist as it is taking the whole argument as a path string or showing permission denied, i dont know why
Sean (Mar 24 2021 at 04:50):sounds like you have/had a bug in the separation?
Sumagna Das (Mar 24 2021 at 05:32):sumagnadas@hp-laptop:~/github/brlcad_git$ build/bin/gcv --input-format png -i ~/Desktop/png/back.png;~/Desktop/png/middle.png -o ../test.g
Bus error (core dumped)
bash: /home/sumagnadas/Desktop/png/middle.png: Permission denied
this is what it is showing without quotes
Sumagna Das (Mar 24 2021 at 05:34):sumagnadas@hp-laptop:~/github/brlcad_git$ build/bin/gcv --input-format png -i "~/Desktop/png/back.png;~/Desktop/png/middle.png" -o ../test.g
ERROR: option parsing failed
Error - file ~/Desktop/png/back.png;~/Desktop/png/middle.png does not exist!
Invalid argument supplied to -i: ~/Desktop/png/back.png;~/Desktop/png/middle.png - halting.
this is output with quotes
Sumagna Das (Mar 24 2021 at 05:35):i was trying to get the argument atleast into the plugin but because of the errors, it didnt even get to the plugin.
Sean (Mar 24 2021 at 05:37):Ah, well you have a secondary issue there. By default the bash shell is actually what expands ~ into your $HOME path. Putting it into a string, you'd have to detect that in gcv and expand it yourself. Bash doesn't know.
Sean (Mar 24 2021 at 05:39):So another issue is that the arguments are being passed to option parsing, and there's clearly some validation function or other logic being called on the -i option to make sure the file exists. You likely have to make it also aware of delimited lists or you need to expand it beforehand so -i "a;b" turns into -i a -i b or something similar.
Sumagna Das (Mar 25 2021 at 05:27):Sean said:
Sumagna Das said:
https://github.com/sumagnadas/brlcad/tree/flatten_mime_namespace
this branch contains the changes to the mime type and gcvHey this looks good to me for the most part. Only things I'm seeing that's maybe an issue is 1) whether it's worth keeping the 2nd-level grouping (e.g., image vs model vs ...) and if it's kept does this change break anything. The lesser 2) issues is wanting to shorten/simplify the api symbols (e.g., bu_mime_t instead of bu_mime_context) so the default usage is more terse.
1st part done but not sure if it will break stuff because it didnt break the build atleast
2nd part was easy with a minor rename.
Sumagna Das (Mar 25 2021 at 06:36):opened a pull request containing the changes......can you please check it?
Last updated: Jan 09 2025 at 00:46 UTC