[PanoTools-devel] Cropping

[Pablo d'A. <pab...@we...>]

Hi Daniel,

Daniel M. German schrieb:
> 
> One of the things that I dislike about panotools is its desire to be
> "symmetric" and to always put the point in front of the viewer in the
> center of the image, even if the panorama only covers an area that
> does not include it.
> 
> For this reason I think it will be useful to be able to create some
> command line commands that can analyze the TIFFs (cropped or
> uncropped) to compute the true area of the panorama, and use this as
> the basis for the cropping of the tiffs.

I don't like the "symmetric" behaviour too, but I think it would be
preferable to extend PTmender and nona to support cropping in the first
place, with a new parameter in the "p" line, that specifies a subregion of
the image:

p f2 w3000 h1500 v360 bleft:top:right:bottom

Then the user can decided what to render already while creating the
panorama. Internally hugin and nona have support for that, I just haven't
had the time to add it to parser and GUI yet.

> So I propose the creation of a pano cropping tool that takes as input
> as set of TIFFs (cropped or uncropped) and generates as output a set
> of cropped tiffs such that:
> 
> a) Any edge of the total sum of all tiffs contains at least one "true"
>   pixel (a pixel with data from at least one pano).

That means the bounding rectangle

> or
> 
> b) Any edge of the total sum does not contain a single "black" pixel
>   (that is, a pixel with no information).

That the "inside" rectangle.

> This tool is useless for those who do sphericals, but very useful for
> those of us who do mosaics or semi-sphericals.
> 
> I think this will help a lot with our workflow. 

I think so to. While I would prefer setting the crop while creating the
panorama (where one can also decide for a tighter crop, if wanted), a
standalone tool after is probably more flexible, since it is also useful for
other applications.

>  >> With respect to creating a text file with info about the
>  >> panorama. What do you think about this:
>  >> file1;offsetx,offsety;croppedsizex,croppedsizey
> 
>  Pablo> What about filenames with ";" in them :-)
> 
> I think that it is better to have the filename first (in case the
> other information is missing). What we can do is to escape ';' with
> '\;'. That will be easy to implement.

Yep, agreed.

ciao
  Pablo