How oddly wad...

I log in to gimpchat.com and I am randomly (I think, unless goolgol's ai has been perfected at last) offered an introductory link to: "Spherical Zoom."

Now--and here's where the intriguing mysteriousliness is--I was visiting preCISEly because I've been trying to do the nearly same thing, but with G'Mic Cartesian-transform deformation.

Now that's eery and I don't mean Pee-Ay either icantellyourightnow.

Anyway, I'm not interested in an "effect" as much as I am in a by-golly reversible tranformation. What I've got is a map of the lunar surface (from USGS), reportedly, and somewhat intelligibly in cylindrical coordinates. I want to cut the rect. pic into two square "hemisquares" and then transform each into a hemisphere.

I played with Filters->LensEffect, but it proved to be that, an effect.

Then I remembered G'MIC's underlying math engine, and after some piddly-diddling around, I found "Cartesian transform" under "Deformations." (It helped that the default already has an equation visible in it...)

After more p-d'ing around trying to construct something by experimentation, I finally drug out the trusty paper and pencil and did some trig. (remember trig?) I don't think I understand, and I even think I don't understand, what G'MIC is up to here. I thought it was going to use my transformation equations to calculate a new (xn,yn) position for the pixels located at old (xo,yo) positions.

However, I've been surprised. Finally, I created a spreadsheet to create the transforms there first, and from that to infer and copy what-must-be the transformations into G'MIC's Cartesian transform, but still no success. Whence I think I don't understand. Wince, I think I come ask you all what you think about it.

So I'll'mattach a) a square moonar image in cylindrical projection and b) ask you if these Cartesian transformation equations make sense to you:
newx=w/2 - ( cos( asin(( (h/2)-y ) / (h/2)) ) * (w/2-x) )
newy=y

I'm interpreting x,y to be coordinates in the orig. image, and w,h to be width and height of same. I am also expecting both images to have origins at the upper left.

I'llcan give the spreadsheet too if you want to see it.

(Yes, I have put the "Model Railroad Coffee Tables" on hold for the nonce...)

Best greetings, friends!
--
gramp
P.S. found the map at:
http://astrogeology.usgs.gov/search/det ... ar2014/cub

What I'm after may possibly be understood from the following picture; I want to shift the x-values of all the pixels on a particular line in the square original, proportionately towards the center of the circular picture, with the proportionality determined by the distance of the y-value from the center of the picture.

That is, the red (vertical edges) pixels should shift onto the perimeter of the circle, and the green not-at-all, and the shifts of in-between pixels should reduce the nearer they are to center.

Pixels outside the circle in the final drawing are don't-cares, to be trimmed off later; however, I do not think my transform will set anything outside the circle.

Maybe Circle to Line perspective comes close. More than likely can be done in G'MIC as well but I do this currently using Mathmap.

viewtopic.php?f=11&t=9832&p=128377&hilit=Circle+to+line&sid=16bb1d72ddaf46d87cf680a83ef3c922#p128377

And below's the thread that inspired this (I said flickr group by mistake in the above thread):

https://groups.google.com/forum/#!searc ... 9ekYou--gJ

Gramp, I put your formula into a quick script and ran your picture through it. This is what I got:



Probably not what you want. What you have probably done is look at it as "where do I move this pixel to" problem. That is the exact opposite of what you need to do when writing filters. What you have to ask is, "at this current (x,y) point, where do I need to pull the pixel from". If you go back to your math, you should be able to rework it to solve it from the opposite direction.

You know where the pixel is going, you just don't know where it is coming from.!

Souphead.

@Lyle

Thank you: there's some good maths in there, especially as I have never been introduced to MathMap.

I don't think it's what I want however because as I understand my image, only the points on the perimeter of the square need to map to a circle, and points inside the square need only to be moved more or less towards the center, remaining on their existing lines (y-coord).

Even if I can successfully invert Edgar Bonet's clever transformation, I expect I would end up with something that mapped left-right lines of the original image onto concentric circles.

@Souphead
I got the same result using my functions in G'MIC's Cartesian Transform.

I do actually know where I want to move each pixel. Just to give two examples, I know all the points on the first and last lines need to map to a single point on the first and last line of the output, and I know that for the line in the exact middle, all the points need to map, unscaled, onto the equator of the output. For lines between the equator and the poles, the points need to map onto the output at the same "latitude" but scaled increasingly towards the center of the picture the further they lie from the equator.

This is probably standard cartography stuff.

I'll take Lyle's post for the recommendation it is to take a further look into MathMap, but I feel in my gut that G'MIC's got the powers and that I'm just not talking to she correckly.
--
gramp

> but I feel in my gut that G'MIC's got the powers and that I'm just not talking to she correckly.

Indeed my assumption seems to be that, in the formulas I'm entering for G'MIC's Cartesian transform,
X-warping: w/2 - (cos(asin( ( (h/2)-y ) / (h/2) )) * (w/2-x))
Y-warping: y
that G'MIC will--somehow--iterate over the original image, running y first from 0 to h and then x from 0 to w.

