I have a few hundred photos. Each photograph is one object. And with each photo repeat the same steps:
Open, select the area; crop, resize, fix brightness, save.
My attempt to automate the process: write a script and hang it on a hotkey.
(define (script-fu-cut800 inText inFont inFontSize inTextColor)
; get the coordinates of allocation
(gimp-image-get-selection (image))
(let * (
(original-left (car (????)))
(original-top (car (????)))
(original-width (car (gimp-image-width image)))
(original-height (car (gimp-image-height image)))
(new-width (- original-width (+ right left)))
(new-height (- original-height (+ top bottom)))
)
; crop the selected image
(gimp-image-crop image new-width new-height left top)
; resize to 800 * 800
(gimp-image-resize image 800 800 0 0)
; open dialogue correction levels
(?????)
; save as JPG 80% compression of the same name
(file-jpeg-save ????)
))
I want to create an image like notebooke paper,
and I thought it is easy if the section of drawing lines
is automated.
In order to make it, I decided to use gimp's function named
'gimp-rect-select' and specify the small height value.
I google-searched and wrote a scheme file,
but when I ran it from gimp's Script-Fu menu,
gimp showed me the message as below.
Error while executing FU01-multi-rect-select:
Error: ( : 1)
Invalid number of arguments for gimp-rect-select
(expected 8 but received 9)
I would like you to see my first script-fu and
point out where something wrong is involved.
To me, my custom function is defined so that
it has 8 parameters, not 9.
The folloing is my code
(define (FU01-multi-rect-select
image
drawable
x1
y1
w
h
p-offset
p-repeat
)
;definition of variables
(let*
(
(X nil)
(Y nil)
(width nil)
(height nil)
(offset nil)
(repeat nil)
;are they below necessary?
(theLayer nil)
(theImage nil)
)
;(gimp-context-push )
(gimp-image-undo-group-start image)
;(set! X (string->number x1))
;(set! Y (string->number y1))
;(set! width (string->number w))
;(set! height (string->number h))
;(set! offset (string->number p-offset))
;(set! repeat (string->number p-repeat))
(set! X x1)
(set! Y y1)
(set! width w)
(set! height h)
(set! offset p-offset)
(set! repeat p-repeat)
(gimp-image-set-active-layer image drawable)
(set! theLayer
(car (gimp-image-get-active-layer image) )
)
; select rectangle and after that,
; add it to current selection
; multiple times that is specified with 'repeat'
(while (> repeat 0)
(gimp-rect-select image X Y width height
CHANNEL-OP-ADD FALSE 0 0)
(set! Y (+ Y height offset))
(set! repeat (- repeat 1))
)
(gimp-image-undo-group-end image)
) ; end of let sentences
)
(script-fu-register "FU01-multi-rect-select"
"<Image>/Script-Fu/Select/multi rect select"
"add a rect selection to current selection multiple times\
each time a rect is selected it is moved\
in y axis by the value of offset"
"Masaaki Fujioka"
"copy right 2014 Masaaki Fujioka"
"August 3 2014"
"*"
SF-IMAGE "SF-IMAGE" 0
SF-DRAWABLE "SF-DRAWABLE" 0
SF-VALUE "start x" "0"
SF-VALUE "start y" "0"
SF-VALUE "width" "0"
SF-VALUE "height" "0"
SF-VALUE "offset" "0"
SF-VALUE "repeat" "0"
)
Just like the error message says, you have one extra parameter to the gimp-rect-select call - if you check the specs for the call on the procedure browser, after the "mode" parameter there should be one boolean to tell whether you want to use feathering, and another number to tell the feathering amount. You are passing two integers instead of just one number needed.
Also, pay attention that this call is marked as "deprecated" - which means that although it still works in gimp-2.8, for a series of reason, you should be calling gimp-image-select-rectangle instead of this. (note that the parameters for that call differ).
So, I have been working on this game for a bit. However, over the past day I have not been able to figure out how to work my collision detection.
The scale at default is equal to 2.
The player is 41*scale by 64*scale.
My player is centered in the middle of the screen in both the x and y axis.
Since the player is centered the world is what moves, those variables are worldx and worldy. The player always stays at the center of the screen.
My tile map is stored in an array and is based on the image pixel color. If the pixel is white at map[x][y] the value is set to 0 else it's set to the block. Meaning the block does not get rendered.
for x = 0, w-1 do --scans the image and builds the map array
amap[x] = {}
for y = 0, h-1 do
local r, g, b, a = source:getPixel(x, y)
if r == 255 and g == 255 and b == 255 then
block = 0
end
if r == 255 and g == 100 and b == 0 then
block = 1
end
if r == 130 and g == 125 and b == 0 then
block = 2
end
if r == 76 and g == 76 and b == 76 then
block = 3
end
if r == 255 and g == 0 and b == 255 then
--this is the spawn pixel yet to build
end
amap[x][y] = block
end
end --end function
function that draws the map
for x = 0, w-1 do --draws the map
for y = 0, h-1 do
if amap[x][y] ~= 0 then
love.graphics.drawq(ImgBlocks, Blocks[amap[x][y]], 32*x*(3/bscale) + worldx, 32*y*(3/bscale) + worldy + jy, 0 , 3/bscale, 3/bscale)
end
if amap[x][y] == 4 then
end
end
end --end function
The function needs to return true or false base on if there is collision between player and block.
Your tiles are 32x32, correct? (from the drawq call) I would recommend you make a function that checks if a point is in a solid tile:
function pointCollisionTest(x, y)
-- find which tile the point is in
local tx, ty = math.floor(x / 32), math.floor(y / 32)
-- check the tile
if map[tx][ty] == solid then
return true
else
return false
end
end
You'll have to change the if map[x][y] == solid logic based on how you determine solid tiles, but this code should otherwise work.
Once you have point collision, the way you make the player collide is by checking each corner of its hitbox (which you should easily be able to determine) against this function whenever the player moves. There are a few ways to do this; I use the relatively simple method of calculating the player's new position, testing it, then canceling the move entirely if the collision test returns true. You have to check/cancel the x and y components of the move separately, though, so the player can move along walls instead of sticking to them.
Are you asking for a basic 2d collision detection?
A simplified formula:
if (playerx > blockminx) and (playery < blockmaxx) and (playery > blockminy) and (playery < blockmaxy) then collission
I'm experimenting with the ImageTransformation function to try to make anamorphic versions of images, but with limited progress so far. I'm aiming for the results you get using the image reflected in a cylindrical mirror, where the image curves around the central mirror for about 270 degrees. The wikipedia article has a couple of neat examples (and I borrowed Holbein's skull from them too).
i = Import["../Desktop/Holbein_Skull.jpg"];
i = ImageResize[i, 120]
f[x_, y_] := {(2 (y - 0.3) Cos [1.5 x]), (2 (y - 0.3) Sin [1.5 x])};
ImageTransformation[i, f[#[[1]], #[[2]]] &, Padding -> White]
But I can't persuade Mathematica to show me the entire image, or to bend it correctly. The anamorphic image should wrap right round the mirror placed "inside" the centre of the image, but it won't. I found suitable values for constants by putting it inside a manipulate (and turning the resolution down :). I'm using the formula:
x1 = a(y + b) cos(kx)
y1 = a(y + b) sin(kx)
Any help producing a better result would be greatly appreciated!
In ImageTransformation[f,img], the function f is such that a point {x,y} in the resulting image corresponds to f[{x,y}] in img. Since the resulting image is basically the polar transformation of img, f should be the inverse polar transformation, so you could do something like
anamorphic[img_, angle_: 270 Degree] :=
Module[{dim = ImageDimensions[img], rInner = 1, rOuter},
rOuter = rInner (1 + angle dim[[2]]/dim[[1]]);
ImageTransformation[img,
Function[{pt}, {ArcTan[-#2, #1] & ## pt, Norm[pt]}],
DataRange -> {{-angle/2, angle/2}, {rInner, rOuter}},
PlotRange -> {{-rOuter, rOuter}, {-rOuter, rOuter}},
Padding -> White
]
]
The resulting image looks something like
anamorphic[ExampleData[{"TestImage", "Lena"}]]
Note that you can a similar result with ParametricPlot and TextureCoordinateFunction, e.g.
anamorphic2[img_Image, angle_: 270 Degree] :=
Module[{rInner = 1,rOuter},
rOuter = rInner (1 + angle #2/#1 & ## ImageDimensions[img]);
ParametricPlot[{r Sin[t], -r Cos[t]}, {t, -angle/2, angle/2},
{r, rInner, rOuter},
TextureCoordinateFunction -> ({#3, #4} &),
PlotStyle -> {Opacity[1], Texture[img]},
Mesh -> None, Axes -> False,
BoundaryStyle -> None,
Frame -> False
]
]
anamorphic2[ExampleData[{"TestImage", "Lena"}]]
Edit
In answer to Mr.Wizard's question, if you don't have access to ImageTransformation or Texture you could transform the image data by hand by doing something like
anamorph3[img_, angle_: 270 Degree, imgWidth_: 512] :=
Module[{data, f, matrix, dim, rOuter, rInner = 1.},
dim = ImageDimensions[img];
rOuter = rInner (1 + angle #2/#1 & ## dim);
data = Table[
ListInterpolation[#[[All, All, i]],
{{rOuter, rInner}, {-angle/2, angle/2}}], {i, 3}] &#ImageData[img];
f[i_, j_] := If[Abs[j] <= angle/2 && rInner <= i <= rOuter,
Through[data[i, j]], {1., 1., 1.}];
Image#Table[f[Sqrt[i^2 + j^2], ArcTan[i, -j]],
{i, -rOuter, rOuter, 2 rOuter/(imgWidth - 1)},
{j, -rOuter, rOuter, 2 rOuter/(imgWidth - 1)}]]
Note that this assumes that img has three channels. If the image has fewer or more channels, you need to adapt the code.
i have implemented a simple image resampler in OpenCL which uses the Lanczos function.
Lanczos is defined by:
Written in C:
inline
float lanczos(float x, float a) {
if( x > fabs(a) ) return 0.0f;
if( x == 0.0f ) return 1.0f;
float pix = pi * x;
return sinc(pix)*sinc(pix/a);
}
Why is there a special case for 0? When i pass 0 to the formular it returns 1. But if i don't include the check for x == 0 it doesn't work.
Could someone shed some light for me?
Florian
Paul already answered, but in case OP wants to know why 0 is special case =>
1) x->0, sin(x)/x = 0/0 and this is indeterminate form.
2) One way to solve this problem is to expand sin(x)/x into Taylor series about zero point, by doing this we get:
x2 x4 x6 x8
1 - ----- + ----- - ------ + ----------- + ...
6 120 5040 362880
3) By substituting 0 into x we see that series converges to 1.
Oh man ... i have been looking at the lanczos function for hours ... and haven't noticed that sinc actually is:
sinc -> sin(x)/x
so the special case for 0 is to prevent a division by zero ... plain and simple ...