From: dmg <dm...@uv...> - 2006-10-18 19:58:31
|
I have been toying with the idea of storing the script that creates the pano inside the TIFFs. I think this will be very useful. I think there is a a comment field that would be very useful for this purpose. It could also be a better option to store the list of TIFFs that compose a pano, as compared to store it in a TXT file along the files. Or perhaps both options are an even better solution. dmg |
From: Max L. <max...@ve...> - 2006-10-18 23:17:50
|
Another idea might be to store the script inside the TIFF, after removing all the "o" (and perhaps "i" and "C") lines that correspond to other images in the project. That way, you'd have all the information necessary to recreate the image without carrying around the extra data for other images in the project. Max > > I have been toying with the idea of storing the script that creates > the pano inside the TIFFs. I think this will be very useful. I think > there is a a comment field that would be very useful for this purpose. > It could also be a better option to store the list of TIFFs that > compose a pano, as compared to store it in a TXT file along the > files. Or perhaps both options are an even better solution. > > dmg > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.408 / Virus Database: 268.13.5/482 - Release Date: 10/18/2006 > |
From: Daniel M. G. <dm...@uv...> - 2006-10-23 19:49:34
|
Max Lyons twisted the bytes to say: Max> Another idea might be to store the script inside the TIFF, after removing all Max> the "o" (and perhaps "i" and "C") lines that correspond to other images in the Max> project. That way, you'd have all the information necessary to recreate the Max> image without carrying around the extra data for other images in the project. Max> Max hi Max, I think this is a great idea. The only disadvantage is what to do when we flatten the image. Perhaps a better solution is to add: * The entire script * An indicator to which image number the current file corresponds to (-1) if it is flatten. I need to read the TIFF spec to see where we can add this extra information. dmg -- 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: yuval l. <yuv...@ya...> - 2006-10-19 00:46:13
|
--- dmg <dm...@uv...>, "Daniel M. German" <dm...@uv...> wrote: > I have been toying with the idea of storing the > script that creates the pano inside the TIFFs. as long as you leave the option to store it in a separate file too I don't have anything to object, though in my current workflow storing anything of lasting value inside the TIFF is a waste of time/space/energy. I use the TIFFs only as in between format during the process of stitching. > I think this will be very useful. I'm always open to new learnings. In what situation could this be useful? to me, currently it would not change a thing. Yuv __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Daniel M. G. <dm...@uv...> - 2006-10-19 01:16:10
|
>> I think this will be very useful. yuval> I'm always open to new learnings. In what situation yuval> could this be useful? to me, currently it would not yuval> change a thing. Have you ever had a TIFF but not know how it was created? yuval> Yuv -- Daniel M. German "No one can be a great thinker who does not recognize, that as a thinker it is his first duty to follow his intellect to whatever John Stuart Mill -> conclusions it may lead." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: yuval l. <yuv...@ya...> - 2006-10-19 13:45:33
|
--- "Daniel M. German" <dm...@uv...> wrote: > Have you ever had a TIFF but not know how it was > created? Your question above can be turned around a number of times: Have you ever had a XXX but not know how it was created? - replace XXX with JPG, GIF, PNG, RAW, BMP, ... you name it. Unless you can store consistently the information you are suggesting to store in the TIFF across all image formats, I urge you to look for a different place to store that information and the relationship between the lost image and its meta data. To give you the more specific example of my own workflow, the answer is *no*. TIFFs are only temporary work files in my workflow. I shoot RAW most of the time. I transform the RAWs into TIFFs for processing. I archive the RAWs and the conversion settings. I dump the input TIFFs after processing as they are much heavier than the RAWs+conversion settings which can reconstruct the TIFFs in no time. Depending on the complexity of the project, I might add alpha transparency to the input TIFFs. I store the mask only, with a file name that clearly references the original RAW file name. I store the mask as PSD. Then I set up the stitching project, which is also archived, as PTS/textfile. I stitch the input TIFFs into output TIFFs which I load into my image editing application (currently Photoshop, and no intention to switch, even though I checked that the Gimp in Ubuntu can open and work with all of my files). I do my editing on layers, making sure I can always go back on each individual manipulation. I save the resulting layered equirect as PSD, with a file name consistent with the PTS filename. Depending on the complexity of work at nadir and zenith, I often also store separately the extracted nadir/zenith view with the work done on it before reinsertion - also all in PSD. When I am happy with the result, I archive all of the above project files in an appropriately named directory that also contains information such as audio recordings, positioning, etc. - each in appropriately named and structured files. I generate one last TIFF - a flattened equirect that goes into the script that produces for me all the different visualization formats and resolutions - mostly as JPGs. I used to delete that TIFF after production of the visualization formats, but I have now moved to have them on a staging server so that when I want to introduce a new visualization format I only have to run a script through the storage on the staging server. I came across this problem when Thomas introduced Flash output to pano2qtvr. Adding support for Flash to the front end of my VoxCasa service was an easy two hours of work. But I can not switch it on until I have Flash for all panos published up there, so I scrambled (and am still scrambling) at getting the original equirects again from the photographers. To summarize, your above question is a management problem, not an editing problem. Since TIFF is editing only for me, I don't have this problem. Also very often, throwing technical solutions at management problem results in damagement, for it does not cure the problem at its root: the damager. Every photographer should have a proper filing/archiving system and while I do welcome technical solutions to manage an archiving system, I do not think that they should be mixed up with a specific image format. My two cents. Yuv __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Daniel M. G. <dm...@uv...> - 2006-10-19 14:51:47
|
yuval levy twisted the bytes to say: yuval> To summarize, your above question is a management yuval> problem, not an editing problem. Since TIFF is editing yuval> only for me, I don't have this problem. Also very yuval> often, throwing technical solutions at management yuval> problem results in damagement, for it does not cure yuval> the problem at its root: the damager. Every yuval> photographer should have a proper filing/archiving yuval> system and while I do welcome technical solutions to yuval> manage an archiving system, I do not think that they yuval> should be mixed up with a specific image format. In a way, yes, it is a management problem. But sometimes, when I am experimenting in the creation on one panorama (using hugin) I find that I change settings, create a pano, a change settings again, create another version of the pano, etc. Sometimes I don't recall exactly what options were used for each pano. This will solve the problem, either as a text file, or embedded. The reality is that the scripts are so small that they hardly create a dent on your disk space. I rather have the info, than not. yuval> My two cents. -- Daniel M. German "To take photographs means to recognize --simultaneously and within a fraction of a second --both the fact itself and the rigorous organization of visually perceived forms that give it meaning. It is putting one's head, one's eye and one's heart on the same Henri Cartier Bresson -> axis" http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: yuval l. <yuv...@ya...> - 2006-10-19 15:21:10
|
--- "Daniel M. German" <dm...@uv...> wrote: > sometimes, when I am experimenting in the creation on > one panorama (using hugin) I find > that I change settings, create a pano, a change > settings again, create > another version of the pano, etc. Now this is a case where the feature can be of value! Thank you for opening my eyes. I do this (recursive trial and error stitching) with PTgui too. Being raised in the time before software had multiple undo step, I have the good habit of always storing each set of settings/pano with a sequence number. This feature would make my habit redundant. Dangerous if I output to multiple format and the feature is supported in TIFF only, but I see now some utility to saving the project file *additionally* in the generated pano, as long as it does not disrupt / create incompatibilities with existing workflows. My preferred solution would still be at the GUI level (hugin/PTgui) with an automated sequence number saving, e.g. every time I send a project to stitch, the Gui would also save that project with a clear reference to the output TIFF. > The reality is that the scripts are so small that > they hardly create a > dent on your disk space. I rather have the info, > than not. Hard disk space is the least of my concerns. I just want to make sure that this addition won't break existing workflows. I finally got around to compile panotools 2.8.4 in MinGW, only to be warned by PTgui that it is not compatible. While I understand the trade-off between progress and backward compatibility and I am inclined to favor progress, I believe careful thinking should be applied before breaking established functionality. The additional value of the new feature needs to be weighted against the lost value from broken functionality. I see little additional value for me in the suggested feature; and I see the natural place to implement it as the GUI, not the stitcher. So I try to get an understanding for whether there will be broken functionality as a consequence of this new feature. That said, there is little I can do to influence the development process: you are the one who write the code (and I am thankful for this) so you are the one who ultimatively decides. All I can do is take it or leave it. I am trying to give as much feedback as possible with the intention to generate value for all of us. Yuv __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Bruno P. <br...@po...> - 2006-10-19 21:49:16
|
On Thu 19-Oct-2006 at 08:20 -0700, Yuval Levy wrote: > > I finally got around to compile panotools 2.8.4 in MinGW, only to > be warned by PTgui that it is not compatible. 2.8.4 isn't binary compatible with previous versions. There is a pre-release of 2.8.5 that should behave the same as older libraries: http://panotools.sourceforge.net/snapshots/ ..but this needs some testing by people who actually require the binary compatability before it can be released. -- Bruno |
From: yuval l. <yuv...@ya...> - 2006-10-19 22:17:17
|
--- Bruno Postle <br...@po...> wrote: > ..but this needs some testing by people who actually > require the > binary compatability before it can be released. what kind of testing? maybe I can help? Yuv __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Bruno P. <br...@po...> - 2006-10-19 22:23:08
|
On Thu 19-Oct-2006 at 15:17 -0700, Yuval Levy wrote: > --- Bruno Postle <br...@po...> wrote: > > ..but this needs some testing by people who actually > > require the binary compatability before it can be released. > > what kind of testing? maybe I can help? Only the binary compatability. I don't use PTStitcher or ptgui so I have no way of testing that they still work, 2.8.4 apparently fails completely if you try and stitch with Helmut's PTStitcher. -- Bruno |
From: yuval l. <yuv...@ya...> - 2006-10-20 23:31:46
|
--- Bruno Postle <br...@po...> wrote: > > what kind of testing? maybe I can help? > > Only the binary compatability. I did one preliminary test and I am afraid it does not bode well. I recompiled the 2.8.5 using MinGW because I need FOV>160 for my transformations. Put the new DLL in the system folder. Kicked off PTgui 6.0.3 and loaded a project (six aorund, sigma). Look at the warped thumbnails with 2.8.4: <http://photopla.net/285dll/normal.jpg> and with 2.8.5: <http://photopla.net/285dll/285.jpg> any way I can help you understand what is going wrong? Yuv __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Jim W. <jwa...@ph...> - 2006-10-20 23:54:23
|
yuval levy wrote: > Look at the warped thumbnails with 2.8.4: > <http://photopla.net/285dll/normal.jpg> > and with 2.8.5: > <http://photopla.net/285dll/285.jpg> > > any way I can help you understand what is going wrong? > > Yuv > The Crop or Select parameters are not being used correctly in the 285.jpg version. It believes that the what is visible is your fov not what it was cropped to. -- Jim Watters Yahoo ID: j1vvy ymsgr:sendIM?j1vvy jwatters @ photocreations . ca http://photocreations.ca |
From: yuval l. <yuv...@ya...> - 2006-10-21 00:16:32
|
--- Jim Watters <jwa...@ph...> wrote: > The Crop or Select parameters are not being used > correctly in the > 285.jpg version. It believes that the what is > visible is your fov not > what it was cropped to. thanks for the quick reply, Jim. Can you direct me to where in the code I can find the Crop or Select parameters (i.e. which files and approximately which line numbers)? not that I would dare make any change in the code, but I would like to *try* to read from the code and see if I can help you guys zero-in on this bug. Yuv __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Bruno P. <br...@po...> - 2006-10-21 07:26:20
|
On Fri 20-Oct-2006 at 19:54 -0400, Jim Watters wrote: > >The Crop or Select parameters are not being used correctly in the >285.jpg version. It believes that the what is visible is your fov not >what it was cropped to. Yes, it looks like it has the C and S parameters mixed-up. -- Bruno |
From: Carl v. E. <ei...@gm...> - 2006-10-19 15:41:55
|
Hi Yuv, I understand that you don't need some special new function which is discussed here. But you bought Photoshop and I guess you don't use every single option of that app, don't you? I personally think that storing some more descriptive data inside an image file is very interesting. Nikon's D2X and also the F6 can store not only fov information but also lon/lat coordinates from a GPS attached to those bodies within the EXIF part of an image file (or for the F6 a text file on a memory card). So where is the difference to also store a description about where one single image is located in space in relation to other images of the same set? When do we have cameras with not only the possibility to store simple coordinates but also y/p/r values from some sensors inside the camera? Also a TIFF is AFAIK no very strictly defined format when you don't think of the very special archive TIFF, and that is more or less a fax. My Hasselblad scanner produces 3f or .fff files which I heard is also a TIFF format. Try saving a GIF with an ICC profile in Photoshop. Good chance that this doesn't work but we all know that different file formats are good for different purposes. TIFF is the de facto work file format for our panorama workflows, why not use tricks we can do with it? I like the idea. And I bet this can be realised as an option so you don't have to use it if it doesn't fit in your personal workflow. Carl |