Does anyone know what is the maximum width and height of a Bitmap in a FireMonkey TImageViewer?
I am drawing vector graphics in a TImageViewer. I am only able to zoom up to a certain value then I get a memory exceprion.
I've tested this on two seperate computers and it would appear that the actual size limit to a Bitmap in Firemonkey is 8000x8000 px meaning both Width and Height respectively cap at 8000 px size.
This is what I observed, if anyone gets a different result please let me know.
How you plan to get around that is up to you, I would suggest dissecting the source image into multiple parts so that neither part excedes the limit and then assign each part to a different Bitmap component(such as TImageViewer) and then make it all come together as a whole.
Related
I am displaying a grid of images (3rows x 3 columns) in collection view. Each image is a square and its width is determined to be 1/3 of collectionView's width. Collection view is pinned to left and right margin of the mainView.
I do not know what the image height and width will be at runtime, because of different screen sizes of various iPhones. For example each image will be 100x100 display pixels on 5S, but 130x130 on 6+. I was advised to supply images that exactly matches the size on screen. Bigger images often tend to become pixelate and too sharp when downsized. How does one tackle such problem?
The usual solution is to supply three versions, for single-, double-, and triple-resolution screens, and downsize in real time by redrawing with drawInRect into a graphics context when the image is first needed.
I do not know what the image height and width will be at runtime, because of different screen sizes of various iPhones. For example each image will be 100x100 display pixels on 5S, but 130x130 on 6+
Okay, so your first sentence is a lie. The second sentence proves that you do know what the size is to be on the different screen sizes. Clearly, if I tell you the name of a device, you can tell me what you think the image size should be. So, if you don't want to downscale a larger image at runtime because you don't like the resulting quality, simply supply actual images at the correct size and resolution for every device, and use the correct image on the actual device type you find yourself running on.
If your images are photos or raster type images created using a raster drawing tool, then somewhere you will have to scale the original to the sizes you want. You can either do this while running in iOS, or create sets up front using a tool which can give you better scaling results. Unfortunately, the only perfect image will be the original with everything else being a distortion of the truth.
For icons, the only accurate rendering solution is to use vector graphics. Tools like Adobe Illustrator will let you create images which you can scale to different sizes without losing clarity. Unfortunately this still leaves you generating images up front. You can script this generation using most tools and given you said your images were all square, then the total number needed is not huge. At most you need 3 for iPhone (4/5 are same width, 6 and 6+) and 2 for iPad (#1 for mini/ipad1 and #2 for retina).
Although iOS has no direct support I know of for vector image rendering, there are some 3rd party tools. http://www.paintcodeapp.com/ is an example which seems to let you import vector images or draw vector images and then generate image code to run in your app. This kind of tool would give you what you want as the images are now vector drawings drawn at the scale you choose at run time. $99 though.
There is also the SVGKit (https://github.com/SVGKit/SVGKit), but not sure how good/bad this is. It seems to let you simply load and render direct from SVG files. Might be worth trying.
So in summary, I think you either generate the relatively small subset up front using a tool you can control the output from, take the hit in iOS and let it scale the images or use a 3rd party vector to image rendering kit which would give you what you want.
I want to use pdf vector images in my app, I don't totally understand how it works though. I understand that a PDF file can be resized to any size and it will retain quality. I have a very large PDF image (a cartoon/sticker for a chat app) and it looks perfectly smooth at a medium size on screen. If I start to go smaller though, say thumbnail size the black outline starts to look jagged. Why does this happen? I thought the images could be resized without quality loss. Any help would be appreciated.
Thanks
I had a similar issue when programatically changing the UIImageView's centre.
The result of this can lead to pixel misalignment of your view. I.e. the x or y of the frame's origin (or width or height of the frame's size) may lie on a non integral value, such as x = 10.5, where it will display correctly if x = 10.
Rendering views positioned a fraction into a full pixel will result with jagged lines, I think its related to aliasing.
Therefore wrap the CGRect of the frame with CGRectIntegral() to convert your frame's origin and size values to integers.
Example (Swift):
imageView?.frame = CGRectIntegral(CGRectMake(10, 10, 100, 100))
See the Apple documentation https://developer.apple.com/library/mac/documentation/GraphicsImaging/Reference/CGGeometry/#//apple_ref/c/func/CGRectIntegral
This image (http://imgur.com/TyPtrxy) will not load in the simulator, although when I scale it to half the size it loads just fine. When trying to load the full image I just get a black box where it should be.
Yes, there is a maximum image size (number of pixels). The limit depends on the hardware in part, but it is generally in the range of 5 to 10 million pixels. This limit is related to limitations on the maximum sizes of textures that can be sent to the graphics card; therefore, it only applies to images that are drawn.
From the documentation:
You should avoid creating UIImage objects that are greater than 1024 x 1024 in size. Besides the large amount of memory such an image would consume, you may run into problems when using the image as a texture in OpenGL ES or when drawing the image to a view or layer. This size restriction does not apply if you are performing code-based manipulations, such as resizing an image larger than 1024 x 1024 pixels by drawing it to a bitmap-backed graphics context. In fact, you may need to resize an image in this manner (or break it into several smaller images) in order to draw it to one of your views.
It might be that you are hitting some limits on the maximum size of the CALayer (which in turn is dependent on the maximum OpenGL texture size supported by the hardware) that is backing the view. If you're exceeding the maximum size, a message like CoreAnimation: surface <size> is too large will be logged. It's also possible that the decompressed image may be too large to fit in memory. You should use CATiledLayer to display content of that size to ensure that it stays within the resource constraints of the device.
Just to expand a bit on the other answers.
The UIImage documentation (as of iOS 10) no longer seems to mention size limitations, although if you use UIImageView with images whose dimensions are larger than the maximum texture size* supported by the device you happen to be using you do get very large memory consumption at render time.
(The memory consumption I see in Instruments seems to indicate that the entire image is put into a 32 bits per pixel buffer when the CA::Layer is rendered.)
If your app doesn't get kill by the OS due to memory usage, the UIImageView does still end up displaying the image though.
Given this, you'll still need strategies to deal with very large images.
* You can check the maximum texture size using something like glGetIntegerv(GL_MAX_TEXTURE_SIZE, &maxTextureSize);. Just make sure you've set the EAGLContext current context to be something non-nil before querying OpenGL, otherwise you'll get zero.
I have an img#myimage whose src is 1000px x 1000px. Then I resize it with .css() to 100 x 100 and apply resizable() to it:
$('#myimage').css('width' : '100px', 'height' : '100px'})
.resizable();
What happens now when I expand it with the resize handles back to 1000 x 1000? Do I still have a million pixels of resolution, or did I lose something when I reduced the width and height with css()?
It seems that I still have the million pixels, but I'd like to get someone else's thoughts on what's really happening here.
jQuery does not actually resize the image, it just scales it. So when you scale it back up to 1000x1000 it will still be the full resolution (because the image hasn't actually changed).
If you wanted to actually resize and save the image you would need server-side code such as php or asp to process the image and send it back to the browser.
I am working on a BlackBerry App that has a lot of ImageButtons, LabelFields and MessageBoxes. What appears to be perfect on one screen size, seems a mess on the other. For instance, Vertical Field Managers that are neatly aligned center with LabelFields, are left/right aligned on bigger screens. Images that cover the width of the screen appear too small on larger screens. Is there some mechanism to auto-align and dynamically change images with respect to the screen size. Any ideas and documents that can help in this regard?
Here are some tips for making screens that look good on almost all devices:
Use less images. If you have to use images, use atleast 3-4 for different screen sizes. for example if you need to have an image as the screen header, use images with widths 320px, 480px and 640px. Load image depending on the width of the screen.
Do not use pixel measurements. Use point measurements instead. Most of the devices are similar in terms of physical size, whereas they have huge difference in pixel density. Using this you can have a screen which will look exactly identical on curve (320x240), bold2 (480x360) and bold 4 (640x480). If you notice, they have the same aspect ratio and similar physical size.
Do not hardcode positions. Instead use FIELD_HCENTER and DRAW_HCENTER etc for fields.
Do not use fonts with fixed pixel height. Use fixed point height instead.
If using custom fields, make sure that they can automatically expand according to device and pixel density.