Resolution 101 Feat. The Tourist Guy  

Share your tips and tricks here or get help with any Autopano Pro / Giga problem!
No bug reports (of any kind) in this forum!
no avatar
arnaud.dk
Member
 
Posts: 63
Likes: 0 post
Liked in: 0 post
Joined: Thu May 24, 2007 4:34 pm
Location: Rennes / France
Info

by arnaud.dk » Sun Feb 22, 2009 11:39 pm

Hi everybody,
I agree all the above about the hardware influence on stitching time, but what about trying to compare rendering on windows and linux with the same configuration. You should be surprised on the difference (i did) ! and the cost is 0€/$. This could be an argument which can save many effort.

Best regards,
Arnaud.

User avatar
klausesser
Member
 
Posts: 8836
Likes: 5 posts
Liked in: 64 posts
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany
Info

by klausesser » Sun Feb 22, 2009 11:57 pm

Hi Henrik!

A friend of mine had the same problem - untill he had the drives changed from 4x1,5TB to 4x1TB. Now it´s fast enough as a backup-device. The 1,5TB drives produced problems - the Drobo was VEERY slow . .

best, Klaus
Simplicity is the keynote of all true elegance. Coco Chanel

User avatar
[bo]
Member
 
Posts: 1226
Likes: 0 post
Liked in: 0 post
Joined: Fri May 05, 2006 8:16 am
Location: Bulgaria
Info

by [bo] » Mon Feb 23, 2009 9:53 am

Yah, I know of the problems Drobo has with some of the drives out there. I've done my homework and I'll probably be using Velociraptors, but I don't expect a top-of-the-line or industry-grade performance. It's the wrong way to look at a Drobo - this device is just a hassle saver. What if I'm on a project for a month, out of town, and the RAID I've setup on a Linux machine fails? No one in my office can fix that. With the Drobo - just replace disk.


Arnaud, could you share some timing info? I'm very intrigued by the possibility to render under Linux, if that speeds the times 50%, but anything less will be too much of a hassle for my rather small panos anyway.
Some of my panoramas, posted in the Autopano Pro flickr group.

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 4:46 am

VRabbit wrote:I am looking to really speed up the time of this and any settings that can be mentioned will really help.

Dection Settings. Having more than one instance decetion will this help decrease total time spend on stitiching several tours?

Aligrithums any sugestions.

I want to use smartblend because its great.

1st image before using AutoPano...2nd Image during use... Hoping it will help illustrate the use of RAM and how its not using to much.

Want some simple advice?

If you want to use smartblend (and why not, the IQ is much better than multiblend) the way to do it is to put the APP temp folder on a *ramdrive*.

If you do this not only will you use your memory more effectively but you will use your cpu & money more effectively.

You can do this with a ramdrive either in Win32 or in Linux...I went the Linux route for a number of reasons.
The basic constraint is that for every 1MP of image data in the final render, you need about 100MB [ note I said 20:1 before which is wrong, please check the math here] of free space in the APP temp partition, thus with a 2GB ramdrive you can render panos up to about 20MP. The batch-renderer will not render the job with smartblend unless enough space is on the temp drive to do it.

Now, rendering a 100MP pano will take quite a while...but even with a ramdrive and all cores cranking away at 100% you will still only see about a 30% reduction in render time over using a single 5600rpm drive. But still you can do this for free (at least until May 9) so why not? It's going to beat a Raid0 array any day of the week. And for panos much larger than 100MP it will take so long that it won't really matter. APP 1.4 just isn't that efficient.

First the ramdrive....Linux has a ramdrive that you can set up either as a static ramdrive at boot time or as a reloadable module. The instructions are easy to find on the net.

I used this one with XP-32:
http://members.fortunecity.com/ramdisk/Download/download_and_buy.htm

(1) This version is a 32bit operating system can use the trial version to 2009.1.24 (The author will use the period of the new quarterly release version)
(The disadvantage is that occasionally opened to use the opportunity to beep out the window to remind you jump out of its existence, there is an exclamation point there will be a yellow triangle logo appears in your lower right corner)
http://members.fortunecity.com/ramdisk/Download/RAMDisk_Evaluation_x86_530110.zip

(2) This version is a 64bit operating system can use the trial version to 2009.1.24 (The author will use the period of the new quarterly release version)
(The disadvantage is that occasionally opened to use the opportunity to beep out the window to remind you jump out of its existence, there is an exclamation point there will be a yellow triangle logo appears in your lower right corner)
http://members.fortunecity.com/ramdisk/Download/RAMDisk_Evaluation_x64_530110.zip

(3) This version does not restrict the use of the period, but only 64MB of setting RamDisk space:
(Windows 2000 / Windows XP / Windows Server 2003 / Windows PE applicable)
http://members.fortunecity.com/ramdisk/Download/RAMDisk_Evaluation_52102PRO.zip

They have a version that works in Vista64. it's easy to set up, and you can start it, stop it and resize it all from the desktop.

The way to control how much ramdrive you need is to control the size of the final render using the % slider.

You can set this up in about 15 minutes.

good luck


...the 2nd question is does it make sense to use more than 2 cores to do the rendering. I say no because they will compete for the memory bus. It might even be faster to just use one core for the rendering and leave the 2nd core for the system (generally-speaking 4 cores can really only be used efficiently for processes that run in core or maybe L2 cache at most). You may want to check your OS prioritization and set it up for optimal processing of background processes otherwise the cores will hang waiting for the system to manage i/o (which will happen faster with the ramdrive, but not if the render process is monopolizing the system, and this will determine whether the system is bus-limited by the background i/o management or by the foreground render io). But you can track the overall performance and see what works best for you. You should be able to get at least 2 cores running at 100%. Adding more render threads will just make it completely i/o bound, I doubt that there is any benefit to this as that should happen with just one render thread.

