The image is given as Base64 encoded string, I had decode and pass to BitmapFactory class, then I got a log saying skia returned false. I did the fix by using FilterInputStream still its failing. So to identify the issue with image decoding part, I did the hexdump and compare with iOS one, it was identical. So now I'm sure that issue with BitmapFactory class. One thing I noticed that, when I put the binary output to a file and copy to Mac, clicking on the file I could see the image. So I was trying to figure out, what is the different between the Image Decoder in Android and iOS.
Related
My Linux gcc program is generating an image as a two dimensional array of pixel data, that I want to print out through CUPS.
The available CUPS_FORMAT_??? is very dicouraging. Tried CUPS_FORMAT_AUTO and send the image as TIFF, it failed. The TIFF data is verified by making perfectly viewable .TIF of it. Making JPEG is far too complicated, but can CUPS_FORMAT_RAW be used? I fails to find a spec of what to feed the cupsWriteRequestData() with using this format. All searches ends up with priner side stuff, nothing about client API. Any help, please?
I've run into an issue where there are a collection of .dds(direct draw surface) files which I need to be able to display within an electron/react app. From what I know, a .dds file must be converted to a png/jpeg before being able to be rendered in an img tag. This must also be done completely in memory as I don't want to create additional files.
Here is what I've tried.
Preview-DDS: https://github.com/Jam3/preview-dds
DDS-Parser: https://github.com/Jam3/parse-dds
I noticed Preview-DDS has an option to convert .dds to .png yet I had no luck replicating it in memory. This isn't a subject im really knowledgable on so I'm hoping someone can get me pointed in the right direction!
I'm building a project where people can upload files, I would like to then display those files in a browser where people can interact with them (vote, comment etc)
However, this means I need to programatically build the html depending on the format of the video or image. Is there a way to feed a file (or filename) into a library, and determine whether I need to display it in a video element or an image element? Even a list of video formats vs image formats would help but I haven't seen anything in regards to that.
No module can reliably determine the file type. The user could either change the extension or even the magic number of the file to obfuscate it. The only reliable way it to try to pass file to some image / video transcoder to let it decide or error out if the format is invalid. This way you know you are working with known formats since all files are transcoded to your specific extensions. That could be mp4 or png. I recommend using handbrake for videos and sharp for images. Leaving the NPM links down below:
https://www.npmjs.com/package/handbrake-js
https://www.npmjs.com/package/sharp
I have a nodejs server that receives images encoded in base64 through a websocket. I would like to do some image manipulation on those images and send them back. I searched a little bit on the net to find some library to help me doing this, but all I could find were libraries that take images stored somewhere in the server side, do the manipulation and save back the image. Apparently all of them take as input a string containing the filename of the image, so I guess under the hood they are fetching the image manually through a file stream.
My question is, is there a library that may help me working directly on base64 data (that is, passing the data as input to the functions) or should I save every time the image on the server, modify it and send it back? I would rather not go with the latter because I'm working on some high-performance application, and all this saving/loading looks a waste of cycles. Otherwise, do you see some other way I could achieve this (that is, getting the image file without saving and loading it back, for example)?
Thanks.
Work with Buffers.
var img = new Buffer(img_string, 'base64');
// Work with your images like other tutorials do.
This one can work with "readable streams": https://github.com/aheckmann/gm
See the second set of examples in the readme.
Imagine an environment in which users can upload images to a website by either uploading it from their pc or referring to a remote url.
As part of some security checks I'd like to make sure that the referenced object is indeed an image.
In the case of a remote-url, I of course check the content-type, but this isn't bullet-proof.
I figured I could use ImageMagick to do the task. Perhaps executing the ImageMagick.identify() method and if no error is returned and returned type is either JPG|GIF|,etc. the content is an image. (In a quick check I noticed that TXT files are identified correctly as well, so I have to blacklist these)
Is there any better way in doing this?
You could probably simply load the image via ImageMagick's appropriate function for your language of choice. If the image isn't formatted properly (in terms of internal formatting, not its aesthetic properties, that is), I would expect ImageMagick to refuse to load it and report an error. In PHP, for example, readImage returns false if the image fails to load.
Alternatively, you could read the first few hundred bytes of the file and determine if the expected image file format headers are present; e.g., "GIF89" etc.
These checks may backfire, if your image is in a compressable format (PNG, GIF) and it is constructed in a way similar to a zip bomb https://en.wikipedia.org/wiki/Zip_bomb
Some examples at ftp://ftp.aerasec.de/pub/advisories/decompressionbombs/pictures/ (nothing special about that site, I just googled decompression bombs)
Another related issue is that formats like SVG are in fact XML and some image processing tools are prone to a variant of "billion laughs" attack https://en.wikipedia.org/wiki/Billion_laughs
You should not store the original file. The generally recommended approach is to always re-process the image and convert it to an entirely new file. There have been vulnerabilites exploited inside valid image files (see GIFAR), so checking for this would have been useless.
Never expose your visitors to an image file that you have not written out yourself and for which you did not choose the file name yourself.