What is a 16 bits-per-pixel component?
Each "channel" (e.g. Red, Green, Blue) can have a value between 0x0000 (no color), and 0xFFFF (full color). This allows greater depth of color, and more precision calculations.
For example. A "RED" pixel displayed with QuantumDepth of 8...
$ convert -size 1x1 xc:red -depth 8 rgb:- | hexdump
0000000 ff 00 00
0000003
Same for QuantumDepth go 16 ...
$ convert -size 1x1 xc:red -depth 16 rgb:- | hexdump
0000000 ff ff 00 00 00 00
0000006
And for Q32..? You guessed it.
$ convert -size 1x1 xc:red -depth 32 rgb:- | hexdump
0000000 ff ff ff ff 00 00 00 00 00 00 00 00
000000c
All-n-all, more memory is allocated to represent a color value. It gets a little more complex with HDRI imaging.
does jpeg image support 16 bits-per-pixel component ? does picture we take from camera in smartphone are in 8 bits-per-pixel component or 16 bits-per-pixel component ?
I believe JPEG's are 8bit, but I can be wrong here. I do know that most photographers KEEP all RAW files from device because JPEG doesn't support all the detail captured by the camera sensor. Here's a great write-up with examples.
I just need to load jpg images, crop/resize them and save. I also need to save the pictures in 2 different variants: one with the icc color profile management included and another without any icc profile (sRGB)
ImageMagick was designed to be "Swiss-Army-Knife" of encoders & decoders (+ a large amount of features). When reading a file, it decodes the format into something called "Authenticate Pixels" to be managed internally. The default size of the internal storage can be configured at time of compile, and for convenience the pre-build binaries are offered as Q8, Q16, and Q32. Plus additional HDRI support.
If your focused on quality, Q16 is a safe option. Q8 will be way faster, but limiting at times.