I have a small video clip that I've run through my video to image software and noticed that the images come out different. Both set of images are identical in which they are cut at 1 second segments. Where they vary is one of the images seem to be brighter then the other set. I'm trying to think what can cause this subtle difference, but I'm at a loss.
I thought that maybe because the hardware is different that would cause this, but I'm not doing anything on the GPU. I also thought that it could be the codec being used, but if the video is encoded the same way using the same codec and information then would decoding really effect it in this way?
Below is a list of what the program is:
Takes a video and saves it out as 1 second images
Uses DirectX in C# to load in a video and saves out the texture.
Video is encoded using MPEG-4 similar compression
I understand that this may not be much information to go off of, but I am at a loss of where I can look.
Any advice is greatly appreciated.
I'd say that images are not actually different. It is unlikely that MPEG-4 decoding uses any GPU resources. Well, it's possible to hardware decode MPEG-4 Part 10, but it's subject to certain conditions too. Far more likely, the effect is due to on of the reasons below (or both):
if you show the picture up within video streaming context, or as you mentioned textures in use - the images might be appearing from YUV surfaces which video hardware is managing differently from regular stuff like desktop, and video hardware might be having a different set of brightness/contrast/gamma controls for those, which result in different presentation
you have different codecs/decoders installed and they decode video with certain differences, such as with post-processing; with all the same encoded video, decoded presentation might be a bit different
Related
I'm programming a directshow application with streaming card. First I installed the drivers and tried their streaming software, everything works perfect and its pixel perfect.
Then make C# code for capturing still images through directshow, pretty much exact copy of DxWebCam example, to be found here in official net library:
https://sourceforge.net/projects/directshownet/files/DirectShowSamples/2010-February/
I also tried more modern approach of using pins and smartee, however I was not able to make it work.
The issue is, the images captured with directshow are just a bit off, like it is using some sort of compression. To demonstrate my issue, here is the original pixel perfect image:
and here is the directshow captured image, with some sort of horizontal pixel mashup: (need to zoom in to see the wrong pixels)
I've tried setting massive bitrate as well as playing with video formats etc.
However I'm just not able to stream pixel perfect in directshow, yet on the same computer with native manufacturer application it works perfectly.
I'm lost as in how to continue or how to try to debug this. Any help appreciated
I have a bunch of apps in the marketplace, and so far I have been able, by changing my functionality or going the extra mile, to work around the issue of being unable to decode a jpg in the background into a WriteableBitmap.
I am finding a situation where I can't think of good ways to "work around" the issue. I need to decode the image I get from MediaLibrary, reduce it's resolution to something managable (800x800), rotate it potentially and save to local storage. By far, the thing that takes the most time (80%) is decoding the bitmap to 800x800 - it takes between 700ms to 1000 ms. A user may add 7-10 images when starting, which translates to ~10 seconds of waiting for the images being added.
I tried doing this lazily, but at some point you need to pay the piper and the app essentially stutters for ~1000ms at that point and the experience is not great.
Is there an alternative I am missing for loading the image in the background somehow?
(Note on why CreateOptions.BackgroundCreation is no good for me: It loads the image into a BitmapImage which is great if you want to just use it, but not so great for what I need to do which is create a copy in Isolated Storage).
Unfortunately something within the constructor of BitmapImage needs to run on the UI thread. :(
I haven't found a workaround but also haven't seen it take anything as long to decode as you're stating.
I need some guidance.
I have to create a simple program, that captures still images every n Seconds, from 4 cameras, attached with USB.
My problem is, that the cameras cannot be "open" at the same time, as it will exceed the USB Bus bandwidth, so I will have to cycle between them.
How to do this, i'm not so sure about.
I've tried using EmguCV, which is a .NET wrapper for OpenCV, but I'm having trouble controlling the quality of my images. I can capture 1280x720, as intended, but it seems like they are just scaled up, and all the image files are around 200kb.
Any ideas on how to do this, properly?
I hate to answer my own question, but this is how I have ended up doing it.
I continued with EmguCV. The images are not very large (file size), but it seems like that is not an issue. They are saving with 96 dpi, and it looks pretty good.
I cycle through the attached cameras, by initiating the camera, taking a snapshot and then releasing the camera again.
It's not as fast as I had hoped, but it works. In average, there is 2 seconds between each image.
I need some help deciding what to use to acquire an image from a webcam. I want to acquire a single image. I know you can typically acquire a still image at a higher resolution than a single video frame.
Currently, I am using MATLAB's image acquisition toolbox.. which apparently only supports obtaining frames in video mode(so lower resolution). Which other libraries do you recommend? Has anyone else encountered this problem?
Are you referring to the fact that the largest resolution reported by the Image Acquisition Toolbox is (for example) 1024x768 but the webcam claims that it can acquire 6 megapixel still images? If so, every webcam that I have ever seen has a note in very small print somewhere that explains that the higher resolution is achieved via software interpolation.
You can just acquire the image in the largest format supported by the toolbox and then use IMRESIZE to scale the image to whatever resolution that you want.
We've used WIA at work before. I can't share our code, but we basically bring up the WIA capture screen (which the user has to interact with before the image is captured). For an automated solution, have a look at this: http://www.codeproject.com/KB/cs/WebCamService.aspx
I'm working on a wallpaper application. Wallpapers are changed every few minutes as specified by the user.
The feature I want is to fade in a new image while fading out the old image. Anyone who has a mac may see the behavior I want if they change their wallpaper every X minutes.
My current thoughts on how I would approach this is to take both images and lay one over the other and vary the opacity. Start the old image at 90% and the new image at 10%. I would then decrease the old image by 10% until it is 0%, while increasing the new image by 10% until 90%. I would then set the wallpaper to the new image.
To make it look like a smooth transition I would create the transition wallpapers before starting the process instead of doing it in real-time.
My question is, is there a more effective way to do this?
I can think of some optimizations such as saving the transition images with a lower quality.
Any ideas on approaches that would make this more efficient than I described?
Sounds like an issue of trade-off.
It depends on the emphasis:
Speed of rendering
Use of resources
Speed of rendering is going to be an issue of how long the process of the blending images is going to take to render to a screen-drawable image. If the blending process takes too long (as transparency effects may take a long time compared to regular opaque drawing operations) then pre-rendering the transition may be a good approach.
Of course, pre-rendering means that there will be multiple images either in memory or disk storage which will have to be held onto. This will mean that more resources will be required for temporary storage of the transition effect. If resources are scarce, then doing the transition on-the-fly may be more desirable. Additionally, if the images are on the disk, there is going to be a performance hit due to the slower I/O speed of data outside of the main memory.
On the issue of "saving the transition images with a lower quality" -- what do you mean by "lower quality"? Do you mean compressing the image? Or, do you mean having smaller image? I can see some pros and cons for each method.
Compress the image
Pros: Per image, the amount of memory consumed will be lower. This would require less disk space, or space on the memory.
Cons: Decompression of the image is going to take processing. The decompressed image is going to take additional space in the memory before being drawn to the screen. If lossy compression like JPEG is used, compression artifacts may be visible.
Use a smaller image
Pros: Again, per image, the amount of memory used will be lower.
Cons: The process of stretching the image to the screen size will take some processing power. Again, additional memory will be needed to produce the stretched image.
Finally, there's one point to consider -- Is rendering the transition in real-time really not going to be fast enough?
It may actually turn out that rendering doesn't take too long, and this may all turn out to be premature optimization.
It might be worth a shot to make a prototype without any optimizations, and see if it would really be necessary to pre-render the transition. Profile each step of the process to see what is taking time.
If the performance of on-the-fly rendering is unsatisfactory, weigh the positives and negatives of each approach of pre-rendering, and pick the one that seems to work best.
Pre-rendering each blended frame of the transition will take up a lot of disk space (and potentially bandwidth). It would be better to simply load the two images and use the graphics card to do the blending in real time. If you have to use something like openGL directly, you will probably be able to just create two rectangles, set the images as the textures, and vary the alpha values. Most systems have simpler 2d apis that would let you do this very easily. (eg. CoreAnimation on OS X, which will automatically vary the transparency over time and make full use of hardware acceleration.)
On the fly rendering should be quick enough if handled by the graphics card, especially if it's the same texture with a different opacity (a lot of graphics rendering time is often loading textures to the card, ever wondered what game loading screens were actually doing?)