> Does BitmapFactory.decodeFile("path to a JPEG file") decompress the JPEG image when decoding it as a Bitmap in the memory?
Yes.
> And when I use Bitmap.compress(Bitmap.CompressFormat.JPEG, 100, byteArrayOutputStream) on the resulting bitmap from the decoded JPEG file, then the size of the compressed image is more than the size of the original image
That is very possible. With a quality level of 100, I would consider it likely, though perhaps not assured.
> Can anybody exactly explain this phenomenon?
There is no requirement that they be the same for a JPEG. In fact, it will be almost random chance if they *are* the same.
Suppose we start with an in-memory image (B<sub>original</sub>, where B is short for bitmap). We then compress that image to a JPEG (J<sub>original</sub>). JPEG incorporates a lossy compression algorithm, to achieve better compression on real-world images (e.g., photos) by taking into account the fact that human eyes cannot discern small amounts of change.
Suppose we then decode J<sub>original</sub> back into an in-memory bitmap (B<sub>reloaded</sub>). B<sub>reloaded</sub> *will not be the same image* as B<sub>original</sub>, because the JPEG compression will have changed the image. How close B<sub>reloaded</sub> is to B<sub>original</sub> will depend on a variety of factors, partly tied to the image itself, and partly tied to the quality level used when saving the JPEG (the `100` in your code). This quality level ranges from 0 to 100, with 100 meaning highest quality.
If we then compress B<sub>reloaded</sub> to a second JPEG (J<sub>reloaded</sub>), the new JPEG *will not be the same* as the original JPEG (J<sub>original</sub>). Partly, that is because the source bitmap changed, per the previous paragraph. Partly, that is because we might not choose the same quality level as we did with the original compression work.
In your case, you did not create J<sub>original</sub>. You do not necessarily know what quality level was used (that information *might* be stored in the JPEG header; I forget). But because B<sub>reloaded</sub> will be different that the original bitmap (wherever it came from), when you compress the bitmap to J<sub>reloaded</sub>, it is going to be different than J<sub>original</sub>. On the whole, whether it is larger or smaller is difficult to say in the abstract. However, since you are choosing a quality level of 100, and J<sub>original</sub> might well have been compressed with a lower quality level, your compressed image very easily could be larger.
This has nothing to do with Android. This is purely a function of how JPEG works. If you have further questions about JPEG itself, you may wish to [read more about JPEG][1] and ask questions on some site that has something to do with image formats.
[1]: https://en.wikipedia.org/wiki/JPEG
> Does BitmapFactory.decodeFile("path to a JPEG file") decompress the JPEG image when decoding it as a Bitmap in the memory?
Yes.
> And when I use Bitmap.compress(Bitmap.CompressFormat.JPEG, 100, byteArrayOutputStream) on the resulting bitmap from the decoded JPEG file, then the size of the compressed image is more than the size of the original image
That is very possible. With a quality level of 100, I would consider it likely, though perhaps not assured.
> Can anybody exactly explain this phenomenon?
There is no requirement that they be the same for a JPEG. In fact, it will be almost random chance if they *are* the same.
Suppose we start with an in-memory image (B<sub>original</sub>, where B is short for bitmap). We then compress that image to a JPEG (J<sub>original</sub>). JPEG incorporates a lossy compression algorithm, to achieve better compression on real-world images (e.g., photos) by taking into account the fact that human eyes cannot discern small amounts of change.
Suppose we then decode J<sub>original</sub> back into an in-memory bitmap (B<sub>reloaded</sub>). B<sub>reloaded</sub> *will not be the same image* as B<sub>original</sub>, because the JPEG compression will have changed the image. How close B<sub>reloaded</sub> is to B<sub>original</sub> will depend on a variety of factors, partly tied to the image itself, and partly tied to the quality level used when saving the JPEG (the `100` in your code). This quality level ranges from 0 to 100, with 100 meaning highest quality.
If we then compress B<sub>reloaded</sub> to a second JPEG (J<sub>reloaded</sub>), the new JPEG *will not be the same* as the original JPEG (J<sub>original</sub>). Partly, that is because the source bitmap changed, per the previous paragraph. Partly, that is because we might not choose the same quality level as we did with the original compression work.
In your case, you did not create J<sub>original</sub>. You do not necessarily know what quality level was used (that information *might* be stored in the JPEG header; I forget). But because B<sub>reloaded</sub> will be different that the original bitmap (wherever it came from), when you compress the bitmap to J<sub>reloaded</sub>, it is going to be different than J<sub>original</sub>. On the whole, whether it is larger or smaller is difficult to say in the abstract. However, since you are choosing a quality level of 100, and J<sub>original</sub> might well have been compressed with a lower quality level, your compressed image very easily could be larger.
This has nothing to do with Android. This is purely a function of how JPEG works. If you have further questions about JPEG itself, you may wish to [read more about JPEG][1] and ask questions on some site that has something to do with image formats.
[1]: https://en.wikipedia.org/wiki/JPEG
