I am trying to use a variant of ImageJ, Fiji for analysis of some microscopy images. When I try to "Open Next" to get to the net image, nothing happens.
In the standard version of ImageJ this feature works, and raises an error if it fails.
It seems like some underlying code is missing. I have been unable to find posts that seem to have the same issue. Could it be that I am missing some module for this to work? Could it be somethiing to do with Java?
Any help would be much appreciated, thank you.
There seems to be a file type-specific issue with File > Open Next: when handling .czi files (and other files usually opened using Bio-Formats), the ij.io.Opener#getFileType(path) method returns the wrong type and leads to failure of the search for the next file. See this thread on the ImageJ mailing list.
Related
I've been trying to load a library into lua file. Sparing the details, as they are not really important, I have tried this many ways.
The final way, and the one I believe to be correct although I still can't get it to work, is to use "package.loadlib". See code:
ed = package.loadlib("Encode_Decode.lua", "luaopen_ed")
print(ed)
But when I run the program I get this error:
Encode_Decode.lua is either not designed to run on Windows or it
contains an error. Try installing the program again using the original
installation media or contact your system administrator or the
software vendor for support.
I know the program runs because I used it internally to test it's encoding and decoding abilities and it worked fine. I'd really prefer not moving the contents of the library over as my main lua file is crowded as it is. I will if I have to though.
Yes it is in the main folder. I've also tried changing the extension of the library file into a .dll, with the same error.
What am I doing wrong?
I apologize in advance if this is a duplicate, I did my best to research this problem as thoroughly as I could. But to be honest it's almost 3 AM and I've been searching for almost an hour.
Stupid beginner mistake, used the wrong syntax.
require("Encode_Decode")
print(dec("bnVs")) --returns "nul"
package.loadlib is used for loading shared libraries; i.e. .dll or .so files. You're passing a .lua file to it, so Windows attempts to load it as a .dll and fails when it can't.
To load Lua source code, you can use dofile. Alternatively, you can use require, which is a bit more complex, but handles loading modules only once and works with both Lua and C modules.
I am starting out getting more hands-on with FPGAs and have chosen Xilinx.
In a small trial project I have the problem that XST complains about the library proc_common_v_3 is not found. The ise prj file contains paths looking like "../../.." and so on and it gets recreated when trying to change the paths.
When looking in the project list and not the file, the library is referenced using "........", which is different.
Is there another way to make sure ISE handles libraries correct?
ISE Version 14.7
Error message when doing XST->Check Syntax
Xst:2927 - .... line 1: Source file ../../../../../../../../../../../../../Xilinx/14.7/ISE_DS/EDK/hw/XilinxProcessorIPLib/pcores/proc_common_v3_00_a/hdl/vhdl/proc_common_pkg.vhd does not exist
NB: Yes I know there is a thread on this issue, but my comment gets deleted. The answer there is using what seems to be known working paths, but as starting out that is not possible. Better to go for Altera perhaps.
Thanks in advance.
-Michael
I am new to opencv and I am using opencv for windows. How can I see the source code for a specific function of an opencv library ? I just one want to get an idea of how that specific machine vision algorithm is implemented.
You can get the OpenCV source code from https://github.com/opencv. An easy way to find the header for a function is to open an explorer window in OPENCV_HOME\build\include (where is the location where you chose to install OpenCV) and use the search box to find the header file that contains your function - this will help you know what module it is in. Then you can search in OPENCV_HOME\modules\MODULE_NAME\src to find the source of the the function. This is even easier if you install a search tool like grepWin.
Looking at the source is almost essential for finding out why those pesky OpenCV exceptions are thrown. It also means that you can answer most things about OpenCV yourself without having to ask here.
Here is a direct link to an excellent source code search, courtesy of Github. This is a very straightforward way to find the implementation and internal usages of a function or type.
All the source is now on github:
https://github.com/opencv/opencv and you can use it's search functionalities as well.
I found the answer by Drew Noakes to be the most helpful, especially given the fact that repository structures keep changing over time.
To search in the code or in other places inside a repository using a keyword, the instructions here can be followed.
What would be even easier for first-timers however, would be to simply search for a key word in the github search bar. Then the appropriate advanced search option would generate the tags described in the the earlier linked tutorial.
Okey, this is not a core programming question; it is more of a question regarding cgns (CFD general notational system) API.
I've exported a grid/mesh file from ANSYS Fluent (which was first created in Gambit 2.46), and I wrote a very simple Fortran program to open and close it (doing nothing else). To check the file is not corrupt I plotted it in Tecplot.
So, when I compiled using gfortran with the mentioned cgns and ran the program I got this error (as part of cg_error_exit_f())
ADF_Database_Open:File does not exist or is not a HDF5 file
Here is the program
program cavity
include "/usr/include/cgnslib_f.h"
call cg_open_f("Cavity.cgns",CG_MODE_READ,index_file,ier)
!check for error if so exit
if (ier .ne. CG_OK) then
call cg_error_exit_f()
end if
write(*,*)"I kind of opened the file?"
call cg_close_f(index_file,ier)
stop
end program cavity
I'm able to write both structured and unstructured grids in cgns format, without any problem.
I suspect the cgns library I'm using(version 2.5.5 packaged in Fedora 15 and Scientific linux 6.1) is built to support only HDF5, while the exported grid file is written in ADF format.
Any ideas to circumvent this or perhaps adding ADF? Which by the way is not packaged in both the distributions. Any other grid generator which is compatible with cgns version 2.5.5?
I hope I was clear. Any further info required, I would provide.
There is so much that could've gone wrong in here, and I'm afraid you didn't exactly narrow the problem down.
You said you exported a file from Fluent (what kind of a file is it? Be sure!). cg_error_exit_f() gave you an error listed. I'm assuming you have the source of the mentioned routines? In the program you include a cgnslib_f.h file - what's in it? I'm assumming the program compiled without errors of any kind, making this a file format question, not a fortran question.
Again, verify what kind of file Fluent produced.
When I ran into this situation, I discovered the following tools:
hdf2adf
adf2hdf
They are in the cgns-convert package on Ubuntu and are probably available for your distribution as well.
I'm currently porting a rather big project from C++ Builder 5 to the newest version, C++ Builder XE. It's my first experience with C++ Builder. I'm stuck with an error in a file, but I don't want to include this file anyway (it's code of a component not required anymore). I was not able to find out where and how this file is included, however. The compiler error does not give any hint at all apart from the error itself. How do you usually find out where a file is included?
The preprocessor is perfect for this. Right click on the cpp file which gives you the error in the project manager then choose "preprocess"
The output from this tells you every file and line number in the order they are processed. You can then search for the file in question, and the line above it is the file that included it.
This could conceivably be another header file as well, so it could be a long chain, but you can determine exactly where it comes from.
In the Project Options, enable the compiler's general messages. When the compiler encounters an error, you will be able to see the chain of includes that lead to the erroneous code.
If the files in question are rather sizable, a tool like Doxygen can be helpful in showing you the include dependencies (as well as call paths, etc.).
If it's just once or twice you'll have to do this, David Dean's suggestion of the preprocessor is golden.