I have an image stored as a png (I could convert it to bmp too). I want to open it in JavaScript and get the raw RGB bytes. It is enough if this works locally in Chrome. So I open ./index.html in the browser which loads an image in the same directory, e.g. with <img src=myimage.png>. However, I need the proper original data, without any compression or artifacts. I can't use NodeJS.
I saw a similar question, Get image data in JavaScript, but it requires that the image is hosted somewhere. I'm also not sure how to get the raw RGB bytes, the results I got from trying those examples looked like they were still encoded as png.
EDIT: As one of the answers to the other SO question mentions, a canvas will re-encode the data and reading from it won't give me exactly the same values as in the original.
Related
I'm getting one base64 string from API response and other one I'm converted image (which is in test data file) to base64 using cypress readfile method.
When I'm using below command the assertion is failing because there is tracking number difference which will be always new with every call.
And I'm getting 2 different base64.
//This base64 is from API response
var base64FromAPI =
res.body.completedShipments[0].completedPackages[0].documents[0].image;
//Image is picked from Test Data file and converts to base64
cy.readFile(`cypress/e2e/Testdata/Canada Post 02StoreId.pdf`, "base64").should(
"eq",
base64FromAPI
);
Because there is tracking number on the label(image) which will be generated from API response is always different.
Is there any other way to compare base64 strings and to ignore some % of difference while comparing in cypress or javascript.
Or is there any other way to do this.
Thanks in advance.
Essentially you can't do this at the base64 level. The differences in a raw bitstream like base64 are totally meaningless. The differences can only become apparent through rendering that image. Actually, what you need to do is pretty complex! I'm assuming it's not possible or a good idea in your use case to change away from having the server add the text to the image, to for example, using DOM to overlay it instead.
If that's the case, the only thing you could do is utilise visual regression testing. With this, you can set a threshold on which a % similarity is defined.
Since the base64 comes from the API. This would probably mean also having test code that injects an img tag with the base64 as the source, so you can allow the visual snapshot to take place.
This works at the level of image analysis rather than on the actual bitstream. Internally it will render and compare the images.
Another way I can think of, though this is quite complex and I wouldn't pursue it unless the above did not work is to:
Use image manipulation libraries to load the base64 into an actual rendered image in memory.
Try to cut away/crop the superimposed text using image manipulation libraries in order to reliably remove areas of difference.
Base 64 that.
Compare that to a known stable base64 of the "rest" of the image.
I am developing a DAM which is hosted in AWS. The user is able to upload heavy files to the system. Under the hood, when an image is uploaded, there is an AWS Lambda function creating a thumbnail for each image.
Obviously files with format .psd and .eps cannot be displayed on the browser with the typical HTML img item. That is why I will need to convert those file formats to .png or .jpg.
Maybe another solution would be to take a "screenshot on the fly" directly in .png. I do not know if this is possible.
The Node.js code running on the Lambda function is very similar the one here: http://docs.aws.amazon.com/lambda/latest/dg/walkthrough-s3-events-adminuser-create-test-function-create-function.html
Thanks in advance for your help!!
I do not know much about AWS, Lambda and Node.js but can maybe help somewhat with the ImageMagick aspects...
To convert an image from one format to another with ImageMagick, you basically use the convert program with appropriate filename extensions like this in the Terminal, or at the command-line:
convert input.jpg output.png # convert a JPEG to a PNG
EPS files
With EPS, which is a vector format, you generally should set the density first, else ImageMagick will use 72 dpi which makes for horrible quality, so for EPS try something like:
convert -density 144 input.eps output.png
PSD files
With Photoshop PSD files, there is generally a preview image and all the multiple layers following afterwards, so, if you are looking to get a Preview, you should use this style of command to address the layer 0 preview in the PSD file:
convert input.psd[0] output.png
If you want to reduce the size of an image, you would resize it after loading like this:
convert input.png -resize 512x256 output.png
to make it no larger than 512 pixels wide or 256 pixels tall.
Another thing you may like to do is to strip the metadata (time/date, camera model, creating application, GPS position of camera) out of the images, for that, add in -strip just before the output filename.
Not sure what else I can help with, but hope that gets you started.
I'm looking for a way to save/export data in a javascript array to an image (preferably tiff, but any lossless format is fine). The catch is that the resulting image must be at least 16bit (grayscale).
I've looked all over and seen many solutions for array->image (and some for reading high bit-depth images such as tiff.js), but none that write to file and preserve the bit depth that I need.
Any ideas?
I need to alter the palette data in PNG images using JavaScript. I would like to do this without using WebGL and drawing to canvass, since this can be... inefficient, and cause slowdown. However, I'm not experienced with working with data compression and I know PNGs use compression.
I have three questions. One, do I need to fully decompress the image, or is it possible to only decompress parts up to the PLTE chunk(s) then re-compress the image?
Two, can JavaScript even work with raw binary data, or will I need to get really creative with base64 and string manipulation?
Third, since I'm working with palette and not truecolor images and so don't need to handle IDAT chunks... are the previous chunks actually compressed? Is this going to even require me to decompress the image?
I need to download a BMP with JavaScript and render it to the screen, in Internet Explorer. First off, yes, I know this is insane, I'm not going to get into why, let's just accept for a moment that img src is not working because of security constraints, but an ajax request with the proper authentication in the post will pull back the image. This example bypasses all the security for the sake of simplicity and just proves we can render something.
The best idea I could come up with was to fetch the stream via ajax, decode the bitmap, and then render it with canvas. Internet Explorer obviously doesn't support canvas, but luckily Google provided a wrapper to SVG called excanvas that I can use for that.
My code (drawing code appears to work, bmp decoding not so much)
http://gist.github.com/614328
Future support for other images besides BMP is plausable, and because of how the canvas works it's easiest to draw pixels in RGBA. Texture2D is essentially the wrapper class for an RGBA byte array, plus the drawing code. ByteStream makes it a bit easier on the eyes dealing with the byte array, and BitmapDecoder contains the method to translate the BGR format to RGBA texture2d for drawing.
Is it possible the bytes are getting mis-translated along the way or is there something the matter with my decoding logic?
FYI, I got the file spec from wikipedia:
http://en.wikipedia.org/wiki/BMP_file_format#Bitmap_Information_.28DIB_header.29
Any idea what's going on in the decoding logic or drawing logic that's causing my BMP to draw incorrectly?
XMLHttpRequest (aka AJAX) was primarily designed for text content, so it's possible that binary data (especially null characters) aren't translated correctly. The first check would be to compare the size of retrieved data with the actual file size.
At least on Firefox, there seems to be a way to specifically retrieve binary data, as described here: Handling binary data.
Here's a much easier (and vastly more performant) approach: base64 encode the BMP data (you can do this either on the server or the client) and then embed it in the page using a data URI:
<script type="text/javascript">
function fetchBmp() {
$.get('http://localhost:3168/experimental/imgrender/beta.bmp', function (data) {
var base64Data = $.base64.encode(data); // *
$('#my-image').attr('src', 'data:image/bmp;base64,' + base64Data);
});
}
// * Lots of plugins for this, e.g. http://github.com/carlo/jquery-base64
</script>
<img id="my-image" />
All modern browsers support data URIs (including IE8 and up--for IE7 workarounds exist) as well as the BMP format.
As casablanca points out, there may be issues with loading binary data via Ajax, so you may have to google around for workarounds.
The fix was a combination of two things
a bit of VBScript to read the raw bytes of responseBody
decoding the byte data properly, each pixel is not padded as the wikipedia article suggests, it's actually each scanline that is padded to dword size.
Working code:
http://gist.github.com/616240