When i am capture image from my mobile native app, image size is 2MB, but when capture by, CWAC Camera Library demo, it resolution is very low size is 400kb, Why this happen ?
Please suggiest me proper solution
it resolution is very low size is 400kb
Resolution and file size are not the same thing. Resolution refers to the number of pixels in each direction (e.g., 1920x1080). File size is measured in KB and will depend on a number of factors, such as the resolution and the compression level.
Please suggiest me proper solution
The "proper solution" is for you to compare resolutions, rather than comparing file sizes.
I would also recommend that you not use the library, as I will need to completely rewrite it (due to android.hardware.Camera being deprecated).
If you wish to continue using the library, you will need to read the instructions for controlling picture sizes, setting up a custom CameraHost that returns a valid picture resolution via getPictureSize().
Related
Does SWT (or JFace) have a public convenience method for converting conventional units to their scaled counterparts? I've found mention of a DPIUtil class but that's part of an internal namespace
If there's not a convenience method available, then is there a reliable way to access the zoom level? I see there's Device#getDeviceZoom() but that is protected. There is Device#getDPI() which is public so it might be useful. Does that take scaling into consideration, or is it naïve and just declares that DPI is 96 for everything?
I'm applying default sizing hints to some panels and I'd like them to take the monitor scaling setting into consideration. E.g., Say on a regular display I want the default to be 300px, but at 150% scaling I want to calculate it to be 450px. The calculation is obviously simple but I need the multiplier.
NOTE: This is related but different from my previous question How do you utilize SWT's Hi-DPI support for icons? because SWT provides classes to specifically handle this with images.
I haven't found anything other than DPIUtil for determining the scale (zoom) factor.
But you don't normally need this information. Specifying a size of 300px will be automatically scaled to 450px by SWT on a 150 scaled device (and any 150 scaled image you provide will be used). I have an iMac with two screens - a 5k screen scaled at 200 and a 2.5k screen not scaled - SWT apps appear the same size on both.
The scaling is actually done in the OS rather than SWT (at least that is how it works on macOS). The OS scales up the sizes, renders fonts at the higher resolution and uses the high resolution images if available. So programs don't need to do anything other than provide hi-res images.
This way even old programs that don't know about zoomed displays still appear at a sensible size.
I have a base64 string that it contains an image which scanned by 300DPI and it size is around 500kb . I need to reduce file size to 300kb (+/- %20) without changing DPI in java. Resolution MUST be 300 DPI. I can't change it.
Hovewer, I don't care about dimensions (pixels). I could not figure out how can I do it. I hope, you can help me ?
Thanks:)
Since the size of the photographed object does not change (inches), and the resolution you mandate to be fixed at 300DPI (Dots/pixels per inch), the number of pixels in the image also cannot change.
The only thing you can do in order to reduce the file size is to compress it.
Depending on the image contents, you can, for example, use JPEG compression and set its quality level to a setting that will yield a 300Kb output. Other compression methods may be more applicable, depending on the contents on the image. For example CCITT G4 compression for scanned black & white text.
Regarding how to compress, Google is your friend:
https://www.google.com/search?q=compress+image+jpeg+java
I am very new to ImgScalr API.I need to resize my images to different views, one of them being a mobile view and second a thumbnail view.
I have made use of the resize method, but have a doubt. Which is the best of the resize method to resizing the image out of the multiple options available that keeps the proper aspect ratio(as in the image doesnt become blurred)
One thing I noticed was that every resize method takes in a targetSize argument. How does specifiying this field make sure that the aspect ratio of the image does not get affected.
What should the ideal arguments to the resize method be, given that I need to generate a 2 KB thumbnail view of my input image that may be of size of around 2 MB.
I am a bit confused because of the lack of enough documentation and examples.
imgscalr author here - definitely understand the confusion, the code base itself (if you happen to glance at GitHub) is almost 50% comments if you are curious how the library works, but from a usage perspective you are right - I didn't put a lot of time into examples.
Hopefully I can hit some highlights quickly for you...
Aspect Ratios
A core design tenant of imgscalr is to always honor the aspect ratio - so if you pass in 200x1 (some ridiculous dimension as an example) it will attempt to calculate the minimum dimension that will meet those 'target' dimensions.
This is handy if you always want your thumbnails in a certain box, like 200x200 -- just pass that in and imgscalr will determine a final width/height that won't be bigger than that (possibly something like 200x127 or 78x200)
Quality
By default the library does what is called a 'balanced' approach to quality by considering the delta in dimension change as well as scaling up/scaling down and chooses the most approach approach (speed VS quality).
You can force it to always scale as quickly as possible (good idea for scaling up operations) or can force it to always use high or ultra quality (good idea if you want really crisp thumbnails or other operations that drastically reduce the image resolution and you want them to still look decent)
On top of that you can also ask the library to apply some additional filtering to the image (called Image Ops) -- I ship some handy defaults out of the box like the anti-aliasing one if you are getting jagged edges on a lot of source material you are scaling (common when scaling screenshots of desktops and other things with diag straight lines)
Overall
The library is meant to be as simple as possible to use, something no harder than:
BufferedImage thumbnail = Scalr.resize(src, 128);
will get you started... all the other operations around quality, fitting, modes, ops, etc. are just additional things you can chose to do if you decide the result isn't quite what you wanted.
Hope that helps!
I have a ViewPager that I'm using to page through several ImageViews (around 1000) which each load a full-screen Bitmap. I'm subsampling the images using options.inSampleSize and using a memcache for performance but this is still not fast enough. What I'm trying to avoid is the user seeing blank ImageViews when they page through the views quickly.
I'm wondering if there is a way to serve a partially rendered image (or low quality) while the requested image loads.
I've noticed the Android gallery incorporates something like this (especially noticeable when zooming in and out, loading looks similar to loading of a progressive JPEG on the web), but I haven't been able to find any related information.
Android does not currently provide a way to get intermediate images during decoding (e.g. a progressive JPEG). You only get one final image.
You are already using inSampleSize to get more coarse versions of the image. This makes the decode hopefully quicker, although there are no time guarantees: it uses libjpeg under the hood. Have you measured how long each image decode takes? Have you tried setting inPreferQualityOverSpeed to false? Are you reusing the same bitmap (also may speed up decode). You can also check if inSampleSize makes a different in speed.
In any case, any work of getting low-quality images quickly gets lost if you then want a more detailed version of the same image, as you have to start the decode from the beginning. Therefore, you want to limit decoding to the visible images plus its near neighbors so that you can scroll without blank images.
I'm trying to display a big image file in a J2ME application. But I found that when the image file is too big I can not even create the Image instance and get a OutOfMemory exception.
I suppose I can read the image file in small chunks and create a thumbnail to show to the user?
Is there a way to do this? Or is there any other method to display the image file in the application?
Thanks.
There are a number of things to try, depending on exactly what you are trying to do and what handset you want your application to run on.
If your image is packaged inside your MIDlet JAR file, You have less control over what the MIDP runtime does because the data needs to be unzipped before it can be loaded as an Image. In that case, I would suggest simply packaging a smaller image. Either reduce the number of pixels or the number of bytes used to encode each pixel.
If you can read the image bytes from a GCF-based InputStream (file, network...), You need to understand the image format (BMP is straightforward, JPEG less so...) so you can scale it down into a mutable Image object that would take less memory, one chunk at a time.
In that case, you also need to decide what your scaling algorithm should be. Turning 32 bits pixels in a file into 8 bits pixels in memory might not actually work as expected if the LCDUI implementation on your mobile phone was badly written.
Depending on the content of the image, simply removing half of the pixel columns and half of the pixel lines may be either exactly what you need or way too naive an approach. You may want to look at existing image scaling algorithms and write one into your application.
Remember that basic LCDUI may not be the only way to display an image on the screen. JSR-184, JSR-239, JSR-226 and eSWT could all allow you to do that in a way that may be totally independant from your handset LCDUI implementation.
Finally, let's face it, if your phone MIDP runtime doesn't allow you to create at least 2 images the size of your screen at full color depth at the same time, then it might be time to decide to not support that specific handset.