I keep getting black bars on the sides and occasionally on the top and bottom as well. I've been troubleshooting the issue for at least 4 days to no avail. I tried, cropping on export pane, different settings/aspect ratios, new sequences with different settings and Scale to Fit/Fill.
The only settings that got rid of the black bars was changing the pixel ratio to 1.0 but that made my video very blurry.
My sequence settings are same FPS 1920/1080 with matching pixel ratio of 1.0 (to the imported clips). And original clips are all 1920/1080 I don't know what their pixel ratio is but when I import them to Premiere they are all 1.0
These are the export settings
https://i.gyazo.com/af4d2459228bfaad5d86864cb1263aa3.png
From the looks of your title I'm going to assume you're uploading to YouTube? If that's so, you might try using one of the 'Presets' other than custom. If you scroll all the way down, in the preset dropdown, I remember there being options to optimise for YouTube 240/480/720/1080 and so on. This might change what you need to change.
Alternatively, I've made the mistake before of aligning my clips to the 'focus lines' rather than to the edge of the screen. Your solution may be as simple as transforming your clips bigger.
I know this is pretty late to the party. I hope you found what you were looking for.
Related
I'm writing an astronomy application using Apple's SceneKit and want to provide a skybox of stars to surround a planet.
I have found a large JPEG (8192x4096) with suitable content but my "camera" field of view (10 degrees) magnifies the skybox image background enough to cause serious loss of resolution. In short, it doesn't look good .. here's a screenshot showing blurry stars:
https://ramsaycons.com/screenshots/SkyBoxRes.png
One solution for greater fidelity would be, I imagine, to use a resolution independent 'material' image like a PDF, but SceneKit doesn't support PDF 'materials'.
Or, I could find, or build, a better or bigger image for the skybox material. For example, a (32768x16384) would look better, at the cost of a massive image ~ the 'small' one I'm using now is nearly 8MB already.
Another option would be to move closer to the planet and widen the field of view, but I don't want to move the camera so close (specifically, because I want it 'above' geosynchronous objects in my model).
This code-less question feels not quite appropriate for StackOverflow, but my reading of related Q&A's here reveals a knowledge of clever SceneKit tricks I wouldn't have thought off .. maybe there's a trick for me out there!
there are a ton of scaling instructions for GIMP but all of them tell you to scale and save easy peasy. I feel like I'm taking crazy pills.
This is what my save or export generates:
How can I simply export a selection? Shouldn't the GIMP instructions include this detail? Sorry for ranting.
In Gimp (and some other popular image editors) the image you work on is actually made of separate images (a.ka.a layers) held together on a "canvas". The "canvas" gives the size of the final image.
There are three different ways to scale things and you have to use the right one:
The Scale tool : scales the active layer by dragging corners. Doesn't change the size of the canvas. This is probably what you used.
Layer>Scale layer: scales the active layer by providing explicit dimensions. Doesn't change the size of the canvas.
Image>Scale image: scales the whole image contents and the canvas. This is probably what you should have used.
What happened to give you the image above is that you resized the layer using the Scale tool, so you got a tiny image in the corner of the canvas, which didn't change size. The uncovered part of the canvas was displayed as a checkerboard pattern. If you exported to a format that supports transparency such as PNG or GIF the image would have been transparent, but since you exported to JPG which doesn't support transparent images Gimp replaced the transparent part by the default background color.
Everything is well explained on their website. https://www.gimp.org/tutorials/GIMP_Quickies/
My aim is to have 3 images shrink, grow, and move along a horizontal axis depending on selection. Using Auto Layout seems to make the images jump about as they try to fulfil the Top space to superview / Bottom space to superview constraints.
So to combat this I have put all the images inside their own UIView. The UIView is set to the maximum size the images can grow to, it is centred on the horizontal axis. So now all the images must do is stay centred inside their corresponding UIView. This has fixed my problem as the UIViews perform the horizontal translation, while the images shrink/grow inside while remaining centred. My question is - is this the correct way to do this? It seems very long and like I am perhaps misusing the ability of Auto Layout. I have to perform similar tasks with more images and so any advice is welcome! Thanks.
I've just written a little essay on this topic here:
How do I adjust the anchor point of a CALayer, when Auto Layout is being used?
Basically autolayout does not play at all well with any kind of view transform. The easiest solution is to take your view out of autolayout's control altogether, but alternatively you can give it only constraints that won't fight back against the particular kind of transform you intend to apply. That second solution sounds like just the sort of thing you're doing.
If I set the Panorama.Background image brush source to a URL of a photo out on the internet, the image is centered and cropped, rather than starting at the left edge and bleeding off the screen to the right, widescreen style.
If I set the source as a local pack URI, its fine.
Smells like a bug.
Anyone got a simple workaround? Microsoft should be equipping us with a working SDK that allows us to create experiences at least as good as the phone's hubs.
Thanks!
UPDATE
The problem appears not to be images on the web, but images that are smaller than the screen size of the phone - all my web-hosted images are quite small for bandwidth reasons.
Taking my original background art 1024x768 and halving its size results in the phone cropping the right edge of the image.
UPDATE 2
Found someone else with the same problem:
http://forums.create.msdn.com/forums/p/78770/615061.aspx
UPDATE 3
http://www.lukepuplett.com/2012/05/windows-phone-panorama-background-image.html
Side-by-side images demonstrate the bug, clearly. I'll throw it over to Cliff on the team in Redmond and see what he thinks.
It's a problem I've found since my earliest days with the phone, and I assumed it'd be quite a well-known issue. So I expected people to quickly say "Oh yeah, that old chestnut, you need to do XYZ."
Thanks for the -3, everyone. Keep up the good work.
Before running around with "IT'S A BUG!" claims, I would do my research.
That being said, you are downloading an image, and most likely using a combo of BitmapImage/ImageBrush. Now, ImageBrush has a Stretch property and that is where you have to look.
The panorama background is intended to be a rich, high quality image.
I would expect what you're seeing ("inconsistent" resizing) if you're using an image smaller than the space you're filling and not specifying how it should be stretched.
If you're claiming a bug, what is the behaviour you're expecting?
Based on your blog post (liked in update 3) it seems you're expecting a different default stretch behaviour for an image when used in the background in a panorama. As a general rule, introducing inconsistencies or conditional defaults is likely to introduce more confusion and work in the long run.
We have a Silverlight application that shows text over video. Both the text and video can be considered variables. Sometimes we might have a dark video, sometimes a bright video, sometimes a video that has sections of both.
Think of credits at the end of a movie. We want to ensure the end user can always read the text being show over the video. The text is always an overlay on top of the video.
The simple solution is to two show the text twice once in white and once in black with a small offset. This almost works but actually looks a little rough, and takes away from the user experience.
Ideally we would have the text with slight semitransparent glow around the edges. So if the text were white there would be a black glow right around the edges.
Is there a way to do this? Or is there an equal or better work-around?
I've done this with the DropShadow pixel shader effect in Silverlight 3. It works nicely, but since the pixel shaders aren't executed on the hardware, it can have a pretty heavy impact on the performance of the application.
If you wanted to get ambitious, you could write your own pixel shader. Silverlight 3 supports HLSL Shaders.
You could try displaying it with a contrasting outline, rather than just a "drop shadow" like you get if you display it once with a small offset. To do this, display it four times in one color, then a fifth time with a contrasting color, centered over the four previous copies. The four first ones should be offset one pixel up, right, down and left of the center.
The net effect should be an outline. Of course, perhaps this too looks "rough", since it's computer-generated and thus not perfect with respect to issues like kerning, spacing between characters, and so on. But it's quick to try, at least.
In general, automatically finding good contrasting colors when the background is video sounds a bit difficult. In the worst case, the video contains text just like the one you want to display. The correct solution in that case is hard to imagine.
Sounds similar to the problem of ensuring subtitles are always readable in films/TV. The most robust, but not necessarily most elegant solution, is to have a coloured background rectangle for the text which is either opaque or has a low transparency value - often grey or black with good contrasting foreground colour.