Also as APP will let you reserve up to 1/3rd of total system ram, in an 8GB 64-bit system you might be better off setting it to only 1GB (that's plenty to render a pano that you've already detected and prerendered) and using say 4 or 5GB for the ramdrive. You should leave some for the disk cache and other processes. Also there are some registry flags that you might want to play with that enable the OS to move system processes out of the pagefile for maximum performance.

FYI the reason that more disk cache doesn't help much is that you are writing so much to the drive, it still has to flush all that data...while the cache may be large enough to effectively read-cache the IO required to render high-resolution panos, the flushing process takes cpu cycles to complete. But there's no need to flush it at all...it's all temp data anyway. It will still use the disk cache to buffer the source images and final pano, so it's not all wasted :)


ps I'm completely with you on not using raid0 unless absolutely necessary (and it rarely is) but on the raw vs jpg/tiff issue there are pluses and minuses to using raw sources vs jpg.

I'd work with the jpeg until I get fully through with editing the pano and then switch to raw sources for a number of reasons. Otherwise you have two sets of files to keep track of. I always sort my jpegs by location and I never sort my raw files. Luckily it's fairly easy to modify the pano config files to point to raw sources instead of jpegs especially if the only difference is the extension.

Of course APP won't let you set the dcraw settings but it can't do worse with raw files than it can with jpegs or tiffs, can it?

But if you want *the best* output you're going to have to use raw sources and render to tiff and that's going to, well, I don't really know what that is going to do to the space requirements...but again if you're looking for top IQ then you won't mind rendering your desired high-MP pano on a drive with raw sources and outputting it to tiff. It's going to take a LONG while anyway. Speed and quality are somewhat mutually-exclusive. Still on *that* note the question becomes is it better to render to 4MP than to render to 1MP and upsample to 4MP externally? It's going to be a *hell* of a lot faster. If you use something good like BlowUp! or Qimage that will let you upsample say 800% with barely any discernable difference in IQ when viewing full-image, I don't see it making any sense at all to render to that final resolution. You'd have to want to pixel-peep the final pano for that to make sense.

And like all things digital, the quality of the final product doesn't really scale with sampling-rate.
Last edited by touristguy87 on Tue Feb 24, 2009 11:01 pm, edited 1 time in total.

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 7:23 am

tived wrote:a word of warning, regarding the drobo, we have one with 4 Samsung f1 disks in it, running in a Mac environment, we have the network module as well.

One word - SLOW!!!! and the samsung F1 disks are not slow.

any chance that it's slow because it's set up as RAID5 not as a 4-disk or 2x2 RAID0 rig, maybe RAID0/1 even?

it might even be set up as a volume spanning 4 disks.

It's *definitely* going to be slow if it's set up as NAS...
Last edited by touristguy87 on Tue Feb 24, 2009 7:24 am, edited 1 time in total.

User avatar
[bo]
Member
 
Posts: 1226
Likes: 0 post
Liked in: 0 post
Joined: Fri May 05, 2006 8:16 am
Location: Bulgaria
Info

by [bo] » Tue Feb 24, 2009 12:13 pm

It's not slow because of the RAID type (which, in Drobo's case is some proprietary development on RAID5 of Data Robotics, not classic RAID5), but because of the problems Drobo has with some newer (usually bigger) HDD models. That's until the firmware catches up - usually they push a new version that has better support for the latest drives pretty quick.

Anyway, your suggestion for ramdrive is a nice one, but only in case you have larger RAM amounts (16GB for example) OR work with smaller projects*. On a 8GB RAM system, you probably cannot use more than 4GB as a ramdrive and that won't hold any bigger projects. Have in mind Smartblend renders as TIFF files* even if you set JPEG as an output format, then the resulting render is JPEGed.

---
* Actually, Smartblend used to produce a TIFF file that's big as the whole pano for each individual input file. Example: you have a pano of 20 images, each of those 6MP (that's about 17MB TIFF file) shot. The resulting pano is 60MP (170MB file), with overlap and cropping considered. When rendering with Smartblend, you are going to get 20 TIFF files, each of them 60MP large (a total of almost 4GB files), and just after all TIFF files are complete, the actual Smartblend-ing will commence. And that will produce some more intermediate temp files, and finally, a composite TIFF file will be created (and optionally JPEGed). So that's about it.
Some of my panoramas, posted in the Autopano Pro flickr group.

User avatar
klausesser
Member
 
Posts: 8836
Likes: 5 posts
Liked in: 64 posts
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany
Info

by klausesser » Tue Feb 24, 2009 12:39 pm

'[bo wrote:']Actually, Smartblend used to produce a TIFF file that's big as the whole pano for each individual input file. Example: you have a pano of 20 images, each of those 6MP (that's about 17MB TIFF file) shot. The resulting pano is 60MP (170MB file), with overlap and cropping considered. When rendering with Smartblend, you are going to get 20 TIFF files, each of them 60MP large (a total of almost 4GB files), and just after all TIFF files are complete, the actual Smartblend-ing will commence. And that will produce some more intermediate temp files, and finally, a composite TIFF file will be created (and optionally JPEGed). So that's about it.

Hi Bo!

Bigger projects i render overnight - no problem. The very longest render-time i had was 2,5hours for a 700MPx pano ( i always use smartblend).

