I'm using a simple PHP script to recognize handwritings in death certificates. With words it works quite well, but with numbers no.
The result I get with my simple PHP code with DOCUMENT_TEXT_DETECTION, is the same as with the "Try it!" Google demo page.
This is an example of the result:
enter image description here
And this is the piece of PHP test code:
require "/var/www/vendor/autoload.php";
use Google\Cloud\Vision\VisionClient;
$vision = new VisionClient(['keyFile'=>json_decode(file_get_contents("*******.json"),true)]);
$image = fopen($imageName,'r');
$imageProcessed = $vision->image($image ,['DOCUMENT_TEXT_DETECTION']);
$result = $vision->annotate($imageProcessed);
As you can see from the result image, it's seems that it rotates the image of 180° so that "08 01 1929" (birth date in "dd mm yyyy" format) rotated resemble "616r r0 80". 9 becames 6, 2 becomes 1, and 1 becomes r.
How can I fix the problem? Can I hint the algorithm from the code that these are numbers and to not rotate the image?
Thank you in advance!
Valerio
Related
I need to upload images and get Exif to display.
I'm using exif_read_data to get exifs data.
$data = exif_read_data($imageFile, 'EXIF', true);
Everything is fine, but :
$data['EXIF']['ExposureProgram'] = 3
I know Exposure Programm could be :
aperture priority
shutter priority
auto
manuel
I don't find any information about this number and what is its meaning.
Maybe someone can help me here ?
Thanks
Why not checking Exif's Standard 2.32 itself? Page 50:
0 = Not defined
1 = Manual
2 = Normal program
3 = Aperture priority
4 = Shutter priority
5 = Creative program (biased toward depth of field)
6 = Action program (biased toward fast shutter speed)
7 = Portrait mode (for closeup photos with the background out of focus)
8 = Landscape mode (for landscape photos with the background in focus)
Other = reserved
Phil Harvey's ExifTool reference is also worth to check for additional improper values from vendors violating the standard(s):
(the value of 9 is not standard EXIF, but is used by the Canon EOS 7D)
9 = Bulb
well, I have a very strange problem generating 2D-Barcodes (PDF417) with PHP using TCPDF (TCPDF-Website). This is my small code:
<?php
require_once ("tcpdf/tcpdf_barcodes_2d.php");
$type = "PDF417";
$code="123456789012";
$barcodeobj = new TCPDF2DBarcode($code, $type);
$barcodeobj->getBarcodePNG();
?>
This code works well and generates the barcode. But when I change the line with the code in
$code="1234567890123";
it does not generate any output. I tried several strings and found out, that everytime I try to use a string with more than 12 digits following one after the other I get no output. It does not depend on which position the digits were.
For example:
$code="abcdefghijklmnopqrstuvwxyz123456789012abcdefghijklmnopqrstuvwxyz";
works finde, but
$code="abcdefghijklmnopqrstuvwxyz1234567890123abcdefghijklmnopqrstuvwxyz";
fails.
I use tcpdf 6.0.037 and also tried to download it from annother source. I even tried Version 6.0.020 - no change.
Server is openSuSE 12.2 64bit , PHP 5.3.15
Edit:
It's getting really strange: I tried annother barcode generator - and I get the same error. This one provides a online demo. When I fill in 1234567890123 online, I get the appropreate barcode. But on my own server the same string does not work.
"123456-7890123" works
"1234567890123" does not work
"123456789012" works
"12e34567890123" works
"123456789012sometext123456789012" works
"123456789012sometext1234567890123" does not work
Every string with more than 12 numbers in a row does not work - no matter how long the string is.
U see what I mean with "strange" ?
Any help would be highly appreciated.
I too had this problem. We are using PDF417 & QR Code barcodes. I have not found a great solution for this, but I have found a solution that works for now. If anyone has a better solution, please advise.
Problem:
In our barcodes we have phone numbers that are stored and sometimes they are 13 digits or longer. The 13 digit phone number was causing the barcode to not print correctly.
Solution:
Since the barcode would not print due to this we just add a space every 10 digits and this keeps the barcode intact and our software can read in the phone number without spaces so we should be A-OK!
Example Phone Number:
123456789012345 (15 digits)
PHP Code to run on phone number:
$phone = chunk_split($phone, 10, ' ');
Example Phone Number after split:
1234567890 12345
The libraries for these barcodes (Google/TCPDF) don't like numbers longer than 12 so it's definitely strange, but maybe I"m missing something easy to see.
Thanks and hope this helps someone.
I've been bashing my head agains something simple..
// ....all prev code is fine....
$pasteboard =imagecreatetruecolor($imgs['bg']["width"],$imgs['bg']["height"]);
imagealphablending($pasteboard, false);
imagecopyresampled($pasteboard, $imgs['bg']["img"],0,0,0,0,$imgs['bg']["width"],$imgs['bg']["width"],imagesx($imgs['bg']["img"]),imagesy($imgs['bg']["img"]));
imagecopyresampled($pasteboard, $imgs['photo']["img"],20,20,0,0,$imgs['photo']["width"],$imgs['photo']["width"],imagesx($imgs['photo']["img"]),imagesy($imgs['photo']["img"]));
imagesavealpha($pasteboard,true);
//send it out
$out = $pasteboard;
header('Content-type: image/png');
imagepng($out);
//then garbage collection
gives me this:
HORAY!
perfect alpha png composite...
Now I want to rotate it, so instead of the $out=$pasteboard i do this:
imagesavealpha($pasteboard,true);
//rotate it
$out = imagerotate($pasteboard,5,imagecolorexactalpha($pasteboard,255,255,255,50),0);
header('Content-type: image/png');
imagepng($out);
which sadly gives me this:
BOOOO!
Ive tried setting the color like:
imagerotate($pasteboard,5,0x00000000,0);
also the last attr like:
imagerotate($pasteboard,5,0x00000000,1);
new empty images sampled etc etc...
no dice....
Can anyone help?
I'm answering my question simply because I've tried 10-15 suggestions i've seen allover the web all of which offering 'nearly' right solutions but nothing exact, Also I've seen this question posted a few places now, and hopefully if anyone reaches this page in future it would be best to show the solution as the direct answer.
MASSIVE thanks to #cristobal for the help and efforts, if I could vote you up any more I would !
The knack seems to be:
//rotate it
$pasteboard = imagerotate($pasteboard,5,0XFFFFFF00,0); //<-- here must be RRGGBBAA, also last attr set to 0
imagesavealpha($pasteboard, true); // <-- then to save it... dont ask me why..
//send it out
header('Content-type: image/png');
imagepng($pasteboard);
produces this (it has a perfect alpha even though you cant see against the white page):
REALLY not the most fun 5 hrs of my life... hopefully it will stop someone else going through the same pain..
Using the same code above and using a blue color for the third parameter in the imagerotate operation, which will be it used to fill the uncovered zone after the rotation i.e.:
imagerotate($pasteboard, 5, 255);
We get the following image
we see the blue area is the uncovered zone which it fills, while the black color is the to be the border shadow from the image which GD does not seem to handle well along the interpolation used in the rotation.
The same image rotated using the convert for imagemagick. commmand i.e. $> convert -rotate 5 image.png image_rotated.png results in the image below
Clearly GD does not handle alpha colors well when rotating.
If you have access to use the convert commmand using exec or process, you should pipe those image operation to imagemagick instead. GD is a simple image library which has not been updated much the latest years. Otherwise try Imagemagick, Cairo or Gmagick which there are pecl plugins for too http://php.net/manual/en/book.image.php.
Last resort somebody made a function that which uses GD http://www.exorithm.com/algorithm/view/rotate_image_alpha for what you are looking after but the result is not pretty since its a simple linear interpolation:
taken from How to rotate an image in GD Image Library while keeping transparency?. Perhaps if you convert the linear interpolation function to a Bicubic or Quad it will look better.
Note these answers did not work for me but this did.
$destimg = imagecreatefromjpeg("image.png");
$rotatedImage = imagerotate($destimg, 200, 0);
imagesavealpha($rotatedImage, true);
imagepng($rotatedImage,"rotated.png");
I am parsing a XML file supplied by some software. Part of the parsing is extracting colors from some attributes. The problem I have is the color is a 12digit hex value. ie,
<Text AdornmentStyle="0" Background="#FFFFFFFFFFFF" Color="#DD6B08C206A2" Font="Courier Final Draft" RevisionID="0" Size="12" Style="">Test</Text>
As you can see the colors are 12digits long. I need to get the 6 digit color so I can display it correctly on html.
Has anyone come across this before?
Hope you can advise.
Never seen a 12-digit hex color string before. Must be using 2-bytes per channel, which means if you convert it, you're going to lose a bit of information.
I believe the color is in the format #RRRRGGGGBBBB, so take each 4 hexgits and divide by (16^4/16^2)=256, and round if necessary. That should do it.
...and if that doesn't give you the right color, try CMYK like cypher suggests: #CCCMMMYYYKKK (12-bits per channel).
e.g., to convert DD6B08C206A2 do:
0xDD6B / 0x100 = 0xDD
0x08C2 / 0x100 = 0x08
0x06A2 / 0x100 = 0x06
Put those back together and you get #DD0806.
PHP and GD seem to have trouble creating images from PNGs of type greyscale with alpha when using imagecreatefrompng(). The results are incredibly distorted.
I was wondering if anyone knew of a way to test for the colour type in order to notify the user of the incompatibility?
Example:
Original Image: http://dl.dropbox.com/u/246391/Robin.png
Resulting Image: http://dl.dropbox.com/u/246391/Robin_result.png
Code:
<?php
$resource = imagecreatefrompng('./Robin.png');
header('Content-type: image/png');
imagepng($resource);
imagedestroy($resource);
Cheers,
Aron
The colour type of a PNG image is stored at byte offset 25 in the file (counting from 0). So if you can get hold of the actual bytes of the PNG file, simply look at byte 25 (I don't do PHP, so I don't know how to do that):
0 - greyscale
2 - RGB
3 - RGB with palette
4 - greyscale + alpha
6 - RGB + alpha
The preceding byte (offset 24) gives the number of bits per channel. See the PNG spec for more details.
In a slight twist a PNG file may have "1-bit alpha" (like GIFs) by having a tRNS chunk (when it is colour type 0 2 or 3).
i landed here today searching for a way to tell (via php) if a specific .png image is an alpha-png one -
David Jones' answer points to the right direction, really easy to implement in php:
file_get_contents to load just that 25' byte (there it is, indeed!), and
ord() to get its ASCII value, to test it (against '6' in my case)
if(ord(file_get_contents($alpha_png_candidate, NULL, NULL, 25, 1)) == 6) {
is_alpha_png_so_do_something();
}
actually i needed that for assuring backward compatibility with ie6
within cms-user-generated-pages, to replace all alpha-png < img > tags with inline-block < spans > - the alpha-png file will then be served as variable for the ms-proprietary css property filter
.alpha_png_span{
filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(
src='$alpha_png_candidate', sizingMethod='crop')
}
...and it all works, so thanks!
paolo
see this answer
:
Another usefull note for those using ImageCreateFromPng:
PHP and GD do not recognize grayscale/alpha images.
So if you use grayscale images with transparency between 0% and 100%, then save the image as RGB.
At least this is true for PHP Version 4.4.2-1 and in 5.1.2-1 with pictures made with GIMP 2.2.8.
url :
http://php.net/manual/en/function.imagecreatefrompng.php