I making a program that takes screenshots, I use GetFrontBufferData and D3DXSaveSurfaceToFile. But now I am facing trouble.D3DXSaveSurfaceToFile uses d3dx9_43.dll, that cannot be static linked, and program didn't work on pc without directx. How I can save surface, using only D3D?
GetFrontBufferData gets you a pointer to the IDirect3DSurface9. Calling IDirect3DSurface9::GetDesc will give you D3DSURFACE_DESC, describing the image data. Most important for saving it to a file are Format, Width and Height members. Then, you can call IDirect3DSurface9::LockRect to obtain the actual data. The output of this function is a D3DLOCKED_RECT, which contains the image data in the pBits member. Note that the image data might not be tightly packed, you will have to take into account the Pitch member of the D3DLOCKED_RECT. You can then use any static linkable image library, (eg. DevIL) to write the image out to disk, or roll-your-own image writer (writing a BMP/TGA is quite easy).
Or, you could just install the proper DirectX runtime on the target computer, which would probably be a lot easier.
Related
I'm developing a program to print images of different formats (BMP, JPEG, EMF, ...) on HDC using C++ and Windows GDI+. Using the MS Publisher Imagesetter driver I can generate a postscript file and through GhostScript functions I obtain the PDF file. If I try to print the following image:
I obtain the following bad quality result with those strange squares (not present on original image):
The part of my code that I used to print the image is:
SetMapMode(hdcPrint,MM_TEXT);
Gdiplus::Graphics graphics(hdcPrint);
graphics.SetPageUnit(Gdiplus::UnitMillimeter);
Gdiplus::Image* image = Gdiplus::Image::FromFile(srPicture->swPathImage);
graphics.DrawImage(image,x,y,w,h);
I tried to print the same image with many drivers and different kind of formats (different from PostScript: PDF, EMF, real printer) and the result is always acceptable (the squares are not present).
Furthermore, I tried to open the bad quality result with a pdf reader different from Adobe Acrobat Reader DC (Wondershare PDFelement and Chrome) and, even then, the result is acceptable.
I also noticed that if the image contains some different shapes (i.e. a big red line, like in the next image) the result is good too.
At this point, I have no idea if the problem is Adobe reader or my implementation.
Is there a differnt way to print different formats images with GDI+ (or pure GDI)?
The PostScript file generated is this.
Well... You haven't supplied either the PostScript or PDF files, which makes it really hard to comment.
Its not completely obvious to me at what point you are getting the image you show, is this what you see on the PDF file ? Is it something you are getting when printing the PDF file to a physical printer ? If its the lattter, how are you printing the PDF file to the printer ?
The JPEG you have supplied a link to is really small (6Kb), are you genuinely trying to use that JPEG file ?
My guess (and in the absence of any files, a guess is all it can be) that you are using an old version of Ghostscript. Old versions would decompress the JPEG image, then recompress the image using whatever filter produced the smallest result, usually JPEG again.
Because JPEG is a lossy format, every time you apply it to an image the quality decreases.
Newer versions of Ghostscript don't decompress the JPEG image data when going to the pdfwrite device, unless other optsions (eg Colour conversion, image downsampling etc) make it neccesary. The current version of Ghostscript is 9.27 and the release of 9.28 is imminent, I'd suggest you try one of those.
Another possibility would be that either the PostScript program has been created in such a way as to degenerate every image smaple to a rectangle, or you are using an extremely old version of Ghostscript where that technique was also used.
Note that none of these would, in my opinion, lead to exactly the result you've pasted here, but the version is certainly worth investigating. Posting the PostScript program file (ie the file you send to Ghostscript) would be more helpful, because it would allow me to at least narrow down where the problem has occured.
[EDIT]
The fault appears to be an intriguing bug in Acrobat.
The PostScript program uses a colour transfer function to invert the colour samples of the RGB JPEG image. (this is a frowned upon practice, its not what transfer functions are for, but its not uncommon). Ghostscript's pdfwrite device preserves the transfer function.
When rendered Ghostscript correctly produces the expected result, Acrobat, however, spectacularly does not, I have no idea what kind of mess they've made which leads to the result you get but its clearly wrong.
If I alter Ghostscript's pdfwrite production settings to Apply transfer functions instead of preserving them:
-c "<</TransferFunctionInfo /Apply>> setdistillerparams" -f PostScript.ps
then the resulting file views correctly in Acrobat. If I modify Adobe Acorbat's settings so that it uses Preserve instead of Apply for transfer functions (look in Settings->Edit Adobe PDF Settings, then the Color tab, and at 'when transfer functions are found', set the drop-down to Preserve instead of Apply) the resulting PDF file renders correctly in Ghostscript, and the same kind of incorrectly in Acrobat as the Ghostscript pdfwrite output file.
In short I'm afraid what you are seeing here is an Acrobat rendering bug, you can work around it by altering the Ghostscript transfer function settings as above but its really not a problem in Ghostscript.
I'm trying to use the MediaFoundation API to encode a video but I'm having problems pushing the samples to the SinkWriter.
I'm getting the frames to encode through the Desktop Duplication API. What I end up with is an ID3D11Texture2D with the desktop image in it.
I'm trying to create an IMFVideoSample containing this surface and then push that video sample to a SinkWriter.
I've tried going about this in different ways:
I called MFCreateVideoSampleFromSurface(texture, &pSample) where texture is the ID3D11Texture2D, filled in the SampleTime and SampleDuration and then passed the created sample to the SinkWriter.
SinkWriter returned E_INVALIDARG.
I tried creating the sample by passing nullptr as the first argument and creating the buffer myself using MFCreateDXGISurfaceBuffer, and then passing the resulting buffer into the Sample.
That didn't work either.
I read through the MediaFoundation documentation and couldn't find detailed information on how to create the sample out of a DirectX texture.
I ran out of things to try.
Has anyone out there used this API before and can think of things I should check, or of any way on how I can go about debugging this?
First of all you should learn to use mftrace tool.
Very likely, it will tell you the problem right away.
But my guess is, following problems are likely.
Probably, some other attributes are required besides SampleTime / SampleDuration.
Probably, SinkWriter needs a texture it can read on CPU. To fix that, when a frame is available, create a staging texture of the same format + size, call CopyResource to copy desktop to staging texture, then pass that staging texture to MF.
Even if you use a hardware encoder so the CPU never tries to read the texture data, I don’t think it’s a good idea to directly pass your desktop texture to MF.
When you set a D3D texture for sample, no data is copied anywhere, the sample merely retains the texture.
MF works asynchronously, it may buffer several samples in its topology nodes if they want to.
DD gives you data synchronously, you may only access the texture between AcquireNextFrame and ReleaseFrame calls.
In order to accomplish some specific editing on some .avi files, I'd like to create an application (in C++) that is able to load, edit, and save those .avi files. But, what is the most efficient way? When first thinking about it, a simple 3D-Array containing a 2D-array of pixels for every frame seems the simplest solution; But then its size would be ENORMOUS. I mean, let's assume that a pixel only needs a color. One color would mean 3bytes (1char r, 1char b, 1char g). If I now have a 1920x1080 video format, this would mean 2MEGABYTES for only one frame! This data may or may not be smaller if using pointers for the colors, so that alreay used colors wont take more size - I don't really know, since I'm pretty new to C++ and the whole low-level stuff. (As a comparison: One of my AVI files recorded with Xvid codec is 40seconds long, 30fps, and only has 2MB.)
So how would you actually store the video data (Not even the audio, just the video) efficiently (while still being easily able to perform per-frame-changes on it)?
As you have realised, uncompressed video is enormous and it is not practical to store an entire video in this way.
Video compression is an extremely complex topic, but more-or-less, it works as follows: certain "key-frames" are compressed using fairly standard compression techniques similar or identical to still-photo compression such as JPEG. Frames following key-frames are compressed by comparing the frame with the previous one and looking for changes (such as moving blocks). Every now and again, a new key-frame is used.
You don't really have to worry much about that as you are not going to write your own video coder/decoder (codec). There are standard ones.
What will happen is that your program will decode the compressed video frame-by-frame and keep a certain number of frames in memory while you are working on them and then re-encode them when it is finished. In the uncompressed form, you will have access to the individual pixels and can work on them how you want.
You are probably not going to do that either by yourself - it is very hard. You probably need to use a framework, such as OpenCV. There are a huge number of standard filters and tools built in to these frameworks, and it may be that what you want to do is already implemented somewhere.
The OpenCV framework can return individual frames in a Mat object and you can then access the pixels. See this post Get Pixels from Mat
OpenCV
Tutorial page: Open CV Tutorial
The title sums this one up. If I'm loading ~200 images of various size. How can I load just the header so I can know the size of each image?
Currently I find it takes a lot of cpu/memory and IO to load them all in to memory just for the size (I'm trying to generate an atlas from them).
QImage doesn't seem to have a way to do this. QImageReader sounded like it was what I wanted, yet this still seems to just go ahead and read the whole image, so not really sure what its purpose is. Is there another class or some way to use either of the class I've mentioned to only grab the image size from header?
How can I load just the header so I can know the size of each image?
Apparently it looks like you have assumed that image file header(first few bytes of) contains the size of the image. This does not hold true(at least not for all image format type). I checked it for few of formats(PNG).
Currently I find it takes a lot of cpu/memory and IO to load them all
in to memory just for the size
As you have mentioned that you are trying to load around ~200 image at one time just to find the size. This design does not looks good and we should try to decompose our problem into the smaller one. So here the efficient approach might be to open one file and find the size store into some data structure and close the file. If there is other part of your program which needs that ~200 image should be loaded into the memory then we should try to think on how can we avoid it.
QImage doesn't seem to have a way to do this?
It does not have as there seem to be no portable/consistent way to do it for all type of image format. However if you are aware about any file format which contains the header you may write small helper function which can open the file and read the header and find the size. But this helper function would be very specific to a particular type of image format and we may need to write different logic to read the header(all image formats have different header size and information).
I recently saw that when sfml loads a font from memory by receiving a const char*.
How does this represent a font?
I also saw the arial.hpp file only contains a huge array of numbers(chars), which you can feed into the LoadFont function.
the font class in SFML also holds an image, but I don't know how it gets set since there's no load/set function for it, and images are made out of unsigned chars, not char arrays like what the arial font is made of.
How does all this stuff fit together, and how do I create and load a font?
(sfml specific steps would be nice also)
As far as I can tell, there is no LoadFont function in SFML. There are Font::LoadFromFile and Font::LoadFromMemory. I'll assume you're talking about those.
From the documentaiton for Font::LoadFromMemory:
Load the font from a file in memory.
It is for cases when you have loaded something into memory. That is, if you're not using the normal filesystem. Maybe you have all of your data in .zip files, so using standard file IO won't be useful. You load it into a block of memory (the aforementioned array of bytes), and pass it to this function.
The 2.0 documentation is more complete, as it lists the font formats that are accepted.