I am trying to create a Security Image from a text using the perl module GD:SecurityImage with the following object:
my $image = GD::SecurityImage->new(
width => 220,
height => 60,
lines => 5,
scramble => 1,
angle => 45,
gd_font => 'giant',
);
$image->create( normal => 'circle' );
$image->particle(30, 70);
But the text in resulted image doesn't have the text angled at 45 Degrees rather its random.
Also if i make scramble = 0 and have angle = 45, the text doesn't rotate at that angle, text is just default in the image as seen in the attach screen.
Please help me out, what am i doing wrong here?.
NOTE: Image is with scramble = 0;
Please note that you must have Math::Trig to rotate with GD, otherwise you get no rotation. You don't need that with the ImageMagick backend - try that. (And use TTF :))
Related
Trying to figure out the image crop aspect ratio attribute, but can't make it working.
The code isL
protected function addUserFields()
{
$this->crud->addFields([
[
'name' => 'profile_image', // The db column name
'label' => trans('Profile image'), // Table column heading
'type' => 'image',
'upload' => true,
'crop' => true,
'aspect-ratio' => 1,
]);
}
It’s probably because you’re using a dash instead of underscore. It should be:
'aspect_ratio' => 1, // omit or set to 0 to allow any aspect ratio
Please also note what the docs say:
The value for aspect_ratio is a float that represents the ratio of the cropping rectangle height and width. By way of example,
Square = 1
Landscape = 2
Portrait = 0.5
And you can, of course, use any value for more extreme rectangles.
With Paperjs, I try to subtract a path from a circle, but it is not working as expected. Here is my code:
// Create circle
var c1 = new Path.Circle(new Point(100, 70), 50);
c1.fillColor = 'red';
// Create path
var eraser = new paper.Path({strokeColor: 'black', strokeWidth: 20, strokeCap: 'round'});
eraser.add(new paper.Point(20, 20));
eraser.add(new paper.Point(100, 80));
eraser.add(new paper.Point(150, 150));
eraser.fillColor = 'white';
eraser.opacity = 0.6;
// Subtract
result = c1.subtract(eraser);
result.selected = true;
result.opacity = 0.8;
result.fillColor = 'pink';
It seems the path is seen as a polygone, not lines when subtracted:
Here is a jsFiddle : https://jsfiddle.net/Imabot/785ergpy/35/
Yes, this is because Paper.js do the boolean operation with the paths fill geometry, ignoring the stroke.
This is more obvious if you remove the stroke from your example (see this sketch).
What you need to do, if you want to subtract the stroke, is turning it into a path first.
Unfortunately, Paper.js doesn't have this feature yet, even if it's planned for a long time and exist as an experimental version (see this issue).
So you have to either use this experimental feature or use a vectorial drawing software like Adobe Illustrator, and export your stroke path as SVG for example, before using it with Paper.js.
I have a sprite for a png file. ( Dimensions of the png file is 432x10 ). The png file is in drawable-xxhdpi folder. When i run on emulator with hdpi density mySprite.getWidth() returns 432. ( mySprite.getWidthScaled() also returns 432.) But the png file is looked just about 200 pixel width. Which method gives right value. ( not the width of the png file.) The value that how many pixel the png file is monitorized in? Thank you very much.
Note : My English is insufficient, sorry.
`public Engine onLoadEngine () {
....
SCR_WIDTH = getResources().getDisplayMetrics().widthPixels;
SCR_HEIGHT = getResources().getDisplayMetrics().heightPixels;
MyCamera = new Camera (0, 0, SCR_WIDTH, SCR_HEIGHT);
......
}`
I'm using the perl module PDF::API2::Annotation to add annotations to my pdf files.
There is support to decide where the annot will be created using a rect. Something like this:
$annot->text( $text, -rect => [ 10, 10, 10, 10 ] );
which works fine, but I'm having problem to be accurate on where to put my annotations.
I know the lower left corner of the pdf is (0,0). Let's say i want to put an annotation exactly in the middle of the page, any idea how can i achieve that?
according to this https://www.leadtools.com/help/leadtools/v18/dh/to/leadtools.topics.pdf~pdf.topics.pdfcoordinatesystem.html
a pdf is divided to points, and each point is 1/72 inch. and a pdf size is so the middle should be
(306,396)
But thats not even close to the middle.
You can get the size of the page media box and then calculate the middle from that:
# get the mediabox
my ($llx, $lly, $urx, $ury) = $page->get_mediabox;
# print out the page coordinates
say "page mediabox: " . join ", ", $llx, $lly, $urx, $ury;
# output: 0, 0, 612, 792 for the strangely-shaped page I created
# calculate the midpoints
my $midx = $urx/2;
my $midy = $ury/2;
my $annot = $page->annotation;
# create an annotation 20 pts wide and high around the midpoint of the mediabox
$annot->text($text, -rect=>[$midx-10,$midy-10,$midx+10,$midy+10]);
As well as the media box, you can also get the page crop box, trim box, bleed box, and art box:
for my $box ('mediabox', 'cropbox', 'trimbox', 'artbox', 'bleedbox') {
my $get = "get_$box";
say "$box dimensions: " . join ", ", $page->$get;
}
These are usually all the same unless the document has been set up for professional printing with a bleed area, etc.
Suppose I want to take one picture, move all of its pixels one pixel to the right and one to the left, and save it. I tried this code:
my $image_file = "a.jpg";
my $im = GD::Image->newFromJpeg($image_file);
my ($width, $height) = $im->getBounds();
my $outim = new GD::Image($width, $height);
foreach my $x (1..$width)
{
foreach my $y (1..$height)
{
my $index = $im->getPixel($x-1,$y-1);
my ($r,$g,$b) = $im->rgb($index);
my $color = $outim->colorAllocate($r,$g,$b);
$outim->setPixel($x,$y,$color);
}
}
%printing the picture...
That doesn't do the trick; it draws all pixels, except those in which x=0 or y=0, in one color. Where am I going wrong?
Look in the docs:
Images created by reading JPEG images will always be truecolor. To
force the image to be palette-based, pass a value of 0 in the optional
$truecolor argument.
It's not indexed. Try adding a ,0 to your newFromJpeg call.
From the comments, it seems your next problem is the number of colors to allocate. By default, the indexed image is 8-bit, meaning a maximum number of 256 unique colors (2^8=256). The "simple" workaround is of course to use a truecolor image instead, but that depends on whether you can accept truecolor output.
If not, your next challenge will be to come up with "an optimal" set of 256 colors that will minimize the visible defects in the image itself (see http://en.wikipedia.org/wiki/Color_quantization). That used to be a whole topic in itself that we seldom have to worry about today. If you still have to worry about it, you are probably better off offloading that job to some specialized tool like Imagemagik or similar, rather than try to implement it yourself. Unless you like challenges of course.
Here's a solution using Imager because it's a very nice module and I'm more familiar with it, and it handles image transformations nicely.
use Imager;
my $image_file = "a.jpg";
my $src = Imager->new(file => $image_file) or die Imager->errstr;
my $dest = Imager->new(
xsize => $src->getwidth() + 1,
ysize => $src->getheight() + 1,
channels => $src->getchannels
);
$dest->paste(left => 1, top => 1, src => $src);
$dest->write(file => "b.jpg") or die $dest->errstr;
Try reversing the direction of x and y - not from 1 to max but from max to 1. You are not sliding the colors but copying the same again and again.
I realize that this is an old post, but this is a piece of code that I use GD:Thumb for creating resized images.
sub png {
my ($orig,$n) = (shift,shift);
my ($ox,$oy) = $orig->getBounds();
my $r = $ox>$oy ? $ox / $n : $oy / $n;
my $thumb = GD::Image->newFromPng($ox/$r,$oy/$r,[0]);
$thumb->copyResized($orig,0,0,0,0,$ox/$r,$oy/$r,$ox,$oy);
return $thumb, sprintf("%.0f",$ox/$r), sprintf("%.0f",$oy/$r);
}