![]() |
|
|
|
|
|
||||||||||
|
| User list | Rules | You are not logged in.
Pages: 1
When saving a pano of whatever size as a 16 bit TIFF, the file appears as a striped gray scale picture in some preview programs and as a black surface in my current picture editor, LightZone.
Doing in LightZone some manipulations to 'brighten" the picture, I get a color negative of the original.
Loading the file into Paint Shop Pro, the picture shows correctly; if I save it as a TIFF from PSP, I get a file i can work with event with LightZone.
I got the problem with zipped and plain TIFF's.
I am used to save TIFF files from other programs and to load them in LightZone, without meeting any problem up to now.
Question: what is the special characteristic of the TIFF file saved by AutoPano? What is the roundabout?
Thanks in advance for any help.
Reto
Offline
It has already been discussed: it seems that APP adds a layer with the preview in the tiff, which disturbs some programs like LightZone (I use it too). You can just generate a png 16 bits, and then convert it to tiff.
Offline
I have a related question about APP and TIFs - maybe this has been discussed too?
When I stitch a large pano using APP and try and render it, APP tells me there is a 2Gb limit on TIFs and will only allow me to save it as a PSB. If I save as a PSB then load the PSB into Photoshop, it will save the file as a TIF with LZW compression. What is going on here? Why can't APP save as a TIF if PSB can? (TIFs with LZW compression is my default setting in APP.)
Is it because PS is interpreting "save as a TIF" as an imperative command i.e. "do whatever you need to do including losing detail to save this picture as a TIF"?
Or is APP missing a trick? This seems unlikely but perhaps APP's estimate of the size is not taking compression into account?
Aeris
Last edited by Aeriscera (2008-09-08 13:00:09)
Offline
We never take into account compression for the moment. In fact, we couldn't because it's content based and at the time of proposal ( rendering dialog box ), we don't have the content.
Offline
Aeriscera wrote:
I have a related question about APP and TIFs - maybe this has been discussed too?
When I stitch a large pano using APP and try and render it, APP tells me there is a 2Gb limit on TIFs and will only allow me to save it as a PSB. If I save as a PSB then load the PSB into Photoshop, it will save the file as a TIF with LZW compression. What is going on here? Why can't APP save as a TIF if PSB can? (TIFs with LZW compression is my default setting in APP.)
Is it because PS is interpreting "save as a TIF" as an imperative command i.e. "do whatever you need to do including losing detail to save this picture as a TIF"?
Or is APP missing a trick? This seems unlikely but perhaps APP's estimate of the size is not taking compression into account?
Aeris
That was a problem in Photoshop. Which version do you use?
best, Klaus
Online
AlexandreJ wrote:
In fact, we couldn't because it's content based [and] we don't have the content.
LOL. Good answer!
Nevertheless it is a problem for me because I want to use APP and the intermediate step of using PS really slows things down. Are you addressing this issue in v. 1.9 and beyond? Eg a direct upload to gigapan.org, or, for preference, some tricksy way of delaying the choice of file format until the content is known?
Aeris
Last edited by Aeriscera (2008-09-08 21:23:26)
Offline
Hi Klaus,
klausesser wrote:
That was a problem in Photoshop
I'm not sure what you are referring to by "that". Do you mean that my suggestion about what PS is doing actually happens?!
I am using CS3.
Aeris
Offline
Aeriscera wrote:
Hi Klaus,
klausesser wrote:
That was a problem in Photoshop
I'm not sure what you are referring to by "that". Do you mean that my suggestion about what PS is doing actually happens?!
I am using CS3.
Aeris
What i don´t understand is: "do whatever you need to do including losing detail to save this picture as a TIF"?
best, Klaus
Online
AlexandreJ answered the question very well so I think we can consider the topic closed?
ps. "do whatever you need to do including losing detail to save this picture as a TIF" - no, TIFF files never degrade the stored image (unless you use JPEG compression in them).
Offline
DrSlony wrote:
AlexandreJ answered the question very well so I think we can consider the topic closed?
?
I asked pertinent follow-up questions regarding what can be done about the limitations of APP.
DrSlony wrote:
ps. "do whatever you need to do including losing detail to save this picture as a TIF" - no, TIFF files never degrade the stored image (unless you use JPEG compression in them).
I could write a piece of code that saves any image as a TIFF occupying less than 100 bytes. This wouldn't be any good because I'd have to throw away nearly all the data to make a file so small, but it would be a valid TIF because it's less than 2GB in size.
Obviously PS doesn't do this, but I thought it might say, "well this file is going to be over 2Gb if I save it in LZW as I was told to do, but what can I do to make a TIF/LZW file that *is* smaller than 2Gb?"
A
Last edited by Aeriscera (2008-09-09 00:41:24)
Offline
". . but what can I do to make a TIF/LZW file that *is* smaller than 2Gb?"
you could resize it . . . . ![]()
btw.: are you talking of "smaller than 2GB" in terms of already compressed (LZW) files? Or do you mean an unpacked 2GB-file - one which is displayed?
Last edited by klausesser (2008-09-09 01:21:07)
Online
Or I could apply a space-saving colour optimisation and approximate every colour as white :-)
KlausEsser wrote:
btw.: are you talking of "smaller than 2GB" in terms of already compressed (LZW) files? Or do you mean an unpacked 2GB-file - one which is displayed?
Well in deference to AlexandreJ's and Dr Slony's remarks, this is purely academic, but I am talking about LZW files. As I understand it, if you have an uncompressed image and then compress it and the resulting file is more than 2GB, then you can't save it as a TIF (using APP and most other software although the limit is technically 4GB).
A
Last edited by Aeriscera (2008-09-09 01:26:17)
Offline
Aeriscera wrote:
Or I could apply a space-saving colour optimisation and approximate every colour as white :-)
KlausEsser wrote:
btw.: are you talking of "smaller than 2GB" in terms of already compressed (LZW) files? Or do you mean an unpacked 2GB-file - one which is displayed?
Well in deference to AlexandreJ's and Dr Slony's remarks, this is purely academic, but I am talking about LZW files. As I understand it, if you have an uncompressed image and then compress it and the resulting file is more than 2GB, then you can't save it as a TIF (using APP and most other software although the limit is technically 4GB).
A
You mean AFTER LZW compressing it´s still more than 2GB? That means about 4GB unpacked . . are you kidding? What kind of picture could that be? A multi-gigapixel-image shot with a compact-camera - made of 5000 shots?? ![]()
Did you see this one - 16 GigaPixel:
http://www.haltadefinizione.com/en/cenacolo/look.asp
and the making of:
http://www.haltadefinizione.com/en/cena … kstage.asp
Online
Aeriscera wrote:
Or I could apply a space-saving colour optimisation and approximate every colour as white :-)
![]()
Wikipedia says this about TIFF: "The Tiff file format uses 32bit offsets, and as such, each file is limited to 4 gigabytes."
The max files size could be limited also by your partition type, operating system and architecture. So the max memory you can address by a 32 bit operating system is 2^(32-1), so 2GB. I don't know why the -1, perhaps someone could explain? Also I don't know why, since you can only address 2GB of memory, can you save a bigger file of a different format. Is it because a file like psb can be internally split into 2GB chunks, so although all the chunks together can add up to e.g. 8GB, the individual pieces are always 2GB?
Since you render huge files I doubt you are saving at 16 bits per channel, but just in case you are, then never save as TIFF using LZW compression or the resulting file will be bigger than if you used no compression at all. PNG works great, but it allows only images with maximum dimensions of 64 000 x 64 000 pixels.
Also see this: APP wiki - Render Settings - Formats
Aeriscera wrote:
I could write a piece of code that saves any image as a TIFF occupying less than 100 bytes.
Well, no, because we're talking about lossless format conversion, and doing that wouldn't be lossless. Compressing using a different compression algorithm, on the other hand, would. (...as long as this different compression method isn't JPEG, because some TIFF flavors allow JPEG compression, so they're not lossless).
In my experience though, most of the time huge panoramas are not nice panoramas. Panoramas that you can actually edit usually can be nicer than those that you cant, since you can fix all errors, bad stitches, dust, blur, ghosting, overall hue, etc etc. I don't know about other APP users, but I do not often get raw files that are perfect in the camera and need no tweaking, that rarely ever happens, probably because most of the time I'm bracketing so that in itself requires lots of work. Most of the huge images I see were done just to beat a record, or I dont know what. www.gigapan.org has some really ugly gigapixels which seems to prove my point. So I'm interested why do you shoot such huge panos? Is it just for the thrill, or you want to see how far you can push your equipment, or what? I sometimes shoot big and render at 75% or even 50% from APP so that I can overcome my lens' max resolution - downscaled panoramas, although still being very big, are sharper than the original 100% image because I don't have a lens for several thousand euro so my shots are not as sharp as ones from expensive prime lenses.
Offline
klausesser wrote:
You mean AFTER LZW compressing it´s still more than 2GB? That means about 4GB unpacked . . are you kidding? What kind of picture could that be? A multi-gigapixel-image shot with a compact-camera - made of 5000 shots??
Well, it's a bridge not a compact and it's only 386 shots, and it probably doesn't qualify as a panorama in your eyes :-) but "yes". Here it is http://share.gigapan.org/viewGigapan.php?id=8792.
2Gb for a compressed TIF is nothing for us hard-core gigapanners ![]()
Aeris
Last edited by Aeriscera (2008-09-09 04:23:13)
Offline
Hi DrSlony,
Thanks for your useful comments on TIFs.
DrSlony wrote:
In my experience though, most of the time huge panoramas are not nice panoramas [...] www.gigapan.org has some really ugly gigapixels
Gigapan.org is not about art or even good photography but documentation and sharing. Richard Palmer speaks well on this topic - I'll ask him to post something if he has time.
Aeris
Last edited by Aeriscera (2008-09-09 04:36:34)
Offline
DrSlony wrote:
In my experience though, most of the time huge panoramas are not nice panoramas [...] www.gigapan.org has some really ugly gigapixels
Aloha APPro afficionados,
Just back on line after a power supply and mother board burn-out. I took the plunge into 64 bit computing, although I didn't get my dream Mac Pro with 32 gigs of RAM. Now using Vista Ultimate, AMD64 dual core processor, and 8 gigs of RAM. I'm currently testing out the Alpha version of the Giga-APPro. A 42C x 11R image is aligning now (15 Sept.), and I hope to render it on 16 Sept.
Responding to DrSlony, in regards to "ugly" gigapixels:
Since I take large panoramas (usually), I suspect that some of your ire is directed at me. As an initial beta tester (since July 2007), and Fine Family Foundation grant recipient through Carnegie Mellon University (CMU), it is expected of me to push the GigaPan unit, and compatible cameras, to their limits, both with image size and complexity. I also don't take gigapans, necessarily, to try to make a living. I shall not soon give up my day job as an Environmental Health Specialist for the Hawaii Department of Health. My main impetus for using the GigaPan is for education and scientific documentation, and occassionally just for fun.
Please look at the gigapan.org website to learn more about the GCP (Global Connection Project), a joint effort between CMU, NASA, National Geographic, and Google. I don't expect it to change how YOU expect to make an image (and I wouldn't want to do that), there is just a difference in philosophy about what may be desireable, or acceptable, in an image meant to educate, and or entertain, rather than one from which a profit is made (although I fully understand that the concepts are not mutually exclusive). The GigaPan web site is open to all panorama makers to upload his/her work to, with the only conditions being that you register at gigapan.org and that your panorama is >.05 gigapixels. The image need not be take with a GigaPan unit either. Just because the gigapan.org viewer allows one to zoom in >100% doesn't mean that you MUST. Gigapan.org is much more egalitarian than many of you on this forum seem to be able to endure. Too bad, you miss out on so much fun!
I'm also a liason between the gigapan team and Kolor in the development of a GigaPan friendly version of APPro, where prerendering tools are rather sophisticated, but alignment of very large image arrays still leaves a bit to be desired.
That's all for now.
Regards,
Richard Palmer (Apapane)
http://gigapan.org/viewProfile.php?userid=319
Offline
I couldn't agree with you more Apapane. I would also add there is a fine sense of community amongst the gigapanners, and that to complain about the quality of gigapans is akin to complaining about the quality of videos at YouTube. I have to confess that every time someone sends me a link to something they have spotted at YouTube, my first reaction is "what a dreadful video" but that is not the point of YouTube (as was pointed out to me on this very forum).
Apapane wrote:
My main impetus for using the GigaPan is for education and scientific documentation, and occassionally just for fun.
If it wasn't fun I wouldn't be doing it, but now that I am getting somewhere I am thinking more seriously about the documentation aspect.
K
Offline
Eh seems we have a big misunderstanding Apapane. So several points:
Apapane wrote:
I suspect that some of your ire is directed at me
On the contrary, there wasn't much emotion whatsoever in what I wrote. Stating that "most of the time huge panoramas are not nice panoramas," is just matter-of-fact. Also please note that "most", not "always". If you would like, I could list many urls to "huge panoramas" and point out why they're not nice, list all the errors, but then again that would be getting somewhat involved, which is not something I want to do, which is why I'm writing this reply - in hope to end the misunderstanding :]
Apapane wrote:
there is just a difference in philosophy about what may be desireable, or acceptable, in an image meant to educate, and or entertain, rather than one from which a profit is made (although I fully understand that the concepts are not mutually exclusive)
Well of course, but that is not the issue. The issue is me saying that most big panos aren't nice aesthetically.
Apapane wrote:
Gigapan.org is much more egalitarian than many of you on this forum seem to be able to endure.
Umm that doesn't sound nice and I can't agree, but I decided that discussing this point could get more unfriendly so I wont :]
Making huge panoramas sure can be fun, as with breaking any records. I also recently posted 2 panoramas here - my longest pano ever, and my hardest pano ever. Both are ugly, but it was sure fun making them, breaking my own records and learning from my mistakes. Same as it is, I suppose, with many gigapan.org users. But the fact that it's fun and blabla doesn't make those 2 panos of mine, or theirs, any nicer :] Bad stitching is bad stitching, ugly light differences are just that - ugly. Pleasing and challenging though it may be, you cant get wine from a cow just because you have some expensive equipment that can break records. But then I never said that milk isn't fun :]
Regards and in hope of better understanding on friendlier terms
Maciek Dworak
Offline
DrSlony wrote:
... Regards and in hope of better understanding on friendlier terms
Maciek Dworak
I certainly don't want to put some wood in a potential fire that doesn't stick to this forum philosophy and friendship. That's why I'll not reply point to point.
DrSlony is never a contributor to show any "ire" but always "positive", open minded.
Apapane, if you want to nicely discuss and bring your ideas while accepting some remarks, just show what you are : a beautiful person. ![]()
Offline
Marco,
This is a frustrating thread for me because I like gigapan and I think it is valuable, but it seems to me that some people that post here don't seem to get the point of it. I could of course say "That's their loss" and get on with the rest of my life. However, this forum is about a tool that I'd like to use for contributing to gigapan, so I have to contend with people who post here and, in my opinion, some of them are routinely and unnecessarily dismissive of the panos at gigapan.
In particular, it seems to me that whenever I raise questions concerning large images and the problems of processing them, I encounter an automatic resistance to the idea that anything good can be achieved by attempting to work with a gigapixel image. Sometimes - and here I am not referring to DrSlony's post in this thread - people make rude, arrogant and elitist remarks. Perhaps insult is not intended on these occasions, but the fact is that some people are arrogant and insensitive.
DrSlony,
With regard to your contribution, there is no doubt that you are an expert, you bring a lot to this forum and have a sense of humour which is always welcome and I think you could bring even more to the group if you read up on what gigapan is all about. To me, gigapan's scope and ideals are worthy and exciting and it's fun to do! May I suggest that you look upon gigapan as different from, but not unadjacent to what you do? Current technology prevents gigapanners from treating their images with the skill and care that you exercise on your images, but that doesn't mean we don't want to. Indeed, the reason I participate in this forum is to ask how you guys can help me get closer to what you are already doing.
Aeris
Offline
Maciek and Marco,
For the time being, I think we can agree to disagree on what we consider criteria for "good" panoramas. You both have your opinions, I have mine. With my background in botany and ecosystem ecology, I value detail and "explorability". If a large panorama documents what is necessary for my work, it needn't be pretty, although that's a definite plus. I do hope that both of you do more research into the development of the GigaPan unit within the context of Carnegie Mellon University's Global Connection Project. http://gigapan.org/about.php
I also hope that you get the opportunity to use a GigaPan unit - to take a panorama with a telephoto lens rather than a wide angle lens. As it stands now, the GigaPan is another tool in the Panorama takers box of goodies. It is certainly not the only game in town, but it may well be one of the easiest to use (it's self contained - needs no external computer hookup, and runs on AA batteries). I would be most interested in your thoughts once you learn more about "GigaPanning", and especially if you have the opportunity to use one.
Aloha for now,
Richard
Offline
rhadorn wrote:
When saving a pano of whatever size as a 16 bit TIFF, the file appears as a striped gray scale picture in some preview programs and as a black surface in my current picture editor, LightZone.
I am used to save TIFF files from other programs and to load them in LightZone, without meeting any problem up to now.
Question: what is the special characteristic of the TIFF file saved by AutoPano? What is the roundabout?
Reto
Hello,
As far as I see in this first question the issue encountered by Reto, for his first question, is quite far away from the use of a motorized pano head… This becomes a little out of topic for him…
Here are a couple of links concerning the use of Tiff files when rendered with APP. There are lots of threads talking about that… Just search on the word - Tiff - and author - AlexandreJ -
http://www.autopano.net/forum/p5520-200 … 9-19#p5520
http://www.autopano.net/forum/p13707-20 … -54#p13707
Last edited by beeloba (2008-09-17 11:44:52)
Offline
Pages: 1
Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
|
CHOOSING KOLOR Why choose Kolor? Which solution to choose? Download a trial Where can I buy? Education |
SOFTWARE Autopano Pro Autopano Giga Panotour Panotour Pro XnView |
ACCESSORIES Training DVD Panobook PROJECTS Paris 26 Gigapixels Yosemite 17 Gigapixels |
COMMUNITY Forums YouTube channel Google+ |
COMPANY Blog About Kolor Resellers Contact Visit us |
PRESS Press center Press review TOOLS My account |
