From: Bruno P. <br...@po...> - 2006-10-15 17:34:28
|
On Mon 02-Oct-2006 at 13:06 -0700, Daniel M. German wrote: > > Bruno> Unfortunately ImageMagick messes-up the cropped TIFF offsets so I > Bruno> was going to use PTuncrop to convert them to normal TIFFs (assuming > Bruno> it works on 16bit images, untested). > >It should work. If not, I'll fix it. Here are a couple of TIFFs that choke PTuncrop: http://bugbear.blackfish.org.uk/~bruno/photos/cropped-tiff/ I get this message: PTuncrop Version 2.8.5pre3 , by Daniel M German Source image is not a cropped tiff One is deflate compressed output from nona and the other has been opened with cinepaint and saved with no compression. Both are 16bit per channel. -- Bruno |
From: Bruno P. <br...@po...> - 2006-10-17 22:53:50
|
On Tue 17-Oct-2006 at 15:39 -0700, Daniel M. German wrote: > >HOw does enblend work? Does it assume the size of the panorama is the >size of the "largest" image (offset + size) in each dimension? Sorry no idea. >With respect to creating a text file with info about the >panorama. What do you think about this: > >---------------------------------------------------------------------- >n;fullsizex;fullsizey >file1;offsetx,offsety;croppedsizex,croppedsizey >... >filen;offsetx,offsety;croppedsizex,croppedsizey >---------------------------------------------------------------------- > >Do we need anything else? > >this can be created by nona and PTmender. Surely this can be generated for any cropped TIFF file by processing the output of tiffinfo? -- Bruno |
From: Daniel M. G. <dm...@uv...> - 2006-10-17 22:59:20
|
>> >> Do we need anything else? >> >> this can be created by nona and PTmender. Bruno> Surely this can be generated for any cropped TIFF file by processing Bruno> the output of tiffinfo? Bruno> -- Bruno> Bruno I think it will be useful to have the filenames and the number of files (tiffinfo can't generate them :). But I agree, the rest is easy to extract with tiffinfo. dmg -- Daniel M. German "I still have to see a problem, however complicated, which, when you looked at it in the right way Poul Anderson -> did not become still more complicated." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Pablo d'A. <pab...@we...> - 2006-10-18 06:31:21
|
Hi Daniel, Daniel M. German wrote: > Panotools uses the size of the first image to determine the size of > the overall panorama. There might be also implicit assumptions that > all images are the same size when allocating space and moving data > around. > > I will change the tools not to use the full size, if it is not > present. The question is, how do we determine the size of the output > panorama? > > HOw does enblend work? Does it assume the size of the panorama is the > size of the "largest" image (offset + size) in each dimension? Yes, this is how enblend works. Internally it does not have problems with the multiple sized files, since first it reads the properties of all files and calculates the final size afterwards. The user can also specify the size from the command line, should it be bigger than the largest image. All this is not perfect, but I didn't find the fullwidth tag at that time.. > With respect to creating a text file with info about the > panorama. What do you think about this: > > ---------------------------------------------------------------------- > n;fullsizex;fullsizey > file1;offsetx,offsety;croppedsizex,croppedsizey > ... > filen;offsetx,offsety;croppedsizex,croppedsizey > ---------------------------------------------------------------------- > > Do we need anything else? What about filenames with ";" in them :-) Then placing the filename at the end would be better. Lets hope nobody has files with a \n in the name :-) offsetx,offsety;croppedsizex,croppedsizey;filen Hmm, I'm not sure how far this should go, but we have talked about the two different alpha channels some time ago, one that defines the valid image area (like the TIFF_m alpha channel), and one that is used to determine the image area that will be visible after the image has been blended onto the panorama (like the TIFF_mask alpha channel). I guess it would be a good idea to add this information as well, if we decide on how things should work, with both enblend and PT* tools. My first idea would be to keep a tiff_m like alpha channel in the original file (because it is the most generic format), and add an additional mask file to the text file. The mask could also saved in a file with a _mask appended to the image file name instead of specifiying the filename explicitly in the file, so we would be back at: offsetx,offsety;croppedsizex,croppedsizey;filen > I would not like to have to read this file (it makes things more > complex) and rather have somebody write a "driver" for the tools (such > as a perl script). Hmm, at least using perl is not very convenient on windows I guess. However, a parser for a simple one line per image file shouldn't be too hard even in C. I can provide one if you don't like to write it. ciao Pablo |
From: Max L. <max...@ve...> - 2006-10-18 23:42:19
|
> 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). > > or > > b) Any edge of the total sum does not contain a single "black" pixel > (that is, a pixel with no information). > I've just finished coding something that does something similar to (b) that will be part of the next version of PTAssembler. It takes a final blended TIFF (e.g. the output from Enblend or Smartblend) and crops the image to remove all extra "black pixels" around the edge, leaving a finished, cropped image. It turned out to be more difficult than I had first guessed because what is really needed is to determine the rectangular region that encompasses the maximum area inside the image rather than look for rows or columns without black pixels at the edges. If one uses "cropped" TIFF files from PTMender (and perhaps Nona...I'm not sure), and then feed them to Smartblend or Enblend you'll end up with a result similar to (a) without any extra work (if I understand the description correctly). Max |
From: Daniel M. G. <dm...@uv...> - 2006-10-23 23:55:29
|
>> 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). >> >> or >> >> b) Any edge of the total sum does not contain a single "black" pixel >> (that is, a pixel with no information). >> Max> I've just finished coding something that does something similar to (b) that Max> will be part of the next version of PTAssembler. It takes a final blended TIFF Max> (e.g. the output from Enblend or Smartblend) and crops the image to remove all Max> extra "black pixels" around the edge, leaving a finished, cropped image. Max> It turned out to be more difficult than I had first guessed because what is Max> really needed is to determine the rectangular region that encompasses the Max> maximum area inside the image rather than look for rows or columns without Max> black pixels at the edges. Hi Max, Any chance you can contribute some of that code to panotoos? I'll write the wrapper program around it. -- Daniel M. German "A person may cause evil to others not only by his actions but by his inaction, and in neither case he is justly accountable John Stuart Mill -> to them for the injury." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2006-10-24 23:31:09
|
> Hi Max, > > Any chance you can contribute some of that code to panotoos? I'll > write the wrapper program around it. > I think I'm going to hold off on that. It is actually a stand alone C program, but this one was developed by my Tawbaware team (i.e. me), rather than my open source team (i.e. me)! The good news is that I'll be contributing another utility program shortly...PTFinalize. I'll have some more details later. Max |
From: Pablo d'A. <pab...@we...> - 2006-10-19 06:03:46
|
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 |
From: Daniel M. G. <dm...@uv...> - 2006-10-24 00:19:52
|
Pablo d'Angelo twisted the bytes to say: Pablo> Hi Daniel, Pablo> 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. Pablo> I don't like the "symmetric" behaviour too, but I think it would be Pablo> preferable to extend PTmender and nona to support cropping in the first Pablo> place, with a new parameter in the "p" line, that specifies a subregion of Pablo> the image: Pablo> p f2 w3000 h1500 v360 bleft:top:right:bottom Pablo> Then the user can decided what to render already while creating the Pablo> panorama. Internally hugin and nona have support for that, I just haven't Pablo> had the time to add it to parser and GUI yet. I agree, this is something that will help a lot. Perhaps we should also include two more options to output either: * The bounding rectangle or * The inside rectangle. This can accelerate processing (if the user wants to process only a region of the pano) but I suspect that for the majority it will not make a big difference (in processing speed) if the cropping happens after the current remapped TIFFs are created. We could then first implement it with a command line utility and then embed it into PTmender or nona, if we feel it is worth the investment. -- Daniel M. German "As De Gaulle used to say: 'Aim well, shoot fast Henri Cartier Bresson -> and get the hell out.'" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2006-10-17 19:38:40
|
Hi Bruno, Thanks for the test images. The reason that PTuncrop does not work is that the TIFF files lack full image records. What should the behaviour of PTuncrop be in this case? 1. Force the user to specify full size of the image as a parameter? 2. Force the full size to be offset + cropped_size (in each dimension)? 2 is easy to implement, but I think 1 is the proper option, given that TIFFs have to be "compatible" (same size, same depth) to be "blended". Bruno> On Mon 02-Oct-2006 at 13:06 -0700, Daniel M. German wrote: >> Bruno> Unfortunately ImageMagick messes-up the cropped TIFF offsets so I Bruno> was going to use PTuncrop to convert them to normal TIFFs (assuming Bruno> it works on 16bit images, untested). >> >> It should work. If not, I'll fix it. Bruno> Here are a couple of TIFFs that choke PTuncrop: Bruno> http://bugbear.blackfish.org.uk/~bruno/photos/cropped-tiff/ Bruno> I get this message: PTuncrop Version 2.8.5pre3 , by Daniel M German Source image is not a cropped tiff Bruno> One is deflate compressed output from nona and the other has been Bruno> opened with cinepaint and saved with no compression. Both are Bruno> 16bit per channel. Bruno> -- Bruno> Bruno Bruno> ------------------------------------------------------------------------- Bruno> Using Tomcat but need to do more? Need to support web services, security? Bruno> Get stuff done quickly with pre-integrated technology to make your job easier Bruno> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo Bruno> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 Bruno> _______________________________________________ Bruno> PanoTools-devel mailing list Bruno> Pan...@li... Bruno> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning Louis Brandeis -> but without understanding." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2006-10-17 19:49:44
|
Daniel> Hi Bruno, Daniel> Thanks for the test images. The reason that PTuncrop does not work is Daniel> that the TIFF files lack full image records. Sorry, I meant to say full size image records. For some reasons those files only include the cropped size + offsets. How did you generate them? -- Daniel M. German "Complexity theory is about proving that I cannot prove this, Valentine Kabanets -> but neither can you." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Pablo d'A. <pab...@we...> - 2006-10-17 20:08:14
|
Hi Daniel, > Hi Bruno, > > Thanks for the test images. The reason that PTuncrop does not work is > that the TIFF files lack full image records. is there a tag to specify the full/page size? Then I must have missed it, and nona needs to be extended to write that tag as well. Just checked the panotools source, and indeed, I overlooked the TIFFTAG_PIXAR_IMAGEFULLWIDTH tag when adding cropped tiff to nona and enblend last year. Hmm, I only read the TIFF 6.0 spec and not the libtiff header file.. > What should the behaviour of PTuncrop be in this case? I think the same behaviour enblend would be the least confusing: 2 if nothing specified by user, 1 otherwise. > 1. Force the user to specify full size of the image as a parameter? > > 2. Force the full size to be offset + cropped_size (in each > dimension)? Btw. given that the offset/size information in the tiff files is not useable by most editors, maybe this meta information could also be stored in a text file, alongside the remapped pano? This would hopefully enable users of scriptable image processing tools (gimp/photoshop) to write suitable scripts to load the multilayer tiff images properly into their image editor and write the to an enblend/PTblender compatible format. ciao Pablo |
From: Bruno P. <br...@po...> - 2006-10-17 21:42:20
|
On Tue 17-Oct-2006 at 11:55 -0700, Daniel M. German wrote: > >Thanks for the test images. The reason that PTuncrop does not work is >that the TIFF files lack full image records. > >What should the behaviour of PTuncrop be in this case? > >1. Force the user to specify full size of the image as a parameter? > >2. Force the full size to be offset + cropped_size (in each > dimension)? 2 by default, but 1 would be a useful option. >2 is easy to implement, but I think 1 is the proper option, given that >TIFFs have to be "compatible" (same size, same depth) to be "blended". Actually enblend is quite happy blending images with different dimensions, it just aligns the top left corner of each. I just assumed that because nona doesn't record the full 'cropped TIFF' image size, this was how it was supposed to work. -- Bruno |
From: Daniel M. G. <dm...@uv...> - 2006-10-17 22:39:35
|
Bruno> On Tue 17-Oct-2006 at 11:55 -0700, Daniel M. German wrote: >> >> Thanks for the test images. The reason that PTuncrop does not work is >> that the TIFF files lack full image records. >> >> What should the behaviour of PTuncrop be in this case? >> >> 1. Force the user to specify full size of the image as a parameter? >> >> 2. Force the full size to be offset + cropped_size (in each >> dimension)? Bruno> 2 by default, but 1 would be a useful option. >> 2 is easy to implement, but I think 1 is the proper option, given that >> TIFFs have to be "compatible" (same size, same depth) to be "blended". Bruno> Actually enblend is quite happy blending images with different Bruno> dimensions, it just aligns the top left corner of each. I just Bruno> assumed that because nona doesn't record the full 'cropped TIFF' Bruno> image size, this was how it was supposed to work. Panotools uses the size of the first image to determine the size of the overall panorama. There might be also implicit assumptions that all images are the same size when allocating space and moving data around. I will change the tools not to use the full size, if it is not present. The question is, how do we determine the size of the output panorama? HOw does enblend work? Does it assume the size of the panorama is the size of the "largest" image (offset + size) in each dimension? With respect to creating a text file with info about the panorama. What do you think about this: ---------------------------------------------------------------------- n;fullsizex;fullsizey file1;offsetx,offsety;croppedsizex,croppedsizey ... filen;offsetx,offsety;croppedsizex,croppedsizey ---------------------------------------------------------------------- Do we need anything else? this can be created by nona and PTmender. I would not like to have to read this file (it makes things more complex) and rather have somebody write a "driver" for the tools (such as a perl script). As long as the PT<tools> have command line options to use this data. dmg -- Daniel M. German "If Microsoft ever does applications Linus Torvalds -> for Linux it means I've won." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Daniel M. G. <dm...@uv...> - 2006-10-18 19:58:31
|
Pablo> Hi Daniel, Pablo> Daniel M. German wrote: >> Panotools uses the size of the first image to determine the size of >> the overall panorama. There might be also implicit assumptions that >> all images are the same size when allocating space and moving data >> around. >> >> I will change the tools not to use the full size, if it is not >> present. The question is, how do we determine the size of the output >> panorama? >> >> HOw does enblend work? Does it assume the size of the panorama is the >> size of the "largest" image (offset + size) in each dimension? Pablo> Yes, this is how enblend works. Internally it does not have problems with Pablo> the multiple sized files, since first it reads the properties of all files Pablo> and calculates the final size afterwards. Pablo> The user can also specify the size from the command line, should it be Pablo> bigger than the largest image. All this is not perfect, but I didn't find Pablo> the fullwidth tag at that time.. 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. 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). or b) Any edge of the total sum does not contain a single "black" pixel (that is, a pixel with no information). a) or b) are a user option. 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. At some point I need to "crop" the pano as in b) option. But I tend to do it in photoshop, making it unreliable. And if I need to process some of the images again, it makes it difficult to aling them. For this reason it is my very last action, but that means I have a lot of "waste" space. >> With respect to creating a text file with info about the >> panorama. What do you think about this: >> >> ---------------------------------------------------------------------- >> n;fullsizex;fullsizey >> file1;offsetx,offsety;croppedsizex,croppedsizey >> ... >> filen;offsetx,offsety;croppedsizex,croppedsizey >> ---------------------------------------------------------------------- >> >> Do we need anything else? 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. -- Daniel M. German "Diminutive as a mote of dust, a mere peck of the pen, a crumb on the keyboard, the full stop --the period-- is the unsung legislator of our Alberto Manguel -> writing systems" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |