On 22/03/2012 5:41 PM, clipka wrote:
> Am 22.03.2012 09:55, schrieb Stephen:
>
>> Also a Mollweide projection (I think)
>> http://www.nasa.gov/mission_pages/WISE/multimedia/pia15481.html
>
> They call it Aitoff.

Thanks and I take my ait off to you. :-)

-- 
Regards
     Stephen

Post a reply to this message

Am 22.03.2012 19:11, schrieb Le_Forgeron:

>>> Also a Mollweide projection (I think)
>>> http://www.nasa.gov/mission_pages/WISE/multimedia/pia15481.html
>>
>> They call it Aitoff.
>
> the difference might be subtle. And is it Aitoff or Hammer-Aitoff ?

They call it Aitoff, so I guess it's Aitoff.


We definitely need custom-projection warps and cameras. You know, with 
functions defining the projection.

Post a reply to this message

Am 22.03.2012 19:58, schrieb Stephen:
> On 22/03/2012 5:41 PM, clipka wrote:
>> Am 22.03.2012 09:55, schrieb Stephen:
>>
>>> Also a Mollweide projection (I think)
>>> http://www.nasa.gov/mission_pages/WISE/multimedia/pia15481.html
>>
>> They call it Aitoff.
>
> Thanks and I take my ait off to you. :-)

Why? Because I read the text? I had never heard of this Aitoff thing 
before myself ;-)

Post a reply to this message

On 23/03/2012 4:14 PM, clipka wrote:
> Am 22.03.2012 19:58, schrieb Stephen:
>> On 22/03/2012 5:41 PM, clipka wrote:
>>> Am 22.03.2012 09:55, schrieb Stephen:
>>>
>>>> Also a Mollweide projection (I think)
>>>> http://www.nasa.gov/mission_pages/WISE/multimedia/pia15481.html
>>>
>>> They call it Aitoff.
>>
>> Thanks and I take my ait off to you. :-)
>
> Why? Because I read the text? I had never heard of this Aitoff thing
> before myself ;-)

It was a joke, albeit a poor one.

-- 
Regards
     Stephen

Post a reply to this message

Le 23/03/2012 17:12, clipka nous fit lire :
> They call it Aitoff, so I guess it's Aitoff.
> 

The true formula for Aitoff is painfull to generate a map (camera); at
least, I get confused by sinc-function enhanced formula (see english
wikipedia), as of course to make a camera, we are going from x,y to
spherical coordinate (and of course, that is not provided by the
documentation, and I did not intend to use a solver)


> 
> We definitely need custom-projection warps and cameras. You know, with
> functions defining the projection.

For custom-camera, you would need a way to output 2 vectors (origin,
direction) from the inputs of 4 vectors (location, up, right,
direction), 2 doubles between 0 and 1, and whatever you do with them as
hard-coded/SDL-coded formulas (including other SDL data and hard-coded
values).(you might see it as a function of 2 doubles which must provides
2 3D-vectors)

Some formula are easy in one direction and nightmare/impossible in
opposite (camera vs projection).

Did you say projection warps ? I would have thought about projection
map_type.  (from a 3D point, some others data (assume origin & other ?),
provide a couple of doubles : integer part can be used to isolate the
"once" (0.x,0.y) and the part after the dot is the coordinate on
map/picture (scale to 0 to 1 in both direction)

Post a reply to this message

Am 23.03.2012 19:22, schrieb Le_Forgeron:

>> We definitely need custom-projection warps and cameras. You know, with
>> functions defining the projection.
>
> For custom-camera, you would need a way to output 2 vectors (origin,
> direction) from the inputs of 4 vectors (location, up, right,
> direction), 2 doubles between 0 and 1, and whatever you do with them as
> hard-coded/SDL-coded formulas (including other SDL data and hard-coded
> values).(you might see it as a function of 2 doubles which must provides
> 2 3D-vectors)

Not really.

The location, up, right & direction vectors just orient the camera; 
that's a simple matrix operation that is independent of the projection 
formula.

For a truly generic projection we'd need six funcions, each taking two 
numbers (X and Y coordinate in resulting image): Ray origin X,Y,Z and 
ray direction X,Y,Z.

For any cartographic projection, two functions would suffice: From two 
screen coordinates (X,Y) we'd have to compute two spherical coordinates 
(phi and theta).

> Did you say projection warps ? I would have thought about projection
> map_type.  (from a 3D point, some others data (assume origin&  other ?),
> provide a couple of doubles : integer part can be used to isolate the
> "once" (0.x,0.y) and the part after the dot is the coordinate on
> map/picture (scale to 0 to 1 in both direction)

Map types can only be used with input images; implementing the stuff as 
a custom warp instead would allow to do the same operations on other 
patterns as well.

Post a reply to this message

Le 24/03/2012 02:45, clipka nous fit lire :
> Am 23.03.2012 19:22, schrieb Le_Forgeron:
> 
>>> We definitely need custom-projection warps and cameras. You know, with
>>> functions defining the projection.
>>
>> For custom-camera, you would need a way to output 2 vectors (origin,
>> direction) from the inputs of 4 vectors (location, up, right,
>> direction), 2 doubles between 0 and 1, and whatever you do with them as
>> hard-coded/SDL-coded formulas (including other SDL data and hard-coded
>> values).(you might see it as a function of 2 doubles which must provides
>> 2 3D-vectors)
> 
> Not really.
> 
> The location, up, right & direction vectors just orient the camera;
> that's a simple matrix operation that is independent of the projection
> formula.
> 
> For a truly generic projection we'd need six funcions, each taking two
> numbers (X and Y coordinate in resulting image): Ray origin X,Y,Z and
> ray direction X,Y,Z.
> 
> For any cartographic projection, two functions would suffice: From two
> screen coordinates (X,Y) we'd have to compute two spherical coordinates
> (phi and theta).
> 

Unless you are always mapping from below (center of the planet), I
prefer for an absolute custom camera to be able to set the origin and
direction of each ray (well, each pixel ray, as well as AA sub-rays).
It seems more natural to thing of the camera as a flying satellite
(well, rather a parallel set of raster satellites using their own single
"laser beam"). Probably something along a mathematical-function(s) based
"mesh camera" (without a mesh)

[so far, I have no intent to implement that fully custom camera. yet ?]

It could also allow for easy (easier ?) setting for stereographic render
(half left-picture for left eye, half right-part for right eye)
(not sure about naming that stereographic)

Simulating the eye(s ?) of bee or fly could also be done (once someone
found the formula)

>> Did you say projection warps ? I would have thought about projection
>> map_type.  (from a 3D point, some others data (assume origin&  other ?),
>> provide a couple of doubles : integer part can be used to isolate the
>> "once" (0.x,0.y) and the part after the dot is the coordinate on
>> map/picture (scale to 0 to 1 in both direction)
> 
> Map types can only be used with input images; implementing the stuff as
> a custom warp instead would allow to do the same operations on other
> patterns as well.

Oh, nice thought. I would never have added a warp in a pigment/image_map
to change its type. Nor using a classical pattern.

maybe it would be "safer" to drop map_type and push the usage of warp
(doing it one way) for image_map.

About using other pattern, it might be more troublesome, as some are
really 3D and cannot be limited to a plane. (and other are using more
than just the position).

Post a reply to this message