I don't know where I get this assumption, but it seems to arise from within rather than any information in the real world.
--
gramp

...and, quelle surprise!, my gut is "at least half" right.

Take a look at this modified form of the X-warping function (Y-warping remains 'y'):
X-warping: cos(asin( ( (h/2)-y ) / (h/2) )) * x - w/2

The most bizarre behavior to me is this: I expect the "-w/2" term, a constant, to be a shift of "w/2" pixels (half the width) to the left, but it definitely affects the curvature even as it's effecting a shift.

Note that the transformed file layer lies over the original rectangular depiction, and also note how features are "bent" in the output.

--
gramp

...and btw I'm wed to G'MIC as a computer/plotter because (from web reports) one has to compile MathMap for GIMP 2.8 under Ubuntu, and there are nowhere mountains of testimony to ease and success.

Playing with Cartesian trying to understand its thought processes, I quickly learned that output coordinates have to be positive to be visible. I'm wondering if there's a buffer-overflow possibly.

I'm not sure if this is what you want, but to map to a circle un-tick "relative warping" and use for x:



My trig is very poor so perhaps that can be simplified...

Edit - some explanation

As Souphead mentioned that G'MIC filter iterates over each point (x,y) on the output image and asks where it should look for a value, which is the opposite of taking each pixel and asking where it should go.

I suppose pythagoras can do part of the work instead:



Or if you only want to "squash" horizontal each line by a fixed ratio:

So is there any value in converting this from MATHMAP to G'MIC or does G'MIC have something like this already? It doesn't look like a hard one. (It being the MATHMAP code below):



Souphead.

Again; this is not my code. Just a copy paste and I sourced it (google group). I didn't know the link at the time I originally posted the code (thought I got it from the Flickr mathmap group and could not find the code). You have to ask the author at the mathmap group at Google anything questions you may have for the code. I'm just an avid user; not a coder Souphead.

Firstly thank you: I had no idea one could "stack" statements, or use variables, in the fields' specifications. And secondly, your trig is salvififying: your first entry is precisely what I was seeking--and suspected was possible. Thank you.

Thickheaded as I am I'm still clinging to the belief that G'MIC is asking "where to move the pixel it's currently looking at at (x,y)", warping the image in the process.

Owing to th'kheadeness, I admit that I didn't websearch for "G'MIC+'Cartesian transform'" until after your post (...and I think perhaps such an admission should be part of, or replace, my sig...), but when I finally did, I found:
viewtopic.php?f=28&t=7593
with you prominently figuring...

Thank you for digging this out: I had actually stepped away from the forum for a few days to look at trying it in Java-based imagej.

Even without garagecoder's explicition, your post definitely made the problem tractable. Thanks.

One last, related to garagecoder's post and Souphead's query about whether G'MIC already has something similar:

Q. Is there a way to save this transform in G'MIC? (Now what is that that I promised myself I would try to remember? Something about search... websearch? Yes, websearch. But websearch what? I wonder. Oh well.)

[Ed. https://www.youtube.com/watch?v=6bFZJt9knyM Mahvelous Mahvin's weighed in on it, but my link is too slow for anything but text; sometimes even uppercase is too hard on it.]

Certainly this is the default view but G'MIC can really do it either way. Using the Mathematical Parser, you can work with an input (your original image) and a blank (your output). Actually you can work with as many inputs and outputs as you want (it's that flexible).

By default, G'MIC wants to update the pixel it is currently working on but you can ignore that approach and for each input pixel calculate where you want to "push it" and store that on your blank image.

That would be more in-line with your (and most sane people's) way of thinking. A template and probably even a pixel pushing equivalent of Cartesian Transform are possible.

As to saving expressions, there are some file handling commands in G'MIC. Maybe that could work but then the issue becomes how to display stored ones and how to retrieve a specific one. Sounds like limited database handling now

Souphead.

The simplest way is to enter your formulas then add a favourite (small "+" button at the bottom).
You can edit the fav's list in %appdata%\gmic\gimp_faves on windows but take care of course!

It comes as a shock that I've talked about cartesian transform previously, I have no memory of it at all and I normally steer clear of trig.

Thanks for snatching saving my mad idea from doom, again.

As to the whyohwhys of it all:


I'm gonna cut this out and hang it on somebody's wall somewhere.

I clicked the little white "+" button and it did I know not what and changed to a little white "-" button. So. I clicked that too... [expand/collapse the appositive comments say]

But then I clicked the larger green "+" button and, that is the one that created a new Category, "Faves," and saved my settings there under "Cartesian transform." (Just for fun I clicked Green+ again and it saved it again. The larger red "Don't!/Ghostbusters/Verboten" icon removes an item from Faves.)

I've been experiencing that memory thing for a bit myself. I look back at stuff and think, "Man that was clever! Wonder who did it?" and cannot believe the evidence that shows it was none but moi.

That embossed look is cool, not really a mad idea
Glad I could help!

...not just a look anymore! (That's what I meant by "cut this out".)