I've successfully built the camera demo from the ios_example and it's running perfect. The problem is that the binary size is comparatively large (Around 11MB binary footprint per CPU architecture). What i'm trying to do now is to shrink the binary size as much as possible.
There is a part named 'Reducing the binary size' in the official document: https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/ios_examples . In the last paragraph it said:
After that, you can manually look at modifying the list of kernels included in tensorflow/contrib/makefile/tf_op_files.txt to reduce the number of implementations to the ones you're actually using in your own model.
So i removed a bunch of items from tf_op_files.txt and rebuilt iOS binary by executing compile_ios_tensorflow.sh, hoping it would reduce the generated binary size. However, the size didn't change at all, not even a single bit. I've tried serval times, i also tried to clear all the content of tf_op_files.txt, but still got the same result.
I guess i was doing wrong somewhere. Does anyone know how to do it right? Or is there any other way to reduce the binary size except those from the official documentation?
Any information is appreciated. Thanks!
TF already has to tool to do 8-bit Quantize. It can largely decrease the model size but may hurt the precision.
Related
Having two or more images that partially overlap, like in this screenshot, I want to combine/merge them into one:
The coloured squares would be the source images, in lossless format, and no rotation is required.
The result I want is like using the "Auto-Blend Layers" command from Adobe Photoshop, so auto-align and auto-blend is performed automatically:
https://helpx.adobe.com/photoshop/using/combine-images-auto-blend-layers.html
Thank you all for the comments. The software that suits best in this case is OpenCV with the cv::Stitcher API as #aergustal pointed out. It works extremely well provided that pictures have a decent overlapping, otherwise the following error will be displayed:
Can't stitch images, error code = 1
Note that to be able to use the ./cpp-example-stitching command, you have to compile it from source code. Even Windows doesn't come with it precompiled, at least the version I've downloaded. More information:
High level stitching API (Stitcher class)
Keep Data out of Code
Moving any resources, such as long strings, or tables, out of code and
into external files will make the final download smaller, because
external files compress more efficiently than when the data is
compiled into a binary. See iOS App Store Specific Considerations for
full technical background.
How much does strings affect binary size in iOS apps, being in code versus their own file?
Is this something significant? Right now my binary size from code is 4mb, but it has a lot of long texts. How much can it decrease?
I use opencl for image processing. For example, I have one 1000*800 image.
I use a 2D global size as 1000*800, and the local work size is 10*8.
In that case, will the GPU give 100*100 computing units automatic?
And do these 10000 units works at the same time so it can be parallel?
If the hardware has no 10000 units, will one units do the same thing for more than one time?
I tested the local size, I found if we use a very small size (1*1) or a big size(100*80), they are both very slow, but if we use a middle value(10*8) it is faster. So last question, Why?
Thanks!
Work group sizes can be a tricky concept to grasp.
If you are just getting started and you don't need to share information between work items, ignore local work size and leave it NULL. The runtime will pick one itself.
Hardcoding a local work size of 10*8 is wasteful and won't utilize the hardware well. Some hardware, for example, prefers work group sizes that are multiples of 32.
OpenCL doesn't specify what order the work will be done it, just that it will be done. It might do one work group at a time, or it may do them in groups, or (for small global sizes) all of them together. You don't know and you can't control it.
To your question "why?": the hardware may run work groups in SIMD (single instruction multiple data) and/or in "Wavefronts" (AMD) or "Warps" (NVIDIA). Too small of a work group size won't leverage the hardware well. Too large and your registers may spill to global memory (slow). "Just right" will run fastest, but it is hard to pick this without benchmarking. So for now, leave it NULL and let the runtime pick for you. Later, when you become an OpenCL expert and understand more about how the hardware works, you can try specifying the work group size. However, be aware that the optimal size may be different for different hardware, and there are other rules (like global size must be a multiple of local size).
I am working on a security problem, where I am trying to identify malicious images. I have to mine for attributes from images (most likely from the metadata) that can be fed in to Weka to run various machine learning algorithms, in order to detect malicious images.
Since the image metadata can be corrupted in various different ways, I am finding it difficult to identify the features to look at in the image metadata, which I can quantify for the learning algorithms.
I had earlier used information like pixel info etc using tools like ImageJ to help me classify images, however I am looking for a better way (with regards to the security) to identify and quantify features from the image/image-metadata.
Any suggestion on the tools and the features?
As mentioned before this is not a learning problem.
The problem is that one exploit is not *similar* to another exploit. They exploit individual, separate bugs in individual, different (!) libraries, things such as missing bounds checking. It's not so much a property of the file, but more of the library that uses it. 9 out of 10 libraries will not care. One will misbehave because of a programming error.
The best you can do to detect such files is to write the most pedantic and at the same time most robust format verifier you can come up with, and reject any image that doesn't 1000% fit the specifications. Assuming that the libraries do not have errors in processing images that are actually valid.
I strongly would recommend you start with investigating how the exploits actually work. Understanding what you are trying to "learn" may guide you to some way of detecting them in general (or understanding why there is no general detection possible ...).
Here is a simple example of the ideas of how one or two of these exploits might work:
Assume we have a very simple file format, like BMP. For compression, it has support for a simple run length encoding, so that identical pixels can be efficiently stored as (count x color pairs). Does not work well with photos, but is quite compact for line art. Consider the following image data:
Width: 4
Height: 4
Colors: 1 = red, 2 = blue, 3 = green, 4 = black
Pixel data: 2x1 (red), 4x2 (blue), 2x3, 5x1, 1x0, 4x1
How many errors in the file do you spot? They may cause some trusting library code to fail, but any modern library (written with knowing about this kind of attacks and with knowing that files may have been corrupted due to transmission and hard disk errors) should just skip that and maybe even produce a partial image. See, maybe it was not an attack, but just a programming error in the program that produced the image...
Heck, even not every out-of-bounds use must be an attack. Think of CDs. Everybody used "overburning" at some time to put more data on a CD than was meant by the specifications. Yes, some drive might crash because you overburned a CD. But I wouldn't consider all the CDs with more than 650 MB to be attacks, just because they broke the Yellow Book specifications of what a CD is.
I'm putting together a script to find remove duplicates in a large library of images. At the moment I'm doing a two pass filter of first finding files of the same size and then doing a sha256 on a 10240 byte piece of the file to get a fingerprint of the files with the same size (code here).
It works well, but I'm guessing there are probably checksums built in to the jpeg format that I could use instead of doing the sha256.
Does anyone know if there are checksums or other components that could act as checksums / fingerprints? If so, is there an efficient way to access them?
I don't think the JPEG specification includes any kind of checksum in the way you're describing.
A JPEG can contain a thumbnail as part of its EXIF metadata, though. It's not a perfect indicator, since it's possible for two different images to have the same thumbnail. There's at least one documented case of a thumbnail not being replaced after the image had undergone substantial modifications, said thumbnail revealing much more than the publisher had intended.
Its been awhile since I've dug into the IJG library, but I don't think there's an easy class member or function call you can use there to check for some type of fingerprint. You could use the built in EXIF tags if you can control the encoding of the images...
I'm just built a very similar script. I don't want to checksum metadata I want to see if the actual images are duplicates even if tags have been modified. Best for that is not to sort by size, but do sort by the checksum istelf. I use jhead to remove metadata and then checksum the whole file (but I also thought about just doing part of it, but actually I don't think it saves much time). jhead doesn't use shared memory (pipes) and does overwrite so I just copy the file to shared memory first. I place the checksum in the ImageDescription field for later faster retrieval. Obviously this also allows to check image integrity later and is part of why I checksum the whole thing. Tip: exiv2 is MUCH faster for reading and writing the metadata than exiftool for one at a time decision based manipulation.
In JPEG standard(ITU-T.81) i believe there isn't any field/syntax element which has a checksum or such, for the whole compressed jpeg image file. Unless a customised application puts such filed in the Application segment, or as meta data for which segments are provided in the standard.
So to serve your purpose, what you are doing is one soln.
Other could be some kind a application wrapper which will call some binary file compare utlitiy (like beyond compare, or even a windows command fc /b) and check the result of that compare utility and take the decision u want to.
-AD
One way you could perform is reduce all images to a fixed size and store that as a thumbnail. Then the image comparison would compare similar sized images and give you a chance of being a duplicate - useful if you have cropped (unless cropped heavily) or resized images and want to find those 'duplicates'.
In the XMP specification there are document ID and version ID which should uniquely identify the version of the image.
The problem with these (and with any other metadata-based identification method) is that it might not be respected by some applications that can change the content of the jpeg updating the metadata accordingly.