I am using OGRE to make a re-rendering of the film, which has a wide aspect ratio (around 1.85). The OGRE dialog seems to be showing the standard full screen resolution by default (800/600, 1024/768, etc.), but those obviously have aspect ratios of 1.333 or around that. But as long as I am not running full screen mode, why should I be restricted to these screen sizes only?
I can definitely change the viewport size, but that would make it difficult for me to generate the video later.
Any idea?
There are no any restrictions for using non standard (4:3) aspect ratio screen resolution in Ogre. Default OGRE configuration window just show list of defaults resolution.
But if you need other screen side you should create it from the code directly depending on the dimensions of your input video.
Related
How to support multiple screen resolutions with Vue? I couldn't find anything about multiple resolutions supporting on nativescript-vue.org.
The default measurement is DIP (Density Independent Pixels) that makes your app mostly look good on different resolution.
But if you still prefer to write CSS specific to a platform / device / screen resolution / orientation, try nativescript-platform-css.
If you want to completely change the layout of your page then you might have to write different components and load them based on your screen resolution.
For saving memory and improving performance，I want to use a special format texture to deal with jpeg picture. The format handles by GL_TEXTURE_EXTERNAL_OES but process is same to GL_TEXTURE_2D (only different from glBindTexture and shader program texture declaration)
I have done it in egl hardware mode('rasterizer_type': 'direct-gles'). But have problems when I use skia hardware mode ('rasterizer_type': 'hardware'), I found skia hardware mode don`t support it directly and will call render_image_fallback_function_ (HardwareRasterizer::Impl::RenderTextureEGL) to deal with it likes 360 video. I found the result for display is very different from it show in egl hardware mode, It seems that the way only use to deal with 360 video. Is there a way to possible I let skia hardware mode support the special format directly or I only add a new way in TexturedMeshRenderer to deal with picture to distinguish 360 video.
Cobalt/Starboard supports letting the platform define custom (possibly accelerated) image decode functionality in starboard/image.h, are you using this to set GL_TEXTURE_EXTERNAL_OES, or are you modifying common Cobalt code?
If you are modifying Cobalt code, you may want to search through https://cobalt.googlesource.com/cobalt/+/master/src/cobalt/renderer/rasterizer/skia/hardware_image.cc for references to "GL_TEXTURE_2D" and make sure that they still make sense after your changes. In particular, you may need to adjust HardwareFrontendImage::CanRenderInSkia().
how can I set height and width in scaling and can I depend on the image generated (quality and professional scale generation).
how can I set height and width in scaling
You can't. Specify a maxSize for each scaling.sizes entry and Fine Uploader will proportionally scale the image.
can I depend on the image generated (quality
Quality will be limited if you rely on the browser only. There is an entire section in the documentation that explains how you can generate higher-quality resizes by integrating a third-party resize library. I also discuss why you may or may not want to do this. From the documentation:
Fine Uploader's internal image resize code delegates to the drawImage
method on the browser's native CanvasRenderingContext2D object. This
object is used to manipulate a element, which represents a
submitted image File or Blob. Most browsers use linear interpolation
when resizing images. This can lead to extreme aliasing and moire
patterns which is a deal breaker for anyone resizing images for
art/photo galleries, albums, etc. These kinds of artifacts are
impossible to remove after the fact.
If speed is most important, and precise scaled image generation is not
paramount, you should continue to use Fine Uploader's internal scaling
implementation. However, if you want to generate higher quality scaled
images for upload, you should instead use a third-party library to
resize submitted image files, such as pica or limby-resize. As of
version 5.10 of Fine Uploader, it is extremely easy to integrate such
a plug-in into this library. In fact, Fine Uploader will continue to
properly orient the submitted image file and then pass a properly
sized to the image scaling library of your choice to receive
the resized image file, along with the original full-sized image file
drawn onto a for reference. The only caveat is that, due to
issues with scaling larger images in iOS, you may need to continue to
use Fine Uploader's internal scaling algorithm for that particular OS,
as other third-party scaling libraries most likely do not contain
logic to handle this complex case. Luckily, that is easy to account
for as well.
If you'd like to, for example, use pica to generate higher-quality
scaled images, simply pull pica into your project, and contribute a
scaling.customResizer function, like so:
scaling: {
customResizer: !qq.ios() && function(resizeInfo) {
return new Promise(function(resolve, reject) {
pica.resizeCanvas(resizeInfo.sourceCanvas, resizeInfo.targetCanvas, {}, resolve)
})
},
...
}
When I make a new Universal App in Visual Studio 2013 I get a number of graphics files for the logos, splash screens, etc. in the Assets folder, for example Square71x71Logo.scale-240.png. The Package.appxmanifest then maps these files to the various required things. For example Square71x71Logo.scale-240.png is mapped in Package.appxmanifest to Square 71x71 Logo.
The actual file is 170 pixels wide, 170 pixels high, Photoshop reads it as having 72 pixels per inch, and it has an 8 bit colour depth.
What does the .scale-240 part of the file name signify?
I'm replacing the file and I am not sure how to scale-240-ify the new image.
The scale-240 part of the file name is a resource qualifier that indicates that the file is used for 240% DPI systems.
Resource qualifiers allow the app to provide different versions of the same resource for different scenarios and refer them all internally by the base name:
Scaling for different DPI systems: .scale-100, .scale-140, .scale-180, .scale-240
Language (if the image has text in it): .lang-de-DE, .lang-en-us
Contrast (to simplify for high contrast modes): .contrast-high, .contrast-standard
Layout direction (if the image should be different in LTR vs RTL language settings): .layoutdir-RTL, .layoutdir-LTR
DirectX feature level: .DXFL-DX9, .DXFL-DX11
The app can reference the image by its base name (e.g. logo.png) and the version which best matches the current scale, contrast level, language, etc. will be automatically used.
The default phone template provides scale-240 images since high-DPI phones are fairly common and it is generally better to scale down from a larger image than to scale up a small image. Best would be for you to provide multiple resolutions when you replace the stock ones with your own, especially if your images are complicated and don't scale well by default.
See How to name resources using qualifiers (XAML)
Universal apps need to be able to run on very different screens. You cannot predict up front what kind of device the user might have. Big difference if he has a cheap contract phone, an expensive slate or a desktop machine. WinRT helps by automatically scaling your app to match the screen resolution.
Supported scaling percentages for a desktop/slate app are 80, 100, 140 or 180%. For a phone it is 100, 140 or 240%.
Text can auto-scale easily but images do not. They get blurry when they get rescaled, a single pixel in the image no longer coincides with a single screen pixel. Pretty noticeable when the image contains fine line art or text. Scaling down necessarily loses pixels, details may disappear.
So the Visual Assets tab of the manifest editor allows you to select multiple images, each suitable for a specific scaling percentage. You found the -240 version in your phone project's Assets directory, the 240% scaling version that were auto-generated when you created the project. The desktop version has -100 assets by default, 100% scaling.
You may want to add your own. You don't have to.
.scale-xxx appears to refer to pre-scaled image resources.
If you are using a an image logo.png with size 100x100px then logo.scale-240.png should be an image of size 240x240px, i.e. scaled by a factor of 240 percent. The idea behind this concept is apparently to avoid potentially expensive and inaccurate rescaling by the displaying device, by supplying several prescaled images at defined scales.
In your case: 170px / 2.40 = ~71px
See also the corresponding MSDN article. (The linked article is in German, I will leave it to the interested reader to find the matching English one ;-)
I am trying to modify the default I-beam cursor image. I'm using [[[NSCursor IBeamCursor] image] representations], passing each one through a CIFilter and adding it to a new image. However, the resulting cursor looks as though it is rendering the low-resolution images.
The High Resolution Guidelines say:
For custom cursors, you can pass a multirepresentation TIFF to the NSCursor class method initWithImage:hotSpot:.
So I would expect this to work. Additionally, if I get the -TIFFRepresentation of the original image and my modified image, and write them to disk, they both look like multi-page TIFF files with the same size images. What could I be doing wrong?
I have a somewhat-temporary solution: manually call -setSize: on each image representation, dividing the pixel height and width by the screen's scale factor. However, this technique doesn't seem like it will work ideally with multiple screens.
You're right on. I've been debugging this all day and I'm pretty sure I've got it nailed. I'm not doing exactly the same thing you are (my images are loaded from a file) but the end result is exactly the same.
The trick is to set the first representation of the multi-representation image to the non-retina size. If you are loading your cursors from an image file, you must take this extra step to adjust the size of the representations to match. It doesn't work 'out-of-the-box' as you would expect.
I've tested this on a machine with two monitors and dragging the window from the retina display to the non-retina display acts as it should, displaying the high/low resolution images for the cursor.
I had a similar problem a while ago: I had my cursor in a PDF, and it always drew as if it was a pixel image at 1:1 size, blown up. There's a solution to that in NSCursor: Using high-resolution cursors with cursor zoom (or retina).
Maybe someone can use that technique to solve this problem? My guess is creating an image with the same size but a different CTM marks it as the same size but Retina. What #jtbrandes is doing probably marks it as a different size and non-Retina. So you're effectively losing the scale factor information. If you create an image with a CTM in the hints, maybe you can draw the filtered images into it and it'll be detected right.