Tell us which versions you are using:
iOS 11.3
RNICP should write universally valid JPEG files to temporary storage at path image.path when user selects HEIC image(s) from camera roll regardless of whether compressImageQuality is set.
When a HEIC image is selected on a real device in multi-picker, the temporary file written to image.path is partially corrupt unless compressImageQuality is set. Images written to image.path without compressImageQuality setting are reported as invalid by my image-processing pipeline, which uses Sharp. Further, these images cannot be displayed in a browser using an image tag (although they can be downloaded and viewed in a standalone image viewer--preview in my case). This does not occur if the image is captured by RNICP's camera. Adding compressImageQuality to the ImagePicker.openPicker options cures the problem.
I'm not sure when this bug was introduced or how, but I was updating a currently deployed app that uses RNICP without specifying the compressImageQuality setting and have not run into this issue previously.
Select HEIC image from iPhone running iOS 11.3 using ImagePicker.openPicker({ multiple: true, includeExif: true }).
Upload jpg file at image.path to S3 using a signed URL with XHR specifying image/jpeg as the content type.
Attempt to view image in browser and/or run any sort of post-processing on the image.
Pull hair out for ~6 hours.

// stacktrace or any other useful debug info
Error: Input buffer contains unsupported image format
Love react-native-image-crop-picker? Please consider supporting our collective:
馃憠 https://opencollective.com/react-native-image-crop-picker/donate
do you have some time to send a pull request?
I will certainly give it the old college try; however, I鈥檓 no Native coder. That said, I鈥檝e always wanted to learn more. So, will try and figure it out this weekend.
I have this problem too, I think it's actually just the original heic file that gets written with a .jpg extension.
I might be able to help with this. I was wondering though if there is a case to be made for keeping images in their original HEIC format when no modification (cropping, resizing, compression etc.) is desired. On the contrary though I agree that this lib should provide a consistent interface and always spit out jpegs. What are your thoughts on this? @ivpusic
Thinking about this a bit further, I think it would make sense to always convert to jpeg if the image is neither jpg, png, gif, or tiff. The current behaviour is that these file types are not converted to jpg but stay in their original format if no image modifications are desired, and I think it should stay like that (think screen shots or images saved to the library from websites). If you all agree I'll look at getting this fixed.
@fubar sounds good
It is the same problem with #681 ?
Is it OK, if you select one file?
Looking forward to hopefully a resolution to this via PR ^
In the time-being though, "Adding compressImageQuality to the ImagePicker.openPicker options cures the problem." As mentioned in the initial issue is a solid workaround for my use case.
Same problem with HEIC images without the compressImageQuality option set
Most helpful comment
Thinking about this a bit further, I think it would make sense to always convert to jpeg if the image is neither jpg, png, gif, or tiff. The current behaviour is that these file types are not converted to jpg but stay in their original format if no image modifications are desired, and I think it should stay like that (think screen shots or images saved to the library from websites). If you all agree I'll look at getting this fixed.