What´s really a point is the speed of geometrical corrections and some others in the editor. Here only one core is used as i learned. Why?

best, Klaus
Simplicity is the keynote of all true elegance. Coco Chanel

User avatar
[bo]
Member
 
Posts: 1226
Likes: 0 post
Liked in: 0 post
Joined: Fri May 05, 2006 8:16 am
Location: Bulgaria
Info

by [bo] » Tue Feb 24, 2009 1:00 pm

Well, if you follow John Nack's blog on Photoshop, you probably know there are certain tasks that cannot be multi-threaded or split to several processes/cores. I personally am happy with the GPU direction APP is taking - the interface in 2.0 will be really responsive for most people with recent hardware out there.

I've described my workflow numerous times... Smaller project (up to 10 5D files) I render in background while working on other panos. Larger projects render in matter of minutes, rarely hours. Render time is not an issue with me also - just trying to help fellow forumers here. So the interface / pano composition part is more important and 2.0 will bring huge improvements in that area.

But the topic is about stitching time - let's try stay on that. My general advice is to get a pano head and render with Multiband, so you don't have to worry about HDDs bottlenecking the process, or just find a way to speed up your HDD for Smartblend - either by manual RAID setup, by a Drobo alternative, by ramdisk for smaller projects, or even by a simple Velociraptor.
Some of my panoramas, posted in the Autopano Pro flickr group.

User avatar
klausesser
Member
 
Posts: 8836
Likes: 5 posts
Liked in: 64 posts
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany
Info

by klausesser » Tue Feb 24, 2009 1:13 pm

'[bo wrote:']I personally am happy with the GPU direction APP is taking - the interface in 2.0 will be really responsive for most people with recent hardware out there.

Yes - i referred to 1.4.2

'[bo wrote:']So the interface / pano composition part is more important and 2.0 will bring huge improvements in that area.

Yes - it´s remarkable seen in the Alpha already.

'[bo wrote:']But the topic is about stitching time - let's try stay on that. My general advice is to get a pano head and render with Multiband, so you don't have to worry about HDDs bottlenecking the process, or just find a way to speed up your HDD for Smartblend - either by manual RAID setup, by a Drobo alternative, by ramdisk for smaller projects, or even by a simple Velociraptor.

What has smartblend to do with stitching? Or do you mean the whole process (stiching/rendering) when you say "stitching time"?

best, Klaus
Simplicity is the keynote of all true elegance. Coco Chanel

User avatar
[bo]
Member
 
Posts: 1226
Likes: 0 post
Liked in: 0 post
Joined: Fri May 05, 2006 8:16 am
Location: Bulgaria
Info

by [bo] » Tue Feb 24, 2009 1:54 pm

klausesser wrote:Or do you mean the whole process (stiching/rendering) when you say "stitching time"?

Yep, that's technical misunderstanding, because in Bulgarian the term "to stitch a panorama" refers to the part of the process after you hit the "Render" button. The previous part is usually known as "to compose a panorama" or "to make it".
Some of my panoramas, posted in the Autopano Pro flickr group.

User avatar
klausesser
Member
 
Posts: 8836
Likes: 5 posts
Liked in: 64 posts
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany
Info

by klausesser » Tue Feb 24, 2009 3:28 pm

'[bo wrote:']
klausesser wrote:Or do you mean the whole process (stiching/rendering) when you say "stitching time"?

Yep, that's technical misunderstanding, because in Bulgarian the term "to stitch a panorama" refers to the part of the process after you hit the "Render" button. The previous part is usually known as "to compose a panorama" or "to make it".

Ah - i see! Thanx.

best, klaus
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 6:38 pm

'[bo wrote:']It's not slow because of the RAID type (which, in Drobo's case is some proprietary development on RAID5 of Data Robotics, not classic RAID5), but because of the problems Drobo has with some newer (usually bigger) HDD models. That's until the firmware catches up - usually they push a new version that has better support for the latest drives pretty quick.

Anyway, your suggestion for ramdrive is a nice one, but only in case you have larger RAM amounts (16GB for example) OR work with smaller projects*. On a 8GB RAM system, you probably cannot use more than 4GB as a ramdrive and that won't hold any bigger projects. Have in mind Smartblend renders as TIFF files* even if you set JPEG as an output format, then the resulting render is JPEGed.

---
* Actually, Smartblend used to produce a TIFF file that's big as the whole pano for each individual input file. Example: you have a pano of 20 images, each of those 6MP (that's about 17MB TIFF file) shot. The resulting pano is 60MP (170MB file), with overlap and cropping considered. When rendering with Smartblend, you are going to get 20 TIFF files, each of them 60MP large (a total of almost 4GB files), and just after all TIFF files are complete, the actual Smartblend-ing will commence. And that will produce some more intermediate temp files, and finally, a composite TIFF file will be created (and optionally JPEGed). So that's about it.


ps: I've merged your posts, *PLEASE* try to use the Edit function - this flooding of topic with consecutive posts is not proper behavior here.

"ps: I've merged your posts, *PLEASE* try to use the Edit function - this flooding of topic with consecutive posts is not proper behavior here."

...you want to know how may times I edited those posts? Honestly?

You know, it quite thoroughly annoys me when people like you come behind me after I've spent a good hour trying to explain a technical detail well, to nitpick about the fact that I did it over 3 posts instead of in just one. Why don't you just write all the replies from now on and then you can format them all to suit your arbitrary issues? How many posts have you made in this thread alone?

