I am looking for a way in which it is possible to extract the left side of the image (the non ascii characters) here, reliably, using OCR. I have a number of images in a similar format, also showing hex data, that i would like to extract.
Would anyone be able to reccomend a way to extract the text from these images?
Ideally, the output for first line would be :
0005C850 00 00 00 00 etc.
and output for fourth line would be something like:
0005C8AA ED 93 A7 8E etc.
A legendary program has been written that does this. - https://github.com/eighttails/ProgramListOCR . For Windows systems, i ran on a VM.
Was hard to find.
First you want to convert your image to 400% of the size:
convert -resize 400% source.png source.png
Make it grayscale:
convert source.png -colorspace Gray destination.png
Change it into a tiff file:
convert destination.png destination.tiff
You then process it using this software.
Related
I have read most of the questions here, here,bug and others.
One difference is that all the posts talks about the external image being read.
However i am creating the jpg image from ImageIO library itself and i am writing that image to a file and reading the same image file however there is difference in pixel value.
here's my code:
BufferedImage j = new BufferedImage(100,100,BufferedImage.TYPE_INT_RGB);
Graphics2D jg = j.createGraphics();
jg.setColor(Color.GREEN);
jg.fillRect(0, 0, 100, 100);
jg.dispose();
File gr = new File("d:/pics/green.jpeg");
ImageIO.write(j,"jpeg",gr);
BufferedImage grbr = ImageIO.read(gr);
System.out.format("expected:%s\tactual::%s\n", j.getRGB(40,40), grbr.getRGB(40,40));
System.out.format("expectedG:%s\tactualG::%s", Color.GREEN.getRGB(), grbr.getRGB(40,40));
Output:
expected:-16711936 actual::-16711935
expectedG:-16711936 actualG::-16711935
I read this excerpt from the questions i saw for help as below
All other image loaders assume that the data is YCbCr in that case,
except for ImageIO, which assumes that it is RGB when channels 1 and 2
are not subsampled. So, check whether the first 4 bytes are FF D8 FF
E1, and if so, whether channels 1 and 2 are subsampled
I read the first few bytes of the green.jpeg after it is written to the file like this as below
FF D8 FF E0 00 10 4A 46 49 46 00
I read about JFIF on wikipedia and found that above sequence is not according to what is mentioned as here. However this is not applicable here because i created a simple RGB type image and not YCbCr type.
So why simple image creating and reading in ImageIO is giving different results? Thanks in advance.
The gamuts of the RGB and YCbCr colorspaces are different. That's your first change of having changes. There are various steps in the JPEG process that can introduce rounding errors. The quantization process in JPEG changes values.
You're comparison shows very slight changes that are normal with JPEG.
I have bunch of .png files from the asset folder of an android game.I derived all assets from the .obb file. Every other file can be opened. But any of these .png files seem not to opened. I tried many of the concerning programs; Illustrator, Photoshop, GIMP, Paint and some online file viewers. But none of them could do.
Then I checked the hex code of the files and realized that those files do not start with usual png header which is89 50 4E 47 0D 0A 1A 0A But all ended with 49 45 4E 44 AE 42 60 82 which belongs to png format.
Checked .PNG Signature Here
So I tried to add png header to the files and then saved them. I had no idea if it was gonna work, just tried. Still I was not able to open those files.
So is there a way to open these files as images or can they be just some kind of data formatted as .png and not intended to using as images?
If it is about adding hex header, how should I do it?
First Page of Hex Code
Thanks.
The hex code shows about 500 bytes of garbage followed by a valid PNG tRNS chunk. So apparently something has overwritten the beginning of the PNG files. It would be possible, but a lot of work, to create the proper IHDR, PLTE, and possibly other chunks that are missing. The information needed to do that is not contained in your file so you'd need to find that out elsewhere or by experimenting.
The fact that it has a 64-byte tRNS chunk tells you that the PNG colortype has to be 3 (indexed) and that the bit depth has to be 8, and suggests that there are only 64 different colors present. The palette contents are anyone's guess, so you could put in a simple 64-entry grayscale palette; this would make the image visible but without the proper colors.
A while ago I saved some images generated by a web service so the file names are e.g 'ysauyft87ggsa67fgeg&w=1600'. I can open and manipulate these images OK, I'd just like to know what encoding they are (it's almost certainly png or jpeg). I've tried 'get info' in OSX, but it thinks the files are just text (even though it generates thumbnails correctly and I can view the images in preview). If I serve the images on a server they are delivered as 'application/octet-stream'.
How can I easily determine whether they are png or jpeg via the shell?
The "magic code" for a
PNG file should begin with 89 50 4E 47 0D 0A 1A 0A
JPEG files begin with FFD8 and end with FFD9
Three methods:
Open a file in a Hex editor (or just a binary file viewer). PNG files start with 'PNG', .jpg files should have 'exif'or 'JFIF' somewhere in the beginning.
Use file command: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/file.1.html
For example: file 'ysauyft87ggsa67fgeg&w=1600'
Use identify file like torazaburo wrote in the comments (part of imagemagick lib)
I'd like to make a script where I could put an image file(in indexed mode) as input then the return will be one image (in rgb mode).
It is like something gimp does in the interactive mode when you you click on Image -> Mode then click on rgb (http://docs.gimp.org/en/images/tutorials/quickie-mode-menu.png), I want to do the same thing but in the linux terminal (or in python) with a lot of images every day.
Any tips?
Thanks in Advance, sorry for the bad english.
This would be done easier/faster with ImageMagick.
Then you would be able to run the following command from your shell:
$ convert cmyk_image.jpg -colorspace rgb rgb_image.jpg
A guide/reference is available at the ImageMagick project wiki.
I tried :
$ convert indexed_image.tif -colorspace rgb rgb_image.tif
This is TIFF with an indexed table RGB, but the result colors are slightly different (darker and more intense).
E.g. table entry 58 which is 192 248 200 (light green) transforms into 134 239 147 (darker green).
I am having a bit of trouble getting Gravatars to work properly:
When I request the following:
http://gravatar.com/avatar/8a17d0d0d8bdf6a8d527bbc943a17cf8.jpg?s=64&d=identicon
Firefox proudly displays the following:
http://files.quickmediasolutions.com/gravatar_p.png
...indicating that the file is a PNG image.
This confuses me - I thought Gravatars were JPEG images. It seems like they can be either. How can I find out if a given image is PNG or JPEG preferably without downloading it first?
Note: Some people are reporting that Gravatar only returns PNG images. Please explain this:
http://files.quickmediasolutions.com/gravatar_p2.png
http://gravatar.com/avatar/03cd042b82ac85b2c5fe0757a94e0413?s=64&d=identicon
If Gravatar icons have accurate MIME types assigned by the server you're accessing them from, just check that. It should be image/jpeg for JPEGs and image/png for PNGs.
Failing that...
http://en.wikipedia.org/wiki/Portable_Network_Graphics#File_header
A PNG file starts with an 8-byte signature. The hexadecimal byte values are 89 50 4E 47 0D 0A 1A 0A; the decimal values are 137 80 78 71 13 10 26 10.
So just check the eight bytes at the beginning of the file; if it's a PNG, it'll have the stated values in those bytes, and if not, it won't. Just download the file, possibly store it somewhere temporarily (which shouldn't be too hard considering it shouldn't be too big), and process it differently depending on what the header contains. You can always change the file extension and then use PHP's graphics library if you saved it as the wrong type at first. (Or are you not allowed to do that?)
As a side note, my favorite bit about the PNG header:
50 4E 47 In ASCII, the letters PNG, allowing a person to identify the format easily if it is viewed in a text editor.
The end tag is JPG, but the string is interpreted by the server and the corresponding image is sent. In this case a PNG.