10-21-2020 03:39 PM
You need to use the DLL with the correct bitness (32 or 64) for your LabVIEW version. A 32-bt application only can load DLLs compiled for 32-bit, and the 64-bit application only can load DLLs compiled for 64-bit.
10-21-2020 03:46 PM
please have a look at this thread here
I wrote a collection of VIs for saving multipage TIFF which don't rely on an external DLL, just Labview.
03-01-2021 09:10 AM
I've just read the whole thread, and not yet tried anything, but it looks a huge work, thanks !
At the beginning you were talking about adding the ability to write/read custom tags (which I'm interested in) and you said that it was tricky to implement (and I trust you), did you abandon the idea?
Should I stop asking you questions on this thread but more on your "ALL-LabView-no-external-library VIs"?
03-01-2021 09:39 AM
thanks for your message: I looked into writing custom tags but didn't find an easy solution with libtiff. Moreover, I am now using a labview only solution which does not rely on any external library, and I think this will make reading/writing custom tags even harder!
However, you could give a look at my code and see whether you find a way of adding the info you need into the file. Good luck and let me know!
03-04-2021 01:52 AM
thank you for your answer Nico,
I'll try to have a look, but honestly I don't feel expert enough to succeed...
I'll let you know.
03-04-2021 02:18 AM
Why would be reading custom tags harder? Of course you can’t provide ready made VIs that provide the user with the fully parsed data type for tags you don’t know but you certainly must have a low level function that actually locates tags in the binary stream to pass the offset and length to the actual parse function that returns then the converted data. Create a “conversion” VI that looks for the tag in the stream and returns the content as binary stream (personally I think a byte array is the most logical choice here but that requires the user to convert to string if he wants to use Unflatten or Typecast. So wish NI had made the Unflatten and Typecast accept byte arrays as an alternative to string inputs many versions ago! It would be a no brainer to do and cost zero time in terms of development time. Bonus points for allowing the Flatten to have a popup selection to choose between generating either of the two and default to byte arrays!)
The user then has to parse this custom tag data himself but that’s the nature of custom tags. 😀
01-04-2023 09:28 PM - edited 01-04-2023 09:31 PM
Thank you so much for doing such a extensive work, and i have read through this thread when i encountered this problem, but not solved yet.
The Problem is here.
Recently, I have downloaded your libtiff2.llb and libtiff3.llb(as you posted on 07-29-2011) for tiff file read and write. But a following error message came when I ried to to run libtiff_example3.vi on my desktop(Labview 2018,Win10X 64bit).
Error 1097 occurred at Call Library Function Node in libtiff2_writeScanLine_U8.vi
LabVIEW: An exception occurred within the external code called by a Call Library Function Node. The exception might have corrupted the LabVIEW memory. Save any work to a new location and restart LabVIEW.
I tried to run the code with Start Single Step to find out the where the error message first came out, and found the message first came out at the "Call library function" node libtiff3.dll:TIFFSetField Node in libtiff2_write_ScanLine_U8.vi,while the libtiff2_open_file_w.vi run correctly.
I have configured the "Call library function" node and specified where is libtiff3.dll on my hard drive.The 64-bit libtiff3.dll I am using was generated in 2015, shown below. I am wondering whether the Error1079 comes because of the old libtiff.dll was not compatible with my Win10 64bit platform.
I would like to know if there is a solution for this problem and whether it is able to generated a new libtiff.dll and regenerate libtiff3.lib in win10 x64 ( I knew this is a quite huge work).
Please advise. Thank you.
01-05-2023 03:51 AM
Your problem is likely that you try to use this with 64-bit LabVIEW. At the time this library was created, the first 64-bit version of LabVIEW was less than 2 years old (2009), and almost nobody saw any reason to install it, since most Toolkits and other 3rd party libraries would only be available as 32-bit anyways.
Accordingly nobody even bothered to consider 64-bit issues when developing new libraries to interface to external code. The problem is most likely not in the DLL but in the VIs interfacing to the DLL. There are a lot of things that might need to be reviewed, revisited, modified and fixed to make those VIs compatible to the 64-bit interface of that DLL. Most can be usually done in a way that it works for both 32-bit and 64-bit, but only LabVIEW 2009 and later provides those features, and before around 2015 almost nobody even bothered about learning what those things are.
There is also the chance that libtiff changed some datatypes and function signatures over time and that your version from 2015 is also incompatible because of such reasons. I know for a fact that they did some changes to the library to add support for BigTIFF 64-bit files, but am not sure if that had any incompatible ABI changes as result.
So to answer your last question. Yes it is possible for sure. Yes, it is going to be a lot of work to review and modify the entire VI library properly. No, it is almost certainly not about regenerating the DLL, but modifying the VIs accessing the DLL functions. And yes, there is likely nobody going to do this for you, so are you willing to pull up your sleeves and get your hands dirty yourself?
01-05-2023 09:03 PM
Many Thanks for your patience.
I need to clearify that the libtiff3.lvlib I was found in Sciscan on Git, and the Labview version is 12.0, and the libtiff3.dll was generated in 2015. Can I infer that the problem comes from the change of Labview Versions.
And I have a second question about modifying the VIs accessing the DLL functions, since Labview provides a Tool to import Shared Libraries(.dll) to generate VI library and the Call Libraries Functions Node,which were used to generate the VI library and call the .dll we configured(specifiy the path where the .dll's location). Whether the only work I can do is to figure out the datatypes during regenerating VI libraries with Labview's import Shared Libraries(.dll) Tool, is there any other aspects I need to aware.
01-06-2023 02:58 AM - edited 01-06-2023 03:06 AM
No it’s not that simple. Interfacing to external code is one of the more taunting exercises in any language out there. In C# it’s Interop, for Python it’s ctypes and for some other languages it’s FFI and LabVIEW calls it Call Library Node. The internet is filled with posts about borked attempts to use one of these to interface to some shared library.
And the reason is simple. Shared libraries where build according to what a C compiler could do and this means two things in order to interface to one:
1) You need to understand how to call the functions in the first place of course.That includes what parameters to pass, in which order to call the various functions, etc.
2) You need to understand and be able to do it in C perfectly in order to be able to do it safely in any other of the above mentioned.
Using the right datatypes is the first and by far easiest challenge here. This is what the Import Library Wizard can do for you.
But each of the mentioned languages is managed in some way. It means it has a specific way to manage how memory buffers are kept track off, how they should be passed between caller and callee, and several more related issues. C has none of this. C was originally designed to be as close to the bare metal of the CPU as possible without using assembly language. The result is that there are none such rules. There are conventions after 50 years of C programming but every C programmer has his own ideas about how to handle this. Many prefer to do it easy and simple and accept that there can be performance issues because buffers are frequently reallocated and copied between. This is the most common case, buffers ALWAYS need to be managed by the caller, and yes this means in LabVIEW you, the writer of the function around the Call Library Node. No machine intelligence can do this for you as much of the necessary information for that is simply not expressible in C syntax but needs to be taken from the hopefully available function documentation or C code samples! Others develop their own more or less involved and library specific management contract to sidestep some of these performance problems. None of these things can be described in the C syntax alone. It’s intrinsic knowledge that the user of the library needs to have by reading the library documentation very carefully, sometimes these things are not even clearly documented but have to be guessed based on name conventions and a deep understanding of C together with painful trial and error.
Basically if you can’t correctly configure the Call Library Node manually in a perfect way, using the Import Library Wizard is not a shortcut but a disservice to yourself. Every single function created by the Import Library Wizard needs to be carefully reviewed afterwards. In any reasonably complex library about 50% of the VIs need to be adjusted to not be a potential memory corruption device and almost all should be modified in some way to not burden the VI library user with C interface specific issues such as a separate numeric parameter indicating to the function the size of an array or string. LabVIEW strings an arrays carry their size with them and the VI containing the Call Library Node should do this translation for the user. But the Import Library Wizard can’t as fheir is no C syntax in the header file that could tell it that these two parameters belong together.
All potential memory corruptions WILL at some point occur according to Murphy, and are translated by LabVIEW into that famous 1097 error (if the corruption wasn’t dramatic enough to destroy major LabViEW internal data structures that make LabVIEW itself go belly up.