Regarding this extraneous information, that's fairly unnecessary and irrelevant here. Just render the pano first at something low like 20% and you can see just how much temp-space APP needs to render that pano. That will scale directly with the MP of the final pano. If it did not then APP would require a fixed amount of temp space regardless of the resolution of the final pano...which would be even better! If that was the case, once you get it to work on a ramdrive you could render panos at any desired resolution with that same ramdrive. Trust me that's not the case with both APP 1.42 and the AG 1.9 beta.

The only reason to not use a ramdrive would be if you want a pano at such a high resolution that you simply can't get APP to build it on the largest ramdrive that you can configure on your system, without forcing the system to page during the render (there's a point where you are using too much system memory altogether and forcing the system to page). That's all there is to it. Any other method will be slower. But this is playing in the margins, the difference between a 90MP pano and a 100MP pano is trivial but that could mean a difference of 200MB in temp-space requirement. That could keep it from paging, right there.

You want a 500MP pano, try a 16-20Gig ramdrive in a 24GB system. It's just not hard.

Wasn't it just the other day that someone here was telling me that you can't expect a P4 system with 512MB of ram to process 10GB worth of image-data well? :)

You don't want to use RAID0, get a computer with sufficient memory to render the pano that you want, all in memory. Or try another package. Or rethink your MP requirements for the pano and upsample later.

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 6:52 pm

klausesser wrote:
'[bo wrote:']Actually, Smartblend used to produce a TIFF file that's big as the whole pano for each individual input file. Example: you have a pano of 20 images, each of those 6MP (that's about 17MB TIFF file) shot. The resulting pano is 60MP (170MB file), with overlap and cropping considered. When rendering with Smartblend, you are going to get 20 TIFF files, each of them 60MP large (a total of almost 4GB files), and just after all TIFF files are complete, the actual Smartblend-ing will commence. And that will produce some more intermediate temp files, and finally, a composite TIFF file will be created (and optionally JPEGed). So that's about it.

Hi Bo!

Bigger projects i render overnight - no problem. The very longest render-time i had was 2,5hours for a 700MPx pano ( i always use smartblend).

What´s really a point is the speed of geometrical corrections and some others in the editor. Here only one core is used as i learned. Why?

best, Klaus

...that's quite interesting because I have almost the opposite situation.

I rarely if ever use the editor (even if it's slow, without GPU rendering, that's not the issue...there's very-little of real use that one can do in it) and I couldn't get a 700MP pano out of this thing (1.5GHz Core Duo laptop with 5600rpm hard drive and DDR2-533 ram) in less than 3 days.

There's no way in hell it would render even a 100MP pano using smartblend in 2.5 hours.

But that was before using XP, I don't know what it will do using Ubuntu.

I still say why do you need a 700MP pano when you can just render to say 200MP and use BlowUP! to produce a 700MP upsample in about 5 minutes. But if you can do it in 2.5 hrs more power to you. But then why not render it to 1GP in 3 hours. You just spent 120 minutes rendering it, why not take 150min and be sure that you have enough image-data. That's what kills me...it's so *stupid* to talk about rendering these huge files when you can just upsample it by 200% or 400% in seconds with hardly any noticable loss of quality. Sure if you put your nose *right next* to it you can tell that it's been upsampled...but it's still going to be only 55DPI even at 700MP! Why don't you need 90dpi, 150dpi? Whatever.
Last edited by touristguy87 on Tue Feb 24, 2009 7:57 pm, edited 1 time in total.

User avatar
[bo]
Member
 
Posts: 1226
Likes: 0 post
Liked in: 0 post
Joined: Fri May 05, 2006 8:16 am
Location: Bulgaria
Info

by [bo] » Tue Feb 24, 2009 7:29 pm

I'm replying to let you know publicly your two posts in this topic will be deleted tomorrow, because they show much ignorance and provide misleading information.

I'm straining in my attempt to understand your motives and explain myself and this will be my last attempt, as I'm sure you won't really comprehend (or at least) my point of view.

Consider that a fair warning - I will delete future posts that I do not see fit the tone or topic of discussion. Have in mind I've been asked by four respected forum members to ban you and received numerous reports. Please know I don't do because I enjoy it or because I'm evil, but I have to oversee the forums and keep things moderate(d). And also I have common sense.

---
That's my reply to your posts. I hope you read it before tomorrow. I'm locking the thread until tomorrow, as I have little doubt if I leave it open I'll find it with 6 or 7 of your offensive posts one after another...

The thread will be opened again tomorrow, after I clean it up.
---

You cannot render 100MB file and upscale it 5 times without loosing crucial detail and image information. I've seen this argument in previous posts but I've refrained from intervening, as those we situated in your thread. Your talk of DPI shows complete lack of knowledge. And all this talk of not seeing the difference... The whole purpose of panoramas is getting more "image" into the same "file" and you're destroying that with those arguments.

And you keep posting as if everyone uses APP the way you do, but the fact is - they don't. I doubt anyone else reading here will upscale images in TIMES. I doubt anyone is NOT using the panorama editor - probably the most useful part of APP.

There's no way in hell it would render even a 100MP pano using smartdrive in 2.5 hours.

Not sure what you mean by smartdrive, I assume it's smartblend. There's way, believe me. People've done it. I've done it.

First you say you won't render big panos, when you have upscaling. That's OK, it's your choice. But why you insist everyone else is doing it wrong? Let all of us be wrong and do it the way you want.

Then you complain about APP not handling 10GB of images - why would you feed 10GB of images to the software and then render 10MP pano? If those are thousands of small panos - your problem is with the file structure and you can solve it by feeding the images to APP in predefined sets. Yes, the software cannot handle each and every case automatically. We all know that and nobody expects the opposite.

All your talk on ramdrive, raids, ram size, etc - that's not relevant to your problem or ANYBODY'S problem. You won't solve the "APP cannot process my 10GB of family photos" issue by hardware means. I honestly believe that. So why do you engage in a discussion, when you cannot solve your problem by talking about it - 16 gigs of ram won't help you, raids won't help you, talk won't help you, whining about APP problems to the developers won't help you and with that attitude of yours - nobody on this board will.

Regarding ramdrive - I've already wrote that it can be useful to some extent. But to put everything in RAM is not feasible in large projects. Systems with over 16GB RAM scale up rapidly in terms of cost. What's much more accessible is HDD space. And you need plenty of space (hundreds of gigabytes) for large projects. No matter what you might think you're achieving with upscaling.
Some of my panoramas, posted in the Autopano Pro flickr group.

User avatar
klausesser
Member
 
Posts: 8836
Likes: 5 posts
Liked in: 64 posts
Joined: Mon May 22, 2006 12:18 am
Location: Duesseldorf, Germany
Info

by klausesser » Tue Feb 24, 2009 7:37 pm

touristguy87 wrote:I still say why do you need a 700MP pano when you can just render to say 200MP and use BlowUP! to produce a 700MP upsample in about 5 minutes. But if you can do it in 2.5 hrs more power to you. But then why not render it to 1GP in 3 hours. You just spent 120 minutes rendering it, why not take 150min and be sure that you have enough image-data. That's what kills me...it's so *stupid* to talk about rendering these huge files when you can just upsample it by 200% or 400% in seconds with hardly any noticable loss of quality. Sure if you put your nose *right next* to it you can tell that it's been upsampled...but it's still going to be only 55DPI even at 700MP! Why don't you need 90dpi, 150dpi? Whatever.

1) Upsampling means interpolation and interpolation deals with non-existant "information". The quality is not up to my standard and the one of my clients. Period.
2) As i stated: rendering time is not a real problem for me: i start batch-rendering in the evening and let it run over night resp. i start it and have lunch - when i come from lunch it´s finished.
My Mac G5 2x2GHz 64bit-DualProcessor with 8GB RAM and 2 fast HDs inside is going well with rendering.
3) You´re (again) talking offensively about things you don´t understand at all. I´m not tyoing around as an amateur - i have to deliver first-class quality and get first-class paid for it.
4) no question: professionals recognize upsampling of more than 25%. And i would commit a kind of professional suicide if the clients wants 700mpx and i´d deliver it by upsampling a 300mpx file . . no serious professional is crazy - and criminal - enough to act this way and charge the fee for 700GPx.
5) printing a photography first class means to have a NATIVE resolution - consisting of OPTICAL resolution and the related 1:1 amount of pixels.

