Activity for Carsten Klein
-
Carsten Klein posted a comment on discussion Developers
Hi there, I'm with you and will try to support a new version 4.0 of FreeImage. Although I've been contributing some small new features to the library written in C/C++, my main focus was always on the VB6 wrapper (as well on the C# .NET wrapper, as long as C# was an option in my software company). However, I'm still here and willing to help with new versions and the VB6 wrapper, at least. BTW, for my mind, FreeImage version 4.0 should be hosted on an official GitHub repository and not longer on SF....
-
You're welcome. Unfortunately, I don't know any .NET Image Metadata library. However, Google should get you a bunch of suitable .NET EXIF libraries.
-
Hi Gian, some of the FreeImage Metadata Models are read-only. You could add tags but they are never written to an image file. Actually, GPS info is read-only for JPEG images. Have a look at Table 13: Metadata models supported by FreeImage on page 77 (approx.) in the PDF documentation. Carsten
-
No, there is no such function in FreeImage available. You need to code one yourself.
-
Hi William, glad to hear that it's working now :-) Carsten
-
Hello William, I'm not a C++ specialist but have some remarks on your code. First, when using the DLL (not linking FreeImage statically), FreeImage_Initialize() and FreeImage_DeInitialise() need not be called, since the DLL does this already in its DllMain entry point. Although FreeImage will not necessarily provide error information for your problem, you must register the FreeImageErrorHandler before calling FreeImage_Save(...). FreeImage's error handler is called directly when an error occurs....
-
I'm still wondering why Microsoft does not include these latest C++ Redistributables into their regular Windows Updates. Isn't it usual, that C/C++ binaries compiled with the operating system's default compiler run out of the box without needing to care for dependencies? It seems like these C++ Redistributables do not install tons of megabytes, so where is the point in NOT installing them automatically?
-
I'm still wondering why Microsoft does not include these latest C++ Redistributables into their regular Windows Updates. Isn't it usual, that C/C++ binaries compiled with the operating system's default compiler run out of the box without needing to care for dependencies? It seems like these C++ Redistributables do not install tons of megabytes, so where is the point in installing them automatically?
-
Oh, that's really good news! Now, as the FreeImage DLL seems to be callable from Access, you can go back to the FreeImage module and test whether all functions required do work properly.
-
John, the dependencies Rob is talking about are a bit different. Your Access dependencies are References to ActiveX-DLLs and OCX-Controls (COM objects). Yes, that are dependencies as well, but what we might have here is something different. Rob's point is, that the 64-bit FreeImage.dll may need other DLLs (like kernel32.dll or user32.dll) in order to work properly. These are dependencies of the FreeImage DLL so, these have nothing to do with your Access dependencies. And since FreeImage is written...
-
Good point, Robert... Since I've never did much C/C++ I didn't think of that. Examining ProcessMonitor logs is quite annoying, so I suggest to try the C++ Redistributable first. According to the sources, the DLL was created with VS 2017, so we need the (new) shared C++ Redistributable for VS 2015, 2017 and 2019. John, could you please give this one a try: x64: vc_redist.x64.exe This can also be downloaded (and much more) from this Microsoft site.
-
Likely the VB6 born ActiveX-EXE solution is worth a try... However, understanding roughly is not the optimal conditions for writing such a COM component. Let's see whether I could code one in some hours (maybe over the weekend?) You basically need just one method for saving a PictureData Byte array to a PNG file, right? So, a method like Public Sub SavePictureData(ByVal Data() As Byte, ByVal Filename As String) As Boolean is all what you need? You could call it like: Call oImgSaver.SavePictureData(MyImageControl.PictureData,...
-
Could you try whether this works in Excel x64? Others recommended to add the full path to the DLL in the Lib clause: Public Declare PtrSafe Sub FreeImage_Unload Lib "C:\Windows\System32\FreeImage.dll" Alias "FreeImage_Unload" (ByVal BITMAP As LongPtr)
-
No, GetTickCount() and GetTickCount64() are both 64-bit functions (as you can only call 64-bit functions from within a 64-bit process). The latter just returns a 64-bit value whereas the first still only returns 32-bit value). So, the first function wraps around (restarts counting at zero) after approx. 50 days system uptime; the latter only after approx. 584,942,417 years. Whatever, you are able to call declared 64-bit functions from Access. Why not these exported from FreeImage.dll? I have no idea...
-
Actually, I only have a quite limited number of ideas left... What about declaring and calling a real Win32 API function? Could you declare and try calling these two functions in your test module? `Public Declare PtrSafe Function GetTickCount Lib "kernel32.dll" () As Long Public Declare PtrSafe Function GetTickCount64 Lib "kernel32.dll" () As LongLong ` You should always get the tick count (number of millis since the system was started) and no File not found error.
-
Hi John, I guess I can come up with the solution... Obviously in 64-bit many things are different. No longer using inline assembler from MSVC is just one thing (not subject to our problem). Have a look at these two attachments, one for 32-bit and one for 64-bit. These show the names of the functions exported by the FreeImage DLL. In 32-bit, these functions are using the __stdcall calling convention and so, are decorated with a leading underscore and a trailing @N, n being the number of bytes on the...
-
Good morning John, hm, that's odd... Is there actually an underscore in your declared function name (at least in the alias name) between FreeImage and Unload? Is it just a SourceForge markdown issue that a single underscore gets lost in a post? Test: using one underscore: FreeImage_Unload@4 using two of them: FreeImage__Unload@4 You could use Sysinternals ProcessMonitor to record, where Access is actually looking for the DLL. You should apply a filter to your Access process (ACCESS.EXE) and start...
-
32-bit DLLs must go into SysWOW64 64-bit DLLs must go into System32 (sounds odd, but is really like that) Wrong declarations (like missing LongPtr) may cause such an error. However, I'm not sure whether it hurts if such a wrong declared function is actually not called. Maybe you should start with a test/dummy module that contains only a handful of (simple) FreeImage functions. The simplest test would be FreeImage_Unload(ByVal Bitmap As LongPtr). Likely this must be a LongPtr, since Bitmap is actually...
-
FreeImage.dll needs not be registered with regsvr32, since it's not a COM DLL but only exports a couple of functions. The DLL not found error may also occur, if 64-bit Access finds the 32-bit DLL on its path (AFAIK, there is no "DLL architecture mismatch" error message). Where did you put the 64-bit DLL and where is the 32-bit DLL?
-
John, I fully understand all of your main reasons 1 to 3... so, clearly you must go for the 64-bit version... According to the code header in your module this actually seems to be the module that I had developed. It's good to hear that you are using just basic features, since there may be some functions that implicitly assume 32 bit pointer sizes. So you should carefully test all functions used by your application. However, since a native 64-bit process (ACCESS.EXE) basically cannot load a 32-bit...
-
John, I fully understand all of your main reasons 1 to 3... so, clearly you must go for the 64-bit version... According to the code header in your module this actually seems to be the module that I had developed. It's good to hear that you are using just basic features, since there may be some functions that implicitly assume 32 bit pointer sizes. So you should carefully test all functions used by your application. However, since a native 64-bit process (ACCESS.EXE) basically cannot load a 32-bit...
-
Hi John, why are you using 64-bit version of Microsoft Access? AFAIK, even Microsoft was recommending to use the 32-bit version if at all possible (at least they did for a long time). There are likely more drawbacks than benefits when using 64-bit concerning code modules, Declare statements and COM components. Is your ModFreeImage based on the official FreeImage VB6 wrapper module? I was maintaining that module for a very long time but there was never any attempt to make it compatible with 64-bit...
-
Hi Francois, add (OR) flag FIF_LOAD_NOPIXELS to the flags passed to FreeImage_Load. Then, only metadata is loaded. That should speed things up :) Carsten
-
Added ZLib function wrappers, pixel access functions and custom array managing functions. Fixed some minor bugs and changed some function declarations.
-
added some minor extensions, bug fixes and complete inline comments and documentation
-
added FreeImage like What's New file
-
Changed format of file for more readability.
-
Added IOlePicture aware toolkit functions, UNICODE functions and support for FreeImage_ConvertGreyScale(). Fixed some minor bugs in pixel access wrapper functions. Now compatible with FreeImage version 3.8.0.
-
Added ImageContainer-related functions, color- and transparency functions, improved SavePictureEx() which takes a 'ColorDepth' paramater with 'FICD_AUTO' option as well as many bug fixes. This will be the last 3.8.0 service release.
-
Added image mask creation functions, windows icon creation, complete image metadata support as well as new features included in FreeImage version 3.9.0 like thumbnail creation, read/write memory streams. Fixed minor bugs in many wrapper functions. Added more helper functions. Now compatible with FreeImage version 3.9.0.
-
Fixed a bug in pGetTagFromTagPtr(): an overflow error occured when converting unsigned short tags (FIDT_SHORT) with values between 32768 and 65535. Now compatible with FreeImage version 3.9.1.
-
Changed signature of declared function FreeImage_UnlockPage(). Added support for function FreeImage_CreateFromScreen(). Fixed a memory leak in wrapper function SafePictureEx(). Added functions FreeImage_SaveEx() and FreeImage_LoadEx() as well as enumeration FREE_IMAGE_LOAD_OPTIONS. Fixed some minor bugs.
-
Added support for new FreeImage 3.9.2 functions FreeImage_JPEGCrop() and FreeImage_LoadMultiBitmapFromMemory(). Added wrapper function FreeImage_LoadMultiBitmapFromMemoryEx() dealing with VB style arrays. Changed all parameters 'flags' from Long data type to either enumeration FREE_IMAGE_LOAD_OPTIONS or FREE_IMAGE_SAVE_OPTIONS. Now compatible with FreeImage version 3.9.2.
-
Changed only to get this file to version 1.8.
-
Fixed a serious memory leak in FreeImage_SaveEx(). Extended function FreeImage_RescaleEx(). Added support for changes in FreeImage 3.9.3. Changed Load/Save flag constants and enumerations. Added ICC Profile support. Fixed some minor bugs. Now compatible with FreeImage version 3.9.3.
-
Added support for new FreeImage 3.10.0 functions and image formats. Added many new wrapper functions. Refactored existing functions. Release is now compatible with FreeImage 3.10.0.
-
File was deleted from repository. MFreeImage_publics.txt is no longer maintained for the FreeImage VB wrapper.
-
Removed property Dib.
-
Removed property Dib. Added documentation.
-
Minor changes.
-
Added plugin self-registration capabilities. LocalPlugin now registers itself in the PluginRepository class.
-
Renamed 'GetICCProfile' to 'GetICCProfileEx'. Renamed 'GetICCProfile_' to 'GetICCProfile' and changed scope to public.
-
Some minor changes.
-
Initial check-in.
-
Changed return type from 'uint' to unsafe 'byte*' for string returning external functions. Added overloaded versions for FreeImage.SetBackgroundColor and FreeImage.Composite. Renamed 'GetICCProfile' to 'GetICCProfileEx'. Renamed 'GetICCProfile_' to 'GetICCProfile' and changed scope to public. Minor changes/updates on comments and source code.
-
Added unit tests for FreeImageBitmap. Updated renamed functions. Some minor changes.
-
Reorganized imports. Added some new files.
-
Removed Assembly Attributes from single source file. Changed both FreeImage.cs and FreeImage.cs.template.
-
Added new sample project.
-
Added NUnit information file.
-
Added assembly info.
-
Some minor changes.
-
Added assembly info.
-
Latest build of the single source file.
-
Reformatted code.
-
Fixed a bug in SaveToStream and some others in GetUniqueColors. Added new functions GetBitmapForDevice, CreateFromHbitmap, Rotate4bit and LoadBitmap. Changed scope of external function DeleteObject to private and exposed public function FreeHbitmap. Refactoring, bugfixes and documentation updates.
-
Renamed to 'clean.bat'.
-
Initial check-in.
-
Fixed a small bug in FreeImage_PaintTransparent, which now calls function FreeImage_ConvertTo32Bits instead of FreeImage_ConvertTo32Bits2. Some minor adjustments.
-
Added some new files to project.
-
Added internal methods GetIndexUnsafe and SetIndexUnsafe for faster access without boundary-check.
-
Changed order of parameters of SaveToStream according to SaveEx.
-
Extracted common code from functions SaveEx and SaveToStream to method PrepareBitmapColorDepth. Changed order of parameters of Load-/SaveToStream according to Load-/SaveEx. Updated methods GetFormatParameters, GetPixelFormat and Compare. Added imported unsafe function CompareMemory; this will be set to internal in the next release. Updated exception handling and documentation. Minor code changes.
-
Adjusted Unit Tests.
-
Refactored method CompareData. Added method CompareMemory(IntPtr, IntPtr, uint) and MoveMemory(IntPtr, IntPtr, uint).
-
Latest build of the single source file.
-
Implemented interfaces IComparable, IComparable<FICOMPLEX> and IEquatable<FICOMPLEX>.
-
Initial check-in.
-
Refactored tag value getters and setters.
-
Name of the template file is defined as a constant now.
-
Minor code adjustments.
-
Latest build of the single source file.
-
Added scanline range check in ctor(FIBITMAP, int). Fixed range checking bugs in Enumerator.Current and Enumerator.MoveNext.
-
Changed unsafe pointer and memory handling. Minor documentation updates.
-
Fixed a bug in constructor FIRGB16ARRAY(FIBITMAP, int).
-
Renamed isCMYK to IsCMYK.
-
Updated exception handling and documentation. Minor code changes.
-
Minor code adjustments.
-
Added structure FICOMPLEXARRAY.
-
Minor documentation updates.
-
Removed TRACE constant from Debug-Configuration.
-
The FI16RGB class along with it's BitSettings class has been superseded by structures FI16RGB555 and FI16RGB565. Only these structures work together with the generic class MemoryArray<T> and it's descendant Scanline<T>.
-
Latest build of the single source file. Introduced new FreeImage .NET namespaces FreeImageAPI.IO, FreeImageAPI.Plugins and FreeImageAPI.Metadata.
-
Removed nowarn switches. Removed and added files to the project.
-
Now uses new generic class Scanline<T> instead of RGBTRIPLEARRAY.
-
Added Sandcastle Help File Builder project file to CVS.
-
Latest build of the single source file.
-
Minor code and documentation updates.
-
Added new method CloneMetadata. Updated version to 3.11.0. Minor documentation updates.
-
Removed /nowarn switch.
-
Removed auto generated comments.
-
This structure is now obsolete and so was removed from the project. It's functionality is now provided by the generic class MemoryArray<T> and it's descendants Scanline<T> and Palette.
-
Overloaded the Equals(object) method. Minor documentation updates.
-
Updated version to 3.11.0.
-
Added new compression flags to the JPEG and PNG plugins.
-
Added support for generic classes Scanline<T> and Palette.
-
Removed and added several files.
-
Some minor changes.
-
Added new constructor (Int32, Int32, FREE_IMAGE_TYPE). Overloaded Equals(Object) and CreateICCProfile(byte[], Int32). Updated GetScanline, GetScanline<T> and GetScanlines; each now returns Scanline<T>. Updated Palette; now returns Palette. Minor documentation and code updates.
-
Initial check-in.
1 >