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!
Related
I have put the jar file inside the library of my magnolia(https://nexus.magnolia-cms.com/#nexus-search;classname~ImagingServlet), but when I invoke the url to return the cropped image, I get an error, if someone can help me.
[this is what appears to me1
I would guess that you are either missing the destinations folder or user has no access to it. Alternatively you are missing imaging support for DAM - see more at various additional jars you might need in documentation.
Also it seems you just copied thumbnail link from the admincentral, so perhaps you might want to read more on using themes and predefined image variations.
Stuck in this weird situation at work. I have .doc files I'm parsing with Node.JS. They have photos in them that are .emf I want to display in my web app. I have no issue getting the emf file out of the word doc, but I can't figure out how to display it on a webpage. Simply embedding as is didn't work. I tried to find a utility to convert them automatically but with no luck. I thought of converting them myself but can't find any tecnhical info on the .emf file.
Any suggestions?
EMF (WMF) are the SVG like formats of the 1990's.
I can't give you the full solution in this space but checkout this thread that uses Apache Batik
If you don't want to build it yourself perhaps try the paid version of converters
If you can't afford I would recommend to host the Batik and make a service endpoint and make calls to generate the desired format from EMF. It may turn out actually faster.
I need to use PDF in a way similar to ZIP/RAR. To hold many images (ancient tibetan buddist literature), ideally 60000. But splitting in 10-100 volumes is OK.
Anything can be used for packing, but for unpacking we need Node.js. Because same PDF file must be served on web. But some users will need to use whole PDF.
So the question is, what node module I can use to read any single arbitrary image from huge PDF? Example would really help.
Every image is a single page. (Or in otherwords every page is single image)
We have been using https://github.com/mirkokiefer/Node-Magick for this....
But the pngs we get out sometimes are fairly low quality..
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.