There´s absolutely no need for pixels upsampled for numbers! You need OPTICAL information - razor-sharp lenses to catch details optically and store it as pixels 1:1 in best quality.
Interpolation, upsampling is a cheap substitute for quality. Up to 25% is okay - above that it´s unprofessional. I know and tried every high-profile upsampling application.

So it´s ridiculous trying to teach me better about my profession - which i´m in for about 30 years. You don´t even have the remotest idea about it and it´s demands in terms of quality.

best, Klaus
Simplicity is the keynote of all true elegance. Coco Chanel

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 7:56 pm

"
There's no way in hell it would render even a 100MP pano using smartdrive in 2.5 hours.

Not sure what you mean by smartdrive, I assume it's smartblend. There's way, believe me. People've done it. I've done it. "

I was referring to my machine. Did I state that in a confusing manner?
My machine wouldn't have a ghost of a chance of rendering even a 100MP pano in 2.5 hrs using smartblend and RAID0, not to mention a *700*MP pano.
And with a 2GB memory limit at the motherboard, there's no way that I can do it in a ramdrive on this machine.

You are free to alter or delete my posts for any reason that you wish. It's not my forum, and I am not the moderator.
If in your role as the assigned moderator to this form you wish to alter or delete my posts for any reason that you see fit, clearly you have the power to do so.
Why do you feel that it is necessary or even a good idea to explain this?

Perhaps you have some confusion about the issue of forum-moderation?
I'd suggest taking this up with the forum-owners, not airing your thoughts on the forum.
Last edited by touristguy87 on Tue Feb 24, 2009 8:13 pm, edited 1 time in total.

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 8:11 pm

"So it´s ridiculous trying to teach me better about my profession - which i´m in for about 30 years. You don´t even have the remotest idea about it and it´s demands in terms of quality."

...and you know this for certain? Or are you just making an unfounded assumption, one could even say "borderline-offensive"?
But I'm not so easily offended.

Anyway I am *asking* you why you or anyone else would need to render a 700MP pano instead of using a quality upsampling process on a 200 or even 400MP pano.
To reply that I am ignorant of the reasons why (and their significance) is to avoid the question and descend to the level of a personal analysis.

To the point...of course there are issues both ways. One can double or quadruple the rendering time and generate panos of higher resolution, or quarter it and generate panos of lower resolution. I'm just trying to understand why specifically 700MP for a print at 55dpi, to be direct.

Of course the quality of the upsampling and the available processing-time would affect the decision on how to handle this.

On a side note, have you *seen* the quality of upsampling that can be done with BlowUP! or Qimage? I really doubt that they would be able to tell if you upsampled it to 200% even using some generic interpolation algorithm. 400% maybe, but BlowUP! and Qimage are *really* good.

