32-bit Windows Imaging Component Download
Favio Lavaki
I have to load images using Winapi only, its is a homework, I found LoadImage is part of the GDI, and i know GDI is part of Winapi, but it only works with BMP, so there is GDI+ and it seems to work with other formats.
During my research i found other methods like using DirectX because is faster, or WIC wich what i understand is a COM (i guess it stands for COMponent) OLeLoadPicture and IShellImageDataFactory wich could help me load a JPG
I have read in a forum -does-directx-just-wrap-the-win32-api/ that DirectX is not part of win32, it works on a close level with the Hardware and that there would be no meaning of using Directx if win32 would do already the work.it also says that DirectX wraps some Win32 function but just for some dialogs and window handlers, nothing to do with image processing, someone also said that Win32 uses some of DXD9 API. DirectX was designed for windows, so it makes sense to categorize it as a Winapi for me.
But if you look into WinApi MSDN List -us/windows/desktop/apiindex/windows-api-listyou found in the API List which also states that it is called Winapi or Win32, scroll down and you will see there is Listed DirectX, Shell and also COM objects
Also because i want to use DirectX for better image processing performance, and i don't want my professor to say something like... "Oh you did not use Win32 API, you will have to repeat the course", because I'm pretty sure it will happen, and i don't like when someone states something as true when it is not and if that happens i want to be confident enough to prove that I'm still using Win32 API.
Every version of Windows since Windows XP Service Pack 2 (and the associated Windows Server 2003 Service Pack 1) has included "DirectX" as part of the operating system, although exactly what components comprise "DirectX" has changed over time. Windows Imaging Component (WIC) has been in the operating system since Windows Vista (and the associated Windows Server 2008).
The headers for WIC have been in the Windows SDK since the Windows SDK version 6. The headers for Direct2D have been in the Windows SDK since Windows SDK version 7. All the rest of DirectX was put into the Windows SDK version 8.
FWIW, GDI+ is pretty ancient and the recommended API is definitely to use Direct2D and WIC instead. You can use these as COM interfaces directly, or you can use a wrapper helper library like Win2D.
As to that referenced forum question, it's a lot of speculation about the internal architecture. The basic answer is that DirectX has always been a system component, but in the old days Microsoft shipped it as a giant patch via the DirectX Runtime. In fact, it was a very invasive patch that had to update many different versions of the operating system. As of Windows XP SP2, it's just another system component in the operating system.
As a little historic footnote, WIC was created precisely because GDI+ was a huge security problem back in the early days of Windows XP. Many OS components and Microsoft application now use WIC to do all bitmap loading to centralize the fuzz-testing and security servicing. For example, the old D3DX9 helper library included it's own copy of various bitmap codecs, while D3DX10 and D3DX11 helper libraries just use WIC--as do the more modern replacements.
I need to convert and display a JPEG image in LabVIEW l that I continously capture from Canon 1D Mark III camera using the Canon SDK. We have a dll wrapper for the SDK that downloads the images into memory so we have a pointer to the jpeg image stream and its size. Now we just need to convert the JPEG image to the IMAQ image type.
The problem we're running into is that it appears the JPEG - IMAQ conversion functions are buried inside the IMAQ ReadFile vi. Unless I'm missing something simple is saving the JPEG file and reading it back with IMAQ readfile the only way to easily get a JPEG image into an IMAQ image?
I also downloaded some code from the forums called IMAQ JPEG decode that converts a binary JPEG stream, but it has a couple problems including a big memory leak and swapping red and blue color planes.
The only problem that I haven't found where in header the length of the jpeg part was stored. So, I create "dummy" jpeg which is guaranteed bigger than original, and then perform jpeg part replacement and pad with zeroes after that (otherwise you will get error from Unflatten). In attachment two examples - one for 8 bit and another one for rgb image both are OK for play.
Somebody in NI R&D wrote those JPEG decode routines many years ago. I don't think he is in R&D anymore. I chatted with him about them long ago, but I can't recall his name at the moment. They were actually designed so that images could be easily transferred from a remote RT target back to a host PC, but they work great for many other uses. I like to be able to pack a large number of images into a single file, which reads and writes much faster than individual images.
I've had a similar task of converting JPEG image stream into a common 32-bit RGB array, that could be passed to IMAQ VIs. As I'm working in 64-bit version of LabVIEW, I ended at Windows Imaging Component (WIC) and its proxy functions (thanks to this thread). So, I have rewritten that C code in pure LabVIEW with the help of CLFN blocks (ole32, windowscodecs and shlwapi calls). Here's how to use it:
Works fine in both 32- and 64-bit LabVIEW and doesn't need any non-standard external libraries or .NET assemblies. Moreover WIC is able to read not only JPEG, but any other widespread formats, such as PNG, BMP etc.
This article describes a platform update for Windows 7 Service Pack 1 (SP1) and Windows Server 2008 R2 SP1. This update improves the range and performance of the following graphics and imaging components:
The following file is available for download from the Microsoft Download Center:
[Asset 4013443]Download the update package now.
Release Date: February 26, 2013
For more information about how to download Microsoft support files, click the following article number to view the article in the Microsoft Knowledge Base:
Microsoft scanned this file for viruses, using the most current virus-detection software that was available on the date that the file was posted. The file is stored on security-enhanced servers that help prevent any unauthorized changes to it.
Prerequisites To apply this update, you must be running Windows 7 SP1 or Windows Server 2008 R2 SP1.
For more information about how to obtain a Windows 7 or a Windows Server 2008 R2 service pack, click the following article number to view the article in the Microsoft Knowledge Base:
Restart requirement You must restart the computer after you apply this update.
For more information about this update, check the "Additional information for the update" section.
Third-party information disclaimer
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.
Important Some computers that have a combination of Intel and AMD video cards in a hybrid configuration have drivers installed that are incompatible with this platform update.
After you install this update and then restart the computer, the computer may crash because of these compatibility issues. In this situation, you receive a Stop error message that resembles the following:
Note This Stop error includes the "PAGE_FAULT_IN_NONPAGED_AREA" text and the Igdpmd64.sys or Igdpmd32.sys file name.
To resolve this issue, you may have to install update 2834140 ("0x00000050" Stop error after you install update 2670838 on a computer that is running Windows 7 SP1 or Windows Server 2008 R2 SP1). Additionally, use the following tables to install the latest compatible drivers for your video card.
Note For computer systems whose Latest compatible drivers column is marked as None, Microsoft is currently working with AMD to find the cause of the problem and to determine the appropriate fix.
If you have installed the platform update for Windows 7 and you experience a compatibility issue, we recommend that you temporarily uninstall update 2670838. To do this, follow these steps:
If you are a Windows 7 DirectX developer who uses the June 2010 DirectX Software Development Kit (SDK), you'll have to update your development environments after you install this platform update. The following .dll files that are associated with this SDK are incompatible with this platform update:
The Windows 8 SDK: This SDK updates the current development environment with new headers, libs, and tools. These include the development .dll files from the preceding list. This update does not update the C or C++ compilers or the IDE, but it does let developers integrate the new features of the platform update into their applications.
Microsoft Visual Studio 2012: This application includes the Windows 8 SDK, the Visual Studio 2012 IDE, and the new compilers. It also lets developers integrate the new features of the platform update into their applications.
Remote Tools for Visual Studio 2012: These tools represent the minimum requirement in order to continue using the Direct3D debug layer. These tools update only the development .dll files from the preceding list. They do not enable developers to integrate the new features of the platform update into their applications. These tools are available in the "Remote Tools for Visual Studio 2012" section of the Visual Studio Download Center.
Note The Pix for Windows tool from the DirectX SDK is incompatible with this platform update. See Debugging Shaders in Visual Studio for more information about the new tools that are available in Visual Studio 2012.
The global version of this hotfix installs files that have the attributes that are listed in the following tables. The dates and the times for these files are listed in Coordinated Universal Time (UTC). The dates and the times for these files on your local computer are displayed in your local time together with your current daylight saving time (DST) bias. Additionally, the dates and the times may change when you perform certain operations on the files.
7fc3f7cf58