I have created vlcControl added on my windows form. I would like to know how can get rid of black bars on my vlc videos (image consumes black space). An example is shown below:
I have tried the line vlc --aspect-ratio 16:9 -L -f /directory/to/file/filename.
The line changes the aspect ratio but did not work as expected. I have tried the following lines of code:
Line 1:
vlcCustomer.Play(new Uri("rtsp://192.168.1.10/2/media/video1"), ":network-caching=50 :aspect-ratio=16:9 -L -f /directory/to/file/filename");
Line 2:
vlcCustomer.Play(new Uri("rtsp://192.168.1.10/2/media/video1"), ":network-caching=50 vlc --aspect-ratio 16:9 -L -f /directory/to/file/filename");
No need to use CLI args for this, libvlc has an API for changing aspect ratio and it is available in Vlc.DotNet. Example: https://github.com/ZeBobo5/Vlc.DotNet/blob/f0d3e2aca37500ccd2710c8b9b286ccc485f1636/src/Samples/Samples.WinForms.Advanced/Sample.cs#L167
The thing is that your control will have the same size, whatever the aspect ratio you give to it, and it will need to fill with black bars. to get rid of it, you will need to resize your control and center it based on the aspect ratio you can get from the media info.
Modify this code according to your screen and paste after your code:
VideoWidth = "1280";
VideoHeight = "750";
VlcControl2.Video.AspectRatio = VideoWidth + ":" + VideoHeight;
Related
I'm tring to modify a pdf with ghostscript via a ps file for add a transversal line, but it don't work for this file.
Input files
B&W pdf
Gradient pdf
I tried:
gs -sDEVICE=tiffsep1 -sCompression=lzw -r300x300 -o out%d.tif post.ps input.pdf
post.ps:
%!
<<
/BeginPage {
newpath
0 0 moveto
1000 1000 lineto
stroke
} bind
/Orientation 3
>> setpagedevice
The black output for my B&W pdf do have the line, but the black output for the Gradient pdf don't have it.
The line seems to be under the pdf!?
The /Orientation for both outputs is correct.
How can I get the expected output for my file with a gradient?
.
I'm calling gs in c# the same way as in this question.
The content of your PDF files contains no transparency operations, so they are opaque. In the case of your B&W file the only marks made on the page are the black areas, in the case of your Gradient file, almost the entire page is marked by the gradient fill.
The BeginPage PostScript procedure is executed at the beginning of the page, before the page contents are processed.
So what happens is that a black line is drawn, then the black marks from the B&W file are drawn. Where the black line is not covered by the black areas of the page contents you can see the line (had you drawn the line in, say, red, you would see where the black areas cover the line).
Your gradient file covers the entire area where the initial black line was drawn, so you can't see any of it.
If you want the line drawn 'on top' of the page content, then you need to use an EndPage procedure, not a BeginPage.
This case was reported as a bug in Ghostscript.
https://bugs.ghostscript.com/show_bug.cgi?id=702597
In fact, the supplied /EndPage procedure was invalid.
/BeginPage and /EndPage procedures are not interchangeable.
See PostScript Language Reference Manual, "6.2.6 Device Initialization and Page Setup" for details.
I'm creating an image with some text and using TextureBrush for draw the text along a line repeatedly. It is working fine on the screen. when i want to print it, it looks very bad.. I've tried to create the image bigger (relative to the dpi differences) and set its resolution as the resolution of the Graphics object (For printing it is higher). Printing the image as it is looks good.. but as TextureBrush not so good.
I'm attaching all the prints - Tried to print it to PDF printer - same results as real printer - so no problem there.
first try before changing anything
Drawing the image using graphics.DrawImage(...) (The image contains The letter 'A' that I've drew in)
Printing TextureBrush
At this time it was clear that i have resolution problem so I've created my image bigger and in better resolution (as the printer dpi)
Drawing the image using graphics.DrawImage(...)
Looks perfect - Exact size and good quality. graphics.DrawImage(...) drew the picture with consideration of its size and resolution.
Now I've used this picture in my textureBrush. The result looks like this
It is bigger because the image itself is bigger - But why it does not consider resolution like graphics.DrawImage(...)..
Anyway i've decided to continue and scale down the image using TextureBrush.ScaleTransform(...) - The results looks like that
This is the best that i've reached so far.. I think the main problem is the TextureBrush that does not consider the resolution of the image.
I would really prefer to stick with the TextureBrush way (And not drawing image by image with clipping and repeating), cause it is very complex code, and complex drawing
Help anyone ?
I'm very new to Android development and decided to approach it using Xamarin. I grabbed the Xamarin (C#) Camera2Api sample from Xamarin's website and got it to the point where I can load the camera preview, take a picture and persist that picture to disk. However, when I look at the picture, it's always 640x480, which is fairly square.
I notice in the Camera2Api project that this is set by grabbing the ScalerStreamConfigurationMap from the camera characteristics, and determining the largest supported size. Here's the snippet:
var map = (StreamConfigurationMap)characteristics.Get(CameraCharacteristics.ScalerStreamConfigurationMap);
if (map == null) {
continue;
}
// For still image captures, we use the largest available size.
Size largest = (Size)Collections.Max(Arrays.AsList(map.GetOutputSizes((int)ImageFormatType.Jpeg)),
new CompareSizeByArea());
For whatever reason, the map.GetOutputSizes((int)ImageFormatType.Jpeg)) always returns a maximum of 640x480.
Can anyone shed some light as to why my emulator only supports such a square image, despite the actual camera preview taking up the full width and height of the screen?
When using the Camera APIs it is important to remember that the capture image size is independent of the preview size.So even though your preview may be full width/height of screen this has no bearing on your capture image size.
The reason 640x480 is being returned as your image size is because that is the largest size image that the "device" you are emulating supports, or its a limitation with the emulator itself. If you were to run this test on a real device you would most likely see a different size image than what you are seeing on the emulator. Alternatively you could print a list of supported capture sizes with map.GetOutputSizes((int)ImageFormatType.Jpeg)
and select a size from that list of a 4:3 aspect ratio at 640x480 is not what you want.
I'm trying to print a pdf with Ghostscript using those settings :
var switches = new List<string>
{
#"-empty",
#"-dPrinted",
#"-dNOPAUSE",
#"-dNOSAFER",
#"-dQUIET",
#"-dPDFSETTINGS=/printer",
#"-dNumCopies=1",
#"-sDEVICE=mswinpr2",
#"-dCompatibilityLevel=1.4",
#"-sOutputFile=%printer%" + printerSettings.PrinterName,
#"-f",
pdfFileName
};
but either the pdf or Ghostscript have bad margins and while it's good when I print it to file it clips when I print it on my printer.
Is there any way to add those programatically with Ghostscript ? I tried many different solutions from first pages of google but none of them work and they seem to have no effect on the printed pdf.
When I try to print it out with Adobe or IE it magicaly adds margins as soon as I choose the printer and it prints fine.
How to achive the same with Ghostscript ?
OK well the first thing is that many of the switches you are setting have no effect:
-empty isn't a Ghostscript-understood switch, and I'm slightly surprised it doesn't cause an error.
-dPDFSETTINGS only affects the pdfwrite device, which is why it is documented in the vector devices section.
-dCompatabilityLevel only affects the output of the pdfwrite device.
-dNOSAFER doesn't have any effect, as that's the default setting.
-f is used to 'close' direct PostScript insertion begun with -c, if you don't use -c you don't need -f
Now almost certainly neither Ghostscript nor your PDF has 'bad margins', the most likely explanation for your problem is that the printer you are using cannot print to the boundaries of the page, the left/right edges, and potentially the top and bottom edges are used by the paper transport mechanism, and the printer cannot print there.
In order to deal with that, you will need to reduce the size of the image, which you can 'probably' do by setting -dDEVICEWIDTHPOINTS and -dDEVICEHEIGHTPOINTS and -dFIXEDMEDIA. Its going to be up to you to work out the correct values for width and height.
Added after the comments below
There are two parts to this problem, the first is to deduce the size of the actual available area to print on, and to scale the output to that size. The second is to then reposition the output on the media so that it is all printed. If as you say the content is significantly smaller than the media then you can ignore rescaling it, but the entire solution is presented here for completeness.
Now as previously mentioned, the first part of this is achieved primarily by creating a fixed size canvas; this is done with any of the media selection switches and the addition of -dFIXEDMEDIA.
NOTE if you alter the media size, then you must, obviously, also alter the scale of the contents, or it won't fit. So you also need to set PSFitPage, EPSFitPage or PDFFitPage depending on the type of input (very recent versions of Ghostscript can use -dFitPage no matter what the input type).
As an experiment I used the file /ghostpdl/examples/text_graphic_image.pdf and sent the output to a printer on FILE:
This command line:
gswin32 -dDEVICEHEIGHTPOINTS=391 -dDEVICEWIDTHPOINTS=306 -dFIXEDMEDIA -sDEVICE=mswinpr2 -sOutputFile=%printer%KensPrinter /ghostpdl/examples/text_graphic_image.pdf
produces output where 3/4 the image is clipped away (the content lies off the newly defined fixed canvas size). If I modify that to:
gswin32 -dDEVICEHEIGHTPOINTS=391 -dDEVICEWIDTHPOINTS=306 -dFIXEDMEDIA -dPDFFitPage -sDEVICE=mswinpr2 -sOutptuFile=%printer%KensPrinter /ghostpdl/examples/text_graphic_image.pdf
then the result is a perfect reproduction of the original, at 1/4 the size (half in each direction).
So, the first thing you need to do is establish the actual printable area of the media on your printer, then you can set the width and height correctly as fixed media, and tell Ghostscript to scale the page to fit.
However, this will still leave the printed image at the bottom left of the media. Since that's in an area that can't be printed, you need to shift the printed image until its centred on the page. As I suggested, you can do this with a BeginPage procedure. This:
gswin32 -dDEVICEHEIGHTPOINTS=391 -dDEVICEWIDTHPOINTS=306 -dFIXEDMEDIA -dPDFFitPage -sDEVICE=mswinpr2 -sOutptuFile=%printer%KensPrinter -c "<</BeginPage {100 100 translate}>> setpagedevice" -f /ghostpdl/examples/text_graphic_image.pdf
produces output where the printed image is shifted up and right by 100 points each.
I believe that a little investigation will allow you to figure out where exactly your printer is able to print, and to create appropriately sized unprintable margins.
Note that, for me, the %printer% syntax does not result in a printer selection dialog. I suspect that your code (whatever language that is) is expanding the %p, resulting in a corruption of the name. Or possibly whatever you use to fork a Ghostscritp process does it. In either event you probably need to double the % signs.
You should get this working from the command line first, then work on getting it into an application.
I am trying to take a screenshot of an application and I would like to make the parts of the rectangle that are not part of the applications region be transparent. So for instance on a standard windows application I would like to make the rounded corners transparent.
I wrote a quick test application which works on on XP (or vista/windows 7 with aero turned off):
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
Graphics g = e.Graphics;
// Just find a window to test with
IntPtr hwnd = FindWindowByCaption(IntPtr.Zero, "Calculator");
WINDOWINFO info = new WINDOWINFO();
info.cbSize = (uint)Marshal.SizeOf(info);
GetWindowInfo(hwnd, ref info);
Rectangle r = Rectangle.FromLTRB(info.rcWindow.Left, info.rcWindow.Top, info.rcWindow.Right, info.rcWindow.Bottom);
IntPtr hrgn = CreateRectRgn(info.rcWindow.Left, info.rcWindow.Top, info.rcWindow.Right, info.rcWindow.Bottom);
GetWindowRgn(hwnd, hrgn);
// fill a rectangle which would be where I would probably
// write some mask color
g.FillRectangle(Brushes.Red, r);
// fill the region over the top, all I am trying to do here
// is show the contrast between the applications region and
// the rectangle that the region would be placed in
Region region = Region.FromHrgn(hrgn);
region.Translate(info.rcWindow.Left, info.rcWindow.Top);
g.FillRegion(Brushes.Blue, region);
}
When I run this test app on XP (or Vista/Windows 7 with Aero off), I get something like this, which is great because I can eek an xor mask out of this that can be used later with BitBlt.
removed dead Imageshack link - Screenshot
Here is the problem, on Vista or Windows 7 with Aero enabled, there isn't necessarily a region on the window, in fact in most cases there isn't. Can anybody help me figure out some way to build a mask like this on these platforms?
Here are some of the approaches I have already tried...
1. Using the PrintWindow function: This doesn't work because it gives back a screenshot taken of the window with Aero off and this window is a different shape from the window returned with Aero on
2 Using the Desktop Window Manager API to get a full size thumbnail: This didn't work because it draws directly to the screen and from what I can tell you can't get a screenshot directly out of this api. Yeah, I could open a window with a pink background, show the thumbnail, take a screenshot then hide this temporary window but thats a horrible user experience and a complete hack I would rather not have my name on.
3. Using Graphics.CopyFromScreen or some other pinvoke variant of this: This doesn't work because I can't assume that the window I need information from is at the top of the z-order on the screen.
Right now, the best solution I can think of is to special case Aero on Windows 7 and Vista to manually rub out the corners by hard coding some graphics paths I paint out but this solution would suck since any application that performs custom skinning will break this.
Can you think of another or better solution?
If you are here, thanks for taking time to read this post, I appreciate any help or direction that you can offer!
If you are looking for a finished application, there is 7capture, which captures also the translucency, so images can be saved to PNG format for later compositing.
EDIT:
The original question and comments indicate you are looking to produce a region on Windows Vista/7 that you can then use to mask out parts the captured image, as is done with Windows XP and non-Aero UIs. Using a region is not going to give you the result you are looking for, since the window outline is not computed as a region, but as an image with variable transparency - RGBA. The Alpha channel in that image is your mask, but it's not an on-off mask like a region, but a gradual mask with a range of values from pixels being fully included to being fully masked out.
Although it uses undocumented APIs, the code at http://spazzarama.wordpress.com/2009/02/12/screen-capture-with-vista-dwm/ will capture to a RGBA buffer which you can then use to render or save the image with the shadow and other translucency effects intact.
In DwmCapture.cs Change
BackBufferFormat = Format.X8R8G8B8
to
BackBufferFormat = Format.A8R8G8B8
(X8->A8)
And you should then be able to access both the usual RGB data plus transparency from the captured buffer. This can then be saved as a PNG or other format with alpha-channel for composing.
Removed idea that is terrible but would have been awesome back in the '90s
You say that using the DWM API only allows you to capture directly to the screen... could you create a window offscreen (say, X = -100000px, Y = -100000px) but visible (maybe even hidden?) and draw the screenshot to it? Since when using the DWM each window has a backing texture, I'm thinking it might still get drawn fine even though the target isn't directly onscreen.
Also, if you want to go the DirectX route and access the actual DX texture backing the window, I found a few leads that might help (especially the first link):
http://spazzarama.wordpress.com/2009/02/12/screen-capture-with-vista-dwm/
http://channel9.msdn.com/forums/TechOff/251261-Help-Getting-the-shared-window-texture-out-of-DWM-/
http://web.archive.org/web/20080625183653/http://www.aeroxp.org/board/index.php?showtopic=6286
http://www.youtube.com/watch?v=hRTgFTMnT_U
Using Graphics.CopyFromScreen or some other pinvoke variant of this:
This doesn't work because I can't
assume that the window I need
information from is at the top of the
z-order on the screen.
If you know which window you need the information from, can you bring it to the front, call Graphics.CopyFromScreen, and then reset its z-index? I know from experience that Aero does odd things when items are in the background in order to make their glass interface work correctly (partial rendering etc). This may not be great UX; however, it would be a special case and used only when Aero is turned on.
You can take a look at the source code of AeroShot, as described on the main page, it can capture rounded edges and with the Aero Glass transparency effect and save it to a PNG file. It's written in C#.