As far as the quality of the lenses etc that's your call. I'm sure that you have specific requirements in terms of line-pairs per picture-height and circle of confusion at a measured distance ;) (all of which would merely be complicated dramatically by the pano process but that's a side-point)

...but the simplest & most-effective way to reduce rendering time is to merely reduce the MP of the final image that APP produces and then upsample it with an external editor. With a pano-head and software you can easily generate 10GP worth of source image data. You still have to render that, and my question is to what criteria do you decide to do it to 55dpi but not 25dpi & upsample or render it to 100dpi. I really don't see an answer to that in your post.
Last edited by touristguy87 on Tue Feb 24, 2009 8:19 pm, edited 1 time in total.

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 8:21 pm

"1) Upsampling means interpolation and interpolation deals with non-existant "information". The quality is not up to my standard and the one of my clients. Period."

PS

it's nonsense to make such blanket statements. Aside from the fact that interpolation deals with quite-real information. No quotation-marks necessary.
You're simply arbitrarily saying that it isn't good enough for either you or your clients. But you haven't specified what standards you use to make this decision, either for you *or* your clients.

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 8:29 pm

last but not least...

"3) You´re (again) talking offensively about things you don´t understand at all. "

Your response is in and of itself "offensive", so clearly this is not truly a concern for you.
Aside from the ignorance in making it.

"I´m not tyoing around as an amateur - i have to deliver first-class quality and get first-class paid for it."

Ok sure you get paid for what you do with APP...but how do you justify the expense of your work?

"4) no question: professionals recognize upsampling of more than 25%"

No one anywhere would recognize an upsample of a mere 25% especially in a pano. If I posted two of your *own* images and one was 700MP and the other 710MP you wouldn't even notice the difference.


"And i would commit a kind of professional suicide if the clients wants 700mpx and i´d deliver it by upsampling a 300mpx file . . no serious professional is crazy - and criminal - enough to act this way and charge the fee for 700GPx."

...that would depend on why you are charging them for the product that you deliver to them. If they specify it as 700MP true that's one thing. If they just want a high-quality 700MP pano, that's quite another. You can't ignore the fact that you aren't actually taking a 700MP image with your camera, and that smartblend is *creating* a 700MP pano for you from much-lower resolution sources, are you telling them this?

Hm, I guess that this is where the issue lies. You've already got enough on your plate with creating the "shot" with APP :) you don't want to create any *additional* questions about the quality ;) I still say in that case why not give them more than they ask for, and just render the pano to 1GP or higher. Wouldn't that be an even-better justification for your "1st-class" fee?

User avatar
Paul
Member
 
Posts: 778
Likes: 0 post
Liked in: 0 post
Joined: Sat Aug 30, 2008 4:46 pm
Location: Bonn, Germany
Info

by Paul » Tue Feb 24, 2009 8:38 pm

The Results
Of course, upsampling is never as good as the original image in the correct resolution because upsampling involves creating those extra pixels out of nothing. Blow Up uses a sort of "facet" approach to creating the missing pixels. You can see the difference this makes in patterned areas.
Paul

close, but no cigar ... ... ...

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 9:18 pm

Ok now in the interest of fairness & full disclosure let's take this quite thoroughly if not quite seriously

>I'm replying to let you know publicly your two posts in this topic will be deleted tomorrow, because they show much ignorance and provide misleading information.

Ok having said that I'm sure that you've already *decided* that they show much ignorance and provide misleading information. So this is no longer under debate with you.

So what happens when you're proven wrong?

You will resign your position as forum-moderator?

"I'm straining in my attempt to understand your motives and explain myself and this will be my last attempt, as I'm sure you won't really comprehend (or at least) my point of view."

You could *ask*, and stop *assuming, much less assuming bad things...

"Consider that a fair warning - I will delete future posts that I do not see fit the tone or topic of discussion. Have in mind I've been asked by four respected forum members to ban you and received numerous reports. Please know I don't do because I enjoy it or because I'm evil, but I have to oversee the forums and keep things moderate(d). And also I have common sense."

With regard to abstract concerns with "tone" I won't reply to that. We all have our preferences. I'm merely here to learn some things and share some information about APP that I've learned in the process of using it, which would help others to use it and which would help to make a better product (you see the self-interest in this last part).

"---
That's my reply to your posts. I hope you read it before tomorrow. I'm locking the thread until tomorrow, as I have little doubt if I leave it open I'll find it with 6 or 7 of your offensive posts one after another..."

Well, "offensive" is just one adjective ;)
But you're right about the rest of that, sorry

"The thread will be opened again tomorrow, after I clean it up.
---"

Hm...

"You cannot render 100MB file and upscale it 5 times without loosing crucial detail and image information. I've seen this argument in previous posts but I've refrained from intervening, as those we situated in your thread. Your talk of DPI shows complete lack of knowledge. And all this talk of not seeing the difference... The whole purpose of panoramas is getting more "image" into the same "file" and you're destroying that with those arguments."

You don't lose ANY image detail or information through upsampling *>if done well<*. As I said, you can take a look at the output of two very good and well-regarded upsampling plugins for PS: BlowUP! and Qimage. They both will produce the highest possible quality interpolation results.
If you start with a 100MP image and downsample to 20MP you won't regain the lost data through upsampling.
My point is that quite often you can upsample from 20MP to 100MP and see negligible difference at full-image, if you do it well.
You've just cut the rendering time by 4/5 and now you can interpolate externally in a fraction of that time.

