When I call resize on images using app engine, they maintain their aspect ratio - I don't end up with the size I ask for.
I'm trying to make rectangular pixel NTSC images from square pixel sources, so I don't want this behaviour
I want to take an image that is 720x540 and resize it to 720x480 but what I actually end up when ask for the resize is an image that is 640x480.
Is there any way round this?
Alas, while PIL per se could do it, that's not what App Engine's very simple images functionality is using (you may be confused by the fact that the SDK is indeed using PIL to implement that functionality's API on your development machine) -- in particular, resize always does respect the aspect ratio. Your chance to get higher functionality depends on asking for it on app engine's issue tracker, and hoping that many developers have that need!
Are you giving the resize method both a width and a height?
http://code.google.com/appengine/docs/python/images/functions.html
Adam McGrath wrote a great rescale function that crops an image to a specific width and height in his answer here.
Why not use the crop function?
The correct arguments to transform a 720x540 to a 720x480 image would be (presuming you want a center crop):
crop(bytestream, 0, 0.055, 1, 0.945, output)
The crop function takes its arguments as a proportion of the image width or height, specified as a float value from 0.0 to 1.0.
Related
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/
I use monogame. Currently, I have a problem that prevents me to advance. this problem is concerning the image resolution and size to use.
What I want to know is Can I use the same images or I must use different images (Background images whish fill all the screen) for each device according to the resolution and/or the size of the screen.
Thank you in advance.
You can use just one image and scale it to fit the desired resolution. The simplest way to do a background image is to use the SpriteBatch.Draw overload that takes a destination rectangle like so:
var width = _graphicsDeviceManager.PreferredBackBufferWidth;
var height = _graphicsDeviceManager.PreferredBackBufferHeight;
var destinationRectangle = new Rectangle(0, 0, width, height);
_spriteBatch.Begin();
_spriteBatch.Draw(_backgroundTexture, destinationRectangle, null, Color.White);
// draw other sprites here
_spriteBatch.End();
Keep in mind that your images are going to look better if you are scaling them down rather than up, so make them fairly large so they look good on tablets as well as phones. I tend to use 1600x960 because it's twice the size of a common phone resolution 800x480.
The other thing to consider is that the image may with stretch into a different aspect ratio on some screens. In my opinion, this is okay most of the time, but you may want to implement a more sophisticated scaling system. Some people like to use Pillarboxing, Letterboxing or simply cut off the sides in a non-widescreen (not sure what this is called).
Alternately, you could use different images for different resolutions for a higher quality result. Although, I haven't seen this approach used much in games but I think it's pretty common in apps.
you must use diffrent image for each resolution, and put images of the same resolution in one folder to order your code.
I have an ximage which I want to zoom in on, and display. I'm currently taking the naive approach:
allocate bigger image
use nearest-neighbor interpolation to fill it in.
put the whole image on a pixmap.
Which works, but slowly, and crawls once I approach bigger zoom levels, like 800%. The gimp, however, can zoom in to 3200% and still feel snappy. What's the approach taken here? Should I only fill one screen at a time? But then what about scrolling: wouldn't performing interpolation, and an XPutImage, and an XCopyArea on each expose kill performance?
I'm not expert in Xlib, but in my opinion a good approach would be to draw only the zoomed part, instead of computing the interpolation of the entire image.
For scrolling, if you are looking for performances, you may copy the part of the old zoom which is still visible in the new position, and compute the interpolation of the "discovered" pixels. For example, when scrolling down, you may copy the bottom of the previous image and paste it higher, and then compute/draw the new visible stuff at the bottom.
Most modern X11 applications don't use Xlib directly much, if at all. My guess would be that Gimp is rendering the zoomed image into a buffer itself and drawing that to the window, rather than working with the image in an XImage.
My application presents an image that can be scaled to a certain size. I'm using the Image WPF control with the scaling method of FANT.
However, there is no documentation how this scaling algorithm works.
Can anyone reference me to the relevant link for this algorithm description?
Nir
Avery Lee of VirtualDub states that it's a box filter for downscaling and linear for upscaling. If I'm not mistaken, "box filter" here means basically that each output pixel is a "flat" average of several input pixels.
In practice, it's a lot more blurry for downscaling than GDI's cubic downscaling, so the theory about averaging sounds about right.
I know what it is, but I couldn't find much on Google either :(
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4056711 is the appropriate paper I think; behind a pay-wall.
You don't need to understand the algorithm to use it. You should explicitly make the choice each time you create a bitmap control that is scaled whether you want it high-quality scaled or low quality scaled.
My developer's box has a screen resolution of 1680 x 1050. I'm developing a full-screen Silverlight 3 application that I'm considering deploying to the Internet. So, I want to make sure the application looks good on a variety of screen resolutions. I just started testing on other boxes, the first one having a screen resolution of 1024 x 768. During the test I found some of the pages on the application were partially truncated. It seems the controls on the page didn't adjust for the lower screen resolution. So, I'm looking for some tips on how to make a Silverlight application, to the extent possible, adjust for screen resolution. For example, are there things one should or should not do on XAML to make adapting to screen resolution easier? Should I just optimize for a minimum screen resolution? Your thoughts and suggestions are welcomed.
You can easily enforce a minimum acceptable resolution by setting the MinHeight and MinWidth properties of your root visual. (Of course, this should be less than the minimum screen resolution to account for browser chrome.)
Try to specify absolute Width and Height only when necessary: for example, for images or icons of fixed dimensions, or for obvious cases like TextBoxes (whose width should reflect the average length of the data entered).
Grid panels are excellent for mixing scalable and fixed layout areas. The star sizing specification takes a bit of getting used to--it's not as simple as a percentage-based proportioning--but it's much more flexible, especially in combination with row/column min/max dimensions.
You don't really need to test on multiple resolutions unless you're interested in testing a range of dots per inch--just resize the browser to approximate different screens. Since there's always a bit of give and take depending on the user's browser configuration, you'll have to account for some variance anyway.
You can make your application scale with the Silverlight Toolkit ViewBox or make it strech with layout controls like the Grid, StackPanel, and WrapPanel. Make your main UserControl have a Width and Height of Auto (or remove the width and height entirely) and the size of the app will resize to the size of the parent div (the default HTML template uses 100%x100%). Then just resize the browser accordingly. IE8 has developer tools that can help you see your app resized to specific screen resolutions.
Testing on a variety of screen resolutions is always a good idea.
I covered the resizing of elements and making it resolution independent on another thread.
You can have a look here, there are multiple ways to sizing and resizing things automatically.