I want to load a jpg file. I tried to use the LoadImage function but it returns NULL if my image is not bmp. What can I do? Here is my code:
hBitmap =(HBITMAP)LoadImage(0, L"D:\\1.jpg", IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE).
You can have a look at WIC.
Windows Imaging Component (WIC) API enables applications to work with all common image formats. It allows developers to not have to understand intricate details of the image formats they work with. WIC has built-in support for popular formats such as JPEG, PNG, TIFF, and GIF as well as an extensibility model so that developers can create their own WIC decoder and encoder (CODEC) and get platform level support for their image format. WIC is available on Windows XP (SP2 and greater), Windows Vista, Windows Server, and Windows 7.
Use GDI+, it has a JPEG decoder. Start that ball rolling with #include <gdiplus.h> and a small tutorial to know how to use the Image class and GdiplusStartup properly.
If you want to support really old stuff (Win9x etc,) IPicture / OleLoadPicture is your best bet
Related
I have a Power Point presentation that I would like to convert to Scorm 1.2. I have tried Adobe Captivate, however the videos within my presentation will not be Flash. Adobe does not work with my files. I have tried Scorm Hero. The videos and gif images will not run. Scorm Hero customer service says they do not support videos or gifs. Can anyone suggest a good conversion tool for converting power point slides to SCORM 1.2 that will suppport gifs and videos? Thank you.
ScormHero now supports video conversions, just tested and is working fine. It also convert media (video or audio) from PowerPoint.
Take a look at any of the rapid development e-learning software out there. I believe Articulate 360 allows you to put a plugin directly into PPT to export out to SCORM compliant packages.
Articulate
https://articulate.com/360
I agree with your statement about Adobe Captivate, not really user friendly from a PPT perspective and pretty pricy.
I'm currently developing a consrol software for a camera that delivers 14 bit/sample grayscale images (specifically it's a scientific x-ray camera).
So far I just used the upper 8 bits and passed those to a QImage, so that I could see something. However now I need to show all detail, a widget that supports HDR and tone/pseudocolour mapping is needed.
Before I start developing such a widget and subclass QImage for HDR support I'd like to know if someone already did this for Qt and published the source under LGPL.
VTK has really good Qt widgets and supports everything what you may need for medical imaging.
Currently we use ParaView. ParaView is based on VTK and Qt, fully open source and easily extensible.
I am writing a video using OpenCV on Linux machine. I want to read the same video using OpenCV on a Windows machine. I am not able to do this using the standard codecs provided in openCV.
Can anybody suggest how I can read/write videos across the two platforms?
The OpenCV Wiki directly addresses this issue. See http://opencv.willowgarage.com/wiki/VideoCodecs and specifically the heading "Compatibility list."
Unfortunately the only codecs supported on all three platforms (Linux, Windows & OSX) are 'DIB' 'I420' and 'IYUV' which are all uncompressed video codecs and thus make for really huge file sizes.
The wiki also lists some codecs to try that may work on any two platforms but not on all three.
If you decide to use uncompressed video files, you can convert them to something with a smaller filesize once they are on your windows machine using a program like VirtualDub.
Edit: FYI, On Windows I have OpenCV output in Motion-JPEG and then I use VirtualDub in directstream copy mode to resave the file which corrects a bug with the movie's index. These M-JPEG video files then play by default on Mac and Windows.
If I am trying to read video into OpenCV, I often will first convert my video to Cinepak, (using virtual dub, quicktime etc.) and then feed it into OpenCV. I use Cinepak because for some reason Cinepak encoders seem more prevalentthan MJPEG encoders.
I don't think the problem is with OpenCV, I think it is with codecs, as you mentioned. I also don't think OpenCV comes with codecs... double check that you have the proper codecs installed under Windows.
Did you look at the documentation on video codecs?
I am using 2 500K bitmaps in to display images on my WiX dialogs.
They dramatically increase the size of the installation package, and what is worse - it looks there's no way to package them as a part of a .cab file since they're <binary>-es in the WiX terms.
So, I thught, is there any way to use other file formats for bitmaps or WiX is tethered with BMP? Ideally it would be greate if there's a way to use .png format since it comes with a looseless compression option.
The Windows Installer documentation for the Bitmap control states that the image should be a "bitmap" -- presumably a .BMP file -- or a JPEG.
You have to remember, when working with WiX, that it's based on Windows Installer. This means that any limitations in WiX are often caused by limitations in the underlying Windows Installer implementation.
.BMP files can be RLE-compressed. I don't know if they support any other compression algorithms.
The WiX toolset isn't tethered to BMP and JPG. As you've found you could put any of those other image formats into your package. However, the MSI SDK only documents BMP and JPG support.
Yes, if you only need to install on Windows 8 or later. From Bitmap Control:
Windows 8 and Windows Server 2012: The image file can be in any
standard format supported by the Windows Imaging Component (WIC),
including TIFF, JPEG, PNG, GIF, BMP, and HDPhoto. The control does not
support animation.
As was stated in other answers the image format limitation comes from Microsoft's implementation of MSI, and not from WiX. Although .jpeg seems to be supported starting from Windows 7, and PNG starting from Windows 8, be very careful about the format you use. Your trade-off is the look of your installer.
My experience showed that the only reliable way to ensure that your resulting installer displays your images correctly is to use uncompressed BMPs. And that is it! Yes, I know they balloon the size of the final file, but, hey, like everything else with Microsoft they are ages behind and there's no way around it.
So if you don't want to have your installer to display gray squares on Windows XP or Vista instead of your graphics, don't use anything other than raw .bmp format.
I am using Windows Media Format SDK to capture the desktop in real time and save it in a WMV file (actually this is an oversimplification of my project, but this is the relevant part). For encoding, I am using the Windows Media Video 9 Screen codec because it is very efficient for screen captures and because it is available to practically everybody without the need to install anything, as the codec is included with Windows Media Player 9 runtime (included in Windows XP SP1).
I am making BITMAP screen shots using the GDI functions and feed those BITMAPs to the encoder. As you can guess, taking screen shots with GDI is slow, and I don't get the screen cursor, which I have to add manually to the BITMAPs. The BITMAPs I get initially are DDBs, and I need to convert those to DIBs for the encoder to understand (RGB input), and this takes more time.
Firing a profiler shows that about 50% of the time is spent in WMVCORE.DLL, the encoder. This is to be expected, of course as the encoding is CPU intensive.
The thing is, there is something called Windows Media Encoder that comes with a SDK, and can do screen capture using the desired codec in a simpler, and more CPU friendly way.
The WME is based on WMF. It's a higher lever library and also has .NET bindings. I can't use it in my project because this brings unwanted dependencies that I have to avoid.
I am asking about the method WME uses for feeding sample data to the WMV encoder. The encoding takes place with WME exactly like it takes place with my application that uses WMF. WME is more efficient than my application because it has a much more efficient way of feeding video data to the encoder. It doesn't rely on slow GDI functions and DDB->DIB conversions.
How is it done?
The source to CamStudio, a GPL'd screencasting app that's been around for years (commercially and then open-srcd later) might be useful?
http://sourceforge.net/project/showfiles.php?group_id=131922
I'd suggest looking at the guts of VNC clients too, though they're probably very simplistic (I think just grabbing screenshots then jpg'ing the tiles that have changed since the last capture).
You might want to consider not using WMV9 as the encoder for on-the-fly encoding if it is too cpu-heavy? Maybe use an older, less efficient compressor (like MS RLE) as used by HyperCam and then compress to WMV afterwards? MS RLE has been a default install since at least Win2000 I believe:
http://wiki.multimedia.cx/index.php?title=Microsoft_RLE
CamStudio's Lossless codec is GPL (same link as above), that offers pretty good compression (though you'd need to bundle the dll in your installer) and could be used on the fly, it works well with high compression on all modern systems.
It's been ages since I've done any Win32 coding, but AFAIK, WMF as a format is basically a list of GDI commands and their parameters which would explain why it is much more efficient to encode...
You'd probably need to hook into the top level GDI context (just as Remote Desktop does, I guess) and capture the GDI commands as they are called. I seem to remember there being some way of creating a WMF output GDI context which means you may be able to just delegate calls to it in some way.
I'm guessing here, but you may be able to find example code for the above in the TightVNC/QuickVNC for Windows projects as they would have to do something like that to capture changes on screen in an efficient way.
Have you checked out the BB FlashBack library?
I am on a similar hunt, and I have just started evaluating the BB FlashBack library.
I am not sure about the external dependencies or install footprint. It appears to have a proprietary codec that has to be installed, but the installation of the codec can be handled by the exposed BB FlashBack API.
Beware, there are licensing restrictions (Runtime setting of license keys, ...)
I can send you the CHM from the SDK via e-mail if you want to evaluate the API before committing to a licensed download.
Things I am in the midst of evaluating:
Proper captures of WPF views
mouse cursor tracking
Size of stored movie
How to display stored movie without proprietary codec (i.e. SWF export)
--Batgar