If you do not have objective criteria to evaluate this than you cannot objectively decide which to do.

Whether you find their output to be of sufficient quality when used at 400% or higher is a matter of personal opinion. I never said that they will give you great results, that's a personal decision. I just said that they can give good results up to 1600% upsampling.

"And you keep posting as if everyone uses APP the way you do, but the fact is - they don't."

I don't know where this is coming from, not only do I not expect that but clearly I'm not doing it professionally on a fast multicore workstation with an advanced graphics-card and Raid0 drives and with 8-64GB of ram in a 64-bit OS. How did you ever get to such a sweeping conclusion from what I've said?

" I doubt anyone else reading here will upscale images in TIMES. I doubt anyone is NOT using the panorama editor - probably the most useful part of APP."

LOL the editor is a nonissue if the pano isn't rendered correctly. By far the most useful part of APP is the batch-renderer. Second the automatic detection and stitching routines. The editor is a side-issue. Even if that's just my opinion, I for one would say that the editor is useless if you don't have a pano to work on and if you can't get a pano out of it.

" There's no way in hell it would render even a 100MP pano using smartdrive in 2.5 hours.

Not sure what you mean by smartdrive, I assume it's smartblend. There's way, believe me. People've done it. I've done it."

Again I was referring to rendering panos on my laptop, based on my experience with APP, not on someone elses' machine which I've never even seen.

"First you say you won't render big panos, when you have upscaling. That's OK, it's your choice. But why you insist everyone else is doing it wrong? Let all of us be wrong and do it the way you want."

Where did I ever say that everyone else is doing it wrong? Where are you coming up with this?

"Then you complain about APP not handling 10GB of images "

I never said that it can't handle 10GB of images!!!! How the hell am I supposed to know how much it can handle?

"- why would you feed 10GB of images to the software and then render 10MP pano?"

I don't know, hypothetically you could do that for any number of reasons, for one that you only need a 10MP pano. Or as I said before, you want to try to evaluate system performance with a 10MP pano as a start.

" If those are thousands of small panos - your problem is with the file structure and you can solve it by feeding the images to APP in predefined sets. Yes, the software cannot handle each and every case automatically. We all know that and nobody expects the opposite."

Yes, I'm aware that this can be done, but no I do not agree that it is wrong to "expect" it to do this without presorting the images.
I think that it is wrong to expect this to happen with the current implementation of APP.
I think that it is wrong to expect that no one should ever expect this out of the software.
I think that it is nonsense to expect someone with a lot of images already presorted to re-sort those images just so that APP can try to find panos in them.
I also think that it is nonsense to expect someone to presort the source-images for all the panos that they want to make with APP.

I think that making panos from hundreds of source-images proves my point very well. It's supposed to work for 200 sources, but what about 400? 1600? Clearly there's an upper limit that it can handle even if the images *are* presorted.

If that was not the case then why would it have a feature to merge panos? Simply in case someone wanted to merge panos?

"All your talk on ramdrive, raids, ram size, etc - that's not relevant to your problem or ANYBODY'S problem."

That's directly related to the issue under discussion, which is the time that it takes to render a pano. That's nonsense. You're not even making half-sense here.
Especially after you just spent 10 posts talking about these same issues, with the exception of a ramdrive.

"You won't solve the "APP cannot process my 10GB of family photos" issue by hardware means. I honestly believe that."

Fine. Maybe we have something in common on this topic.

" So why do you engage in a discussion, when you cannot solve your problem by talking about it - 16 gigs of ram won't help you, raids won't help you, talk won't help you, whining about APP problems to the developers won't help you and with that attitude of yours - nobody on this board will."

You're mixing metaphors here.
The issue under discussion is the rendering of a single pano with APP in the shortest time possible, not searching through a bunch of pics to try to generate panos from them.

You need to back off of this, get some sleep, have a good breakfast, go for a walk in the park, maybe take another day off after that and then reread the thread.
Last edited by touristguy87 on Tue Feb 24, 2009 9:49 pm, edited 1 time in total.

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 9:39 pm

Having said all that I realized that I was off by a factor fo 10 in my memory-requirements

It will take a 256MB ramdrive to render a 3MP pano using smartblend [established by personal experience]. It's more like 100:1, not 20:1.

So if there is *one* thing that I was seriously wrong about, that is it. It will still be much faster than using RAID0. And it's much easier to calculate that way anyway :)

So conceivably using a 16GB 64-bit system you can use maybe 14GB of that for a ramdrive and that would let you render a pano that's 140MP.
If you want to do a 700MP all in ramdrive you could do it easily on this mystery 96GB PC that I have heard about here, but can't find any detail of.
If you have a more-common 64GB system you could probably get 600MP out of it using a ramdrive.

That's a difference of a factor of say $30/GB for buffered ram vs $0.1/GB for a 7200 disk doubling that for RAID0.
Of course you can use that ram for a disk cache too, as well as memory for applications. In other words that RAID0 array may end up being much more valuable as a striped-set not as a RAID0 array (and certainly disk space will get cheaper) but you will probably not grow tired of using that ram. Plus you can write it off as a business expense.

So...what do you say is your practical upper-limit, 16GB, 32, 64, 96, subtract a couple of GB of ram for the OS and sw and divide the remainder by 100 and that would be your practical upper limit. And from there you can fiddle with the DPI.

I'm sorry if I'm misusing DPI maybe someone can explain where I am wrong there. My opinion is that 12MP will give you 300dpi at 4000x3000 pixels on a 13x10" print.

Is that wrong?
Last edited by touristguy87 on Tue Feb 24, 2009 9:45 pm, edited 1 time in total.

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 9:51 pm

Paul wrote:The Results
Of course, upsampling is never as good as the original image in the correct resolution because upsampling involves creating those extra pixels out of nothing. Blow Up uses a sort of "facet" approach to creating the missing pixels. You can see the difference this makes in patterned areas.

yes...it uses a vector transformation.

I never said that it will give you the same IQ. Of course you can see the difference.
The question is what does it take to see the difference and to what degree is there a difference.

And it doesn't "create extra pixels out of nothing". An interpolation procedure uses a mathematical transformation on the existing pixel data.

A good choice of the transformation & its application and adequate source data will result in a quality result. It will not match the quality of the image SHOT at the rendered resolution.

But APP is not actually shooting the image at the rendered resolution *either*.

APP is in and of itself an upsampling procedure. It just uses a different algorithm.

The question is whether the time spent rendering the image to NMP in APP using source images worth the IQ benefit over rendering it to say N/4 and then upsampling with a good interpolator. Because rendering to a lower resolution and upsampling will save you a *heck* of a lot of time. If it takes you 2 hours to render to 1GP, and it's linear, then it will take you 30 minutes to render to 250MP, and it will be trivial to upsample the result 200% to get back to 1GP.
Last edited by touristguy87 on Tue Feb 24, 2009 9:57 pm, edited 1 time in total.

no avatar
Gordon
Member
 
Posts: 357
Likes: 0 post
Liked in: 0 post
Joined: Wed Oct 08, 2008 12:18 pm
Location: Deep in the woods, UK
Info

by Gordon » Tue Feb 24, 2009 9:53 pm

Paul wrote:The Results
Of course, upsampling is never as good as the original image in the correct resolution because upsampling involves creating those extra pixels out of nothing. Blow Up uses a sort of "facet" approach to creating the missing pixels. You can see the difference this makes in patterned areas.

Paul and klausesserare are absolutely correct in stating that upsampling an image will deteriorate the quality of an image, as the interpolation of pixels is at most clever, but is definitely non existent and can be seen, "once spotted never forgotten".

I myself after experimenting now prefer to downsample original images by 25% if possible as this perceptually increases sharpness and resolution, but of course is not suitable for every situation. I have used several of the upsampling softwares around and they do work to a certain extent, I would say that they are more for artistic use whether professional or amateur.

Gordon
2000th Member :D

GigaPixel Experimenter
Gigapan Beta Unit, Canon Powershot S5IS, Canon 350D, Nikon D40, Manfrotto Tripod, BT-Serial + Papywizard on Nokia 770, Fully-Operational Merlin the Wizard Unit!!!

no avatar
touristguy87
Member
 
Posts: 234
Likes: 0 post
Liked in: 0 post
Joined: Mon Feb 09, 2009 9:45 pm
Info

by touristguy87 » Tue Feb 24, 2009 9:59 pm

"Paul and klausesserare are absolutely correct in stating that upsampling an image will deteriorate the quality of an image, as the interpolation of pixels is at most clever, but is definitely non existent and can be seen, "once spotted never forgotten"."

That's one half of the point that I'm making, ignoring the last part which is all mental...

"I myself after experimenting now prefer to downsample original images by 25% if possible as this perceptually increases sharpness and resolution, but of course is not suitable for every situation. I have used several of the upsampling softwares around and they do work to a certain extent, I would say that they are more for artistic use whether professional or amateur."

And that's the other half. If 55DPI is enough for you, why not 90 or 150DPI? Doubling the DPI will take 4x the amount of time to render so why not put in the extra 300% of time if resolution = income? Why not render it to 300DPI and charge the client 12x as much?

Because you can't make a rational argument that you are getting paid according to the *resolution* of your work!

You're making an abstract claim that you are justifying your rate based on "quality" that you can't quantify or even rationalize.

Ultimately your client is free to demand better and better quality at lower and lower rates delivered at lower and lower lead-times. His only concern is that it is "good enough" and he'll stick with you because you're "reliable" and produce "good-quality work". Someone else comes along and produces similar quality of work with similar reliability but faster and cheaper and you're screwed because you can't justify the rate that you were charging and now the core component of trust is out the window.

Or even say that the other guys' work is just as good and he charges the same rate for the product. Now you've got competition. Having two sources at hand, why shouldn't the client play one off against the other? What if he asks you, "why do you charge $6k for this work?" What's your answer then? Remember he's going to ask the same question of the other guy. Then one day he's going to be walking by the camera section in his local department store and realize that he could probably shoot the things himself, or at least get his kid to do it. And for what you're charging him to do one pano his kid is doing for free by the end of the summer and coming out of high-school he's got a nice little job in the company and you just lost your client.

If any idiot can go out and buy some gear and with practice do the same thing that you are doing, how are you ever going to justify charging $10k per job for it?
Does it *matter* how high the resolution is of your product, or how good your lenses were? No, they just need to be "good enough". What matters is how good the *shot* is, which depends mostly on your artistic eye, and the same for the editing work. Whether the end-result is 25dpi upsampled, 50dpi or 100dpi is a technical issue. But you're not getting paid for the resolution of your panos. You're getting paid for the artistic quality of the end-result of your efforts.
Last edited by touristguy87 on Tue Feb 24, 2009 10:25 pm, edited 1 time in total.

PreviousNext

Who is online

Users browsing this forum: No registered users and 3 guests

cron