 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | You are not logged in.
It would be nice to be able to hint SmartBlend or MultiBlend with some Bezier curve shapes. You could use them to cut stuff off an image you absolutely didn't want to blend into the final pano. Actually, the curves don't even need to be as fancy as a Bezier curve. Simple natural curves or even linear shapes would probably do the trick. (I actually prefer natural curves as they are less work to edit) Perhaps the shapes could have a "blur" or soft edge option, to help control blending. They only have to be good enough to hint the blending engine.
A proxy mode to help speed up the interactivity of this interactive work of masking stuff would be nice.
Offline
lordtangent wrote:
It would be nice to be able to hint SmartBlend or MultiBlend with some Bezier curve shapes. You could use them to cut stuff off an image you absolutely didn't want to blend into the final pano. Actually, the curves don't even need to be as fancy as a Bezier curve. Simple natural curves or even linear shapes would probably do the trick. (I actually prefer natural curves as they are less work to edit) Perhaps the shapes could have a "blur" or soft edge option, to help control blending. They only have to be good enough to hint the blending engine.
A proxy mode to help speed up the interactivity of this interactive work of masking stuff would be nice.
Hey lord!
Maybe you misunderstand the purpose of a stitcher? 
You already have this opportunity in rendering your pano as Photoshop-layers and work it over there. How should a blender use curves?
best, Klaus
Offline
There are many reasons to have such a feature:
- Photoshop is somewhat expensive and my particular substitute (PSPro) doesn't support really large psb that a created with Autopano
- Autopano has to blend the images anyway (yes, thats the purpose of a stitcher, too), so why not take hints from the user what parts of the image should be preferred when doing its job?
- Postprocessing the images to explude objects costs time, so why do a job manually that Autopano could do (semi-)automatically?
Christian
Offline
Tipjip wrote:
There are many reasons to have such a feature:
- Photoshop is somewhat expensive and my particular substitute (PSPro) doesn't support really large psb that a created with Autopano
- Autopano has to blend the images anyway (yes, thats the purpose of a stitcher, too), so why not take hints from the user what parts of the image should be preferred when doing its job?
- Postprocessing the images to explude objects costs time, so why do a job manually that Autopano could do (semi-)automatically?
Christian
Here, here, I agree with all these points, it would a leap forward in functionality and speed if such a feature could be implemented that would surpass all the competition!
Offline
BrianLR wrote:
Tipjip wrote:
There are many reasons to have such a feature:
- Photoshop is somewhat expensive and my particular substitute (PSPro) doesn't support really large psb that a created with Autopano
- Autopano has to blend the images anyway (yes, thats the purpose of a stitcher, too), so why not take hints from the user what parts of the image should be preferred when doing its job?
- Postprocessing the images to explude objects costs time, so why do a job manually that Autopano could do (semi-)automatically?
ChristianHere, here, I agree with all these points, it would a leap forward in functionality and speed if such a feature could be implemented that would surpass all the competition!
Christian, Brian: a stitcher is a stitcher. It´s goal is to stitch and render the stitch as perfect as it´s actually possible. APP/APG is a very good stitcher, extended to APT/KRPano tools you get an excellent bundle of high productive apps. In my eyes the best of it´s kind.
A stitcher is not a dedicated RAW-converter, no dedicated HDR-application, no substitute for photoshop, no animation-postproducer, no 3D constructor/renderer and so on.
APP/APG/APT are excellent apps with some demands on the skills of the users anyway. Could you imagine the exploding complexity and can you also imagine the money such an application of your demands would have to cost? I guess they might be demanding too much skills sometimes somehow anyway . . . .
Would YOU like to pay some grands for a product which fits the needs of maybe 10% of it´s users?
I wouldn´t like that - and i wouldn´t like to bother with features which other specialized apps have already elaborated. As a professional i know that professional applications are 1) always specialized and 2) always expensive . . sometimes very expensive. And for good reasons.
You wouldn´t really expect Maya, C4D to be a professional audio-editing suite too - instead you buy a professional audio-suite like ProToolsHD additionally when you´re a pro. Or you out-source your audio to an external audio pro.
So: IF you really need the features you describe for doing professional work with - buy the professional apps you need to do it and combine their features.
Don´t expect a "one-does-it-all" magic lamp you can rubble on and which does everything you want . . . for a price of a dinner for two and some bottles of wine in a middle-class italian restaurant.
That´s just my opinion - no offense.
best, Klaus
Offline
Klaus,
Watch what you say about Italian restaurants - you might get a visit from my cousin Luigi! ;^)
Ricardo
Offline
Apapane wrote:
Klaus,
Watch what you say about Italian restaurants - you might get a visit from my cousin Luigi! ;^)
Ricardo
I love italian restaurants! 
Was lunching at Luigi´s yesterday - really!
best, Klaus
Offline
klausesser wrote:
Christian, Brian: a stitcher is a stitcher. It´s goal is to stitch and render the stitch as perfect as it´s actually possible. APP/APG is a very good stitcher, extended to APT/KRPano tools you get an excellent bundle of high productive apps. In my eyes the best of it´s kind.
A stitcher is not a dedicated RAW-converter, no dedicated HDR-application, no substitute for photoshop, no animation-postproducer, no 3D constructor/renderer and so on.
That´s just my opinion
best, Klaus
Klaus I agree with much of what you say, but when you say "a stitcher is a stitcher. It´s goal is to stitch and render the stitch " that is the point, we are talking about a tool that would allow one to choose which parts of the images to include in the rendering process. Rather like choosing which ingredients to include on your Pizza!
Brian
Last edited by BrianLR (2010-02-03 02:52:50)
Offline
BrianLR wrote:
we are talking about a tool that would allow one to choose which parts of the images to include in the rendering process.
You can choose the part you want to render by cropping the pano in the editor and render just what you want to render the way you want to render it . . . .
I don´t know whether it´s possible to select an aerea in the editor/rendering dialogue to be rendered smartblend and another area to render multiband or something . . . i´m just a photographer and ex-cameraman and not a software pro.
But i know from apps like - as i told - Maya, Nuke, Renderman and so on how complex these things are - and how expensive the could come.
In the end: who really NEEDS it combined in one? The ways to do what you want exist already. Correct me if i´m wrong!
best, Klaus
Offline
klausesser wrote:
In the end: who really NEEDS it combined in one?
This is the point where we differ: I don't see that as a combination of different tools but as the tweaking of one tool. I want to tell the renderer what it should render and what not, much like cropping the panorama. Following your line of thought I could argue that cropping the pano really shouldn't be in APP because cropping is image editing and has nothing to do with stitching the panorama. So you should use PS for the job. Of course that works, but adding cropping to APP makes it more convenient to use and faster. The same applies to the requested feature.
My point in case of adding the feature to APP is that as the stitcher has to decide what to render and what not anyway (to remove ghosts i.e.), why not take a hint from the user?
In the end wether the requested feature is NEEDED or not depends on the workflow you follow. Yours obviously involves PS anyway, so you have no need. Lordtangents and mine doesn't, so we think it would be useful.
That other ways to do the task exist is true. But the better is always the enemy of the good. And you COULD use PS to stitch you panorama manually. It just takes a little longer....
Christian
P.S.: I remember that Realviz Stitcher had such a feature back in 2003. Considering how extremely advanced APP ist compared to that piece of software I can't imagine adding the feature would be all that hard. By the way, can't you already crop out the black ring from fisheye lenses before rendering? Thats nearly the same.
Last edited by Tipjip (2010-02-03 15:59:54)
Offline
Really, all we need is an "eraser" tool and a "highlight" tool to edit the source files in APP. No need for bezier curves or the like. Just erase what you don't want, highlight what you do want, and let the blenders work.
APP uses the alpha channel to determine what not to put into a pano. So you can already do the "erase" part in PS, but its awkward, you have to find each source image that contains what has to be erased, and then erase it, and save it to a new file.
Offline
hankkarl wrote:
Really, all we need is an "eraser" tool and a "highlight" tool to edit the source files in APP. No need for bezier curves or the like. Just erase what you don't want, highlight what you do want, and let the blenders work.
APP uses the alpha channel to determine what not to put into a pano. So you can already do the "erase" part in PS, but its awkward, you have to find each source image that contains what has to be erased, and then erase it, and save it to a new file.
I'm glad to see my request has stimulated so much conversation.
hankkarl has a good point about extending tools that already exist. It doesn't HAVE to be bezier curves. In fact an "eraser" and "highlight" might even be a better interface if it's clear enough what it's doing and fast enough in APP.
The only reason I suggested curves is it seems Autopano is somewhat resolution-independent. By that I mean, it seems to not make any pixels until they are requested at a given output resolution. Bezier or natural curves just seemed to make more sense to me as they also would not need to be rasterized until rendertime.
Anyway, I don't care about the implementation as much as the results. I want a way to hint the blender for fixing ghosts and making transitions where I think they should be when the stitch isn't perfect and you want to blend in a more intelligent way to work around it.
Sure, Photoshop can do the pixel editing part. But why should I have to use it for something that is honestly so simple? As Tipjip observed, the stitcher/blender is doing all that work ANYWAY. Why not just have it do it right the first time? Plus, what about Gigapixel images? Sure, you could edit each problem tile manually in PS, but who has the time for that? Wouldn't it be better to be able to go in and just setup a quick mask shape to fix the few problem areas right in the stitching software?
Offline
lordtangent wrote:
The only reason I suggested curves is it seems Autopano is somewhat resolution-independent.
Because any digital photography is based on pixels - and any analogue photography is based on film-grain - there is no resolution-independence at all working with photographed images!
best, Klaus
Last edited by klausesser (2010-02-23 12:32:08)
Offline
lordtangent wrote:
The only reason I suggested curves is it seems Autopano is somewhat resolution-independent. By that I mean, it seems to not make any pixels until they are requested at a given output resolution. Bezier or natural curves just seemed to make more sense to me as they also would not need to be rasterized until rendertime.
Ummm.....APP runs on a digital computer. Each input image is composed of pixels (even if it was scanned from film). The input images control the maximum resolution--you can't go bigger than 100% in APP. You can downsize when rendering. Previews can be expanded to more than 100%, but that's just a scaling on the monitor, not an increase in the panorama's resolution.
Last edited by hankkarl (2010-02-23 18:25:48)
Offline
hankkarl wrote:
The input images control the maximum resolution--you can't go bigger than 100% in APP.
I totally agree that the resulting panorama can't go beyond input image quality, but about the 100% I would be happy to know more...
Though things are quite simple when a long lens is used, it's much more difficult to understand how Autopano decides of the width and height in the resulting pano which will correspond to 100% when an ultra-wide-angle lens or a fisheye is used.
For these lenses the amount of pixels varies widely between the center of the source images and the corners (pixels per solid angle units.) For rectilinear lenses I would tend to use image center as the reference because this is where the number of pixels per angular unit is the lowest (that the corners are stretched results from "too many pixels" being used in said corners!) For fisheyes it looks even more intricate: the variation of pixels per solid angle units is quite low but not homogeneous between the direction toward the center an the direction perpendicular to it: this certainly don't improve image quality and using the image center as a reference is questionable.
When using a motorized panohead, spherical panos can be shot using any kind of lens and very large images can be stitched: selecting the right percentage for rendering can save a lot of time (post-processing included), that 100% is the best option is not obvious...
Full frame sensor size image, rectilinear lenses:
Focal Diagonal Corners corners versus center
Length FOV stretching ratio of pixels per
sensor area unit (1)
500 mm 4 deg + 0 % 1.0
300 mm 8 deg + 0 % 1.0
200 mm 12 deg + 1 % 1.0
135 mm 18 deg + 2 % 1.0
100 mm 24 deg + 4 % 1.0
85 mm 28 deg + 6 % 1.1
50 mm 46 deg + 18 % 1.3
35 mm 63 deg + 38 % 1.6
28 mm 75 deg + 59 % 2.0
24 mm 84 deg + 81 % 2.4
21 mm 91 deg + 106 % 4.2
20 mm 94 deg + 117 % 4.7
16 mm 107 deg + 182 % 4.8
14 mm 114 deg + 238 % 6.2
12 mm 121 deg + 325 % 8.8
(1): for example the 3.3 ratio value for 24 mm lens means that
if the image of an object corresponds to a single pixel
when at the image center, the image of this object will
correspond to 3.3 x 3.3 = 10 pixels when same object
is located in an image corner.Last edited by GURL (2010-02-24 20:21:56)
Offline
klausesser, hankkarl, you are missing my point and dwelling on semantics. Notice I used the word "somewhat" and that is regarding how APP seems to function internally. (It doesn't care what the input res or output res is. It generates the OUTPUT pixels at render time.) GURL seems to "get" my thinking. With so much interpolation and filtering happening in the stitching process, it's naive to say "input pixels equal output pixels".
I don't believe APP magically makes resolution. Of course input images drive the maximum output resolution possible. And of course we never make output larger than the input because that would be stupid.
OK... back to my original point... curve based masks would have no pixels at all until render time, which would make them much faster to work with in the interface regardless of the input resolution. They can work right on top of the OpenGL preview and could be dynamically rasterized for the previews and rendered only at the full output res later for the final render.
Do you REALLY want to be painting masks on tens or potentially hundreds of 18+ megapixel input images? Remember, the original request was for a way to hint the stitcher/blender in situations that confuse it. The simpler and faster the interface to it, the better... as long as it gets job done.
Last edited by lordtangent (2010-02-24 23:01:35)
Offline
lordtangent wrote:
With so much interpolation and filtering happening in the stitching process, it's naive to say "input pixels equal output pixels".
Nobody said that.
lordtangent wrote:
Do you REALLY want to be painting masks on tens or potentially hundreds of 18+ megapixel input images?
How would i need to?
best, Klaus
Offline
Surely you've gotten "ghosts" on some projects, even with Smart Blend.
Offline
lordtangent wrote:
Surely you've gotten "ghosts" on some projects, even with Smart Blend.
Rarely enough - in this case i use rendering layers and Photoshop to edit the layers.
Or i erase moving objects in PS before stitching. Usually it´s only one or two images to edit.
best, Klaus
Offline
GURL wrote:
hankkarl wrote:
The input images control the maximum resolution--you can't go bigger than 100% in APP.
I totally agree that the resulting panorama can't go beyond input image quality, but about the 100% I would be happy to know more...
Though things are quite simple when a long lens is used, it's much more difficult to understand how Autopano decides of the width and height in the resulting pano which will correspond to 100% when an ultra-wide-angle lens or a fisheye is used.
For these lenses the amount of pixels varies widely between the center of the source images and the corners (pixels per solid angle units.) For rectilinear lenses I would tend to use image center as the reference because this is where the number of pixels per angular unit is the lowest (that the corners are stretched results from "too many pixels" being used in said corners!) For fisheyes it looks even more intricate: the variation of pixels per solid angle units is quite low but not homogeneous between the direction toward the center an the direction perpendicular to it: this certainly don't improve image quality and using the image center as a reference is questionable.
When using a motorized panohead, spherical panos can be shot using any kind of lens and very large images can be stitched: selecting the right percentage for rendering can save a lot of time (post-processing included), that 100% is the best option is not obvious...
I oversimplified. I was referring to the render output of 100%--that is, APP doesn't use fractals to enlarge an image, and doesn't even give you an option to enlarge.
And there is the case when you use a long lens and a short lens--AFIK, APP interpolates the images from the short lens so you can have the greatest resolution.
But I think that if you take the number of pixels around the equator--that is, the centerline of the pano, that number is controlled by the input images. It may be sort of like "take the number of pixels in 1 degree at the center of the image and multiply by 360" that should give you a maximum for the size of the pano. APP may give a slightly different number because of errors (roundoff or stitching errors) but it should be close. You can't get APP to render bigger than this.
But most importantly, I was addressing the issue that APP scales like vector graphics--it doesn't. You can shrink the image, but APP won't allow you to render larger than what it thinks is 100%. The bezier curve is not needed, and a crisp edge may not be wanted in an erase/highlight tool--you may want a feathered region to allow a better blend.
Offline
lordtangent wrote:
klausesser, hankkarl, you are missing my point and dwelling on semantics. Notice I used the work "somewhat" and that is regarding how APP seems to function internally. (It doesn't care what the input res or output res is. It generates the OUTPUT pixels at render time.) GURL seems to "get" my thinking. With so much interpolation and filtering happening in the stitching process, it's naive to say "input pixels equal output pixels".
I don't believe APP magically makes resolution. Of course input images drive the maximum output resolution possible. And of course we never make output larger than the input because that would be stupid.
OK... back to my original point... curve based masks would have no pixels at all until render time, which would make them much faster to work with in the interface regardless of the input resolution. They can work right on top of the OpenGL preview and could be dynamically rasterized for the previews and rendered only at the full output res later for the final render.
Do you REALLY want to be painting masks on tens or potentially hundreds of 18+ megapixel input images? Remember, the original request was for a way to hint the stitcher/blender in situations that confuse it. The simpler and faster the interface to it, the better... as long as it gets job done.
You have to mask somehow. using bezier curves or a erase/highlight (like painting a mask) tool is work either way. And it doesn't have to be done to each picture, only to the ones of interest.
Say you have a person walking across a field and you want to show him several times. You Highlight that person in each of several images when he is where you want him to be. At some point, he may be halfway in the frame, so you erase him only on that frame. If you use bezier curves, you have to do the same thing.
Speed is not really an issue, images already use an alpha channel. There's so much else going on, I don't see this as being a big processor cycle hog. Besides, you have to calculate bezier curves, which may take more processor time. (you do want the preview to show what's masked out and in, right?)
There is a way to erase/highlight on the main editing window if some proportional blending is used. If you highlight over a ghost, APP could pick the pixels that are only on one image (erase would ignore the pixels only on one image). But this breaks down when you have multiple exposures in one area (like the corner where four images overlap)--APP would have to pick the best pixels from an image where the highlight region stays entirely on one image, you don't want the guy who's halfway in the frame. So this would be a major effort to plan, let alone develop. One way this could work is that you select a region (by curves, brush, lasso, or whatever so long as its more complicated than a simple rectangle), then APP displays all the underlying images and gives you a "erase" "highlight" "normal" choice for each.
Offline
klausesser wrote:
lordtangent wrote:
Surely you've gotten "ghosts" on some projects, even with Smart Blend.
Rarely enough - in this case i use rendering layers and Photoshop to edit the layers.
Or i erase moving objects in PS before stitching. Usually it´s only one or two images to edit.
best, Klaus
Just pointing out that the two methods Klaus uses have different effects. If you erase moving objects in PS before stitching, there are no control points put on them.
Offline
hankkarl wrote:
If you erase moving objects in PS before stitching, there are no control points put on them.
Right - when you leave the rest of the image untouched and save transparency it works fine.
Somewhere here in the Wiki is how it works . . . here:
http://www.autopano.net/wiki-en/action/ … ng_objects
best, Klaus
Offline
hankkarl wrote:
if you take the number of pixels around the equator--that is, the centerline of the pano, that number is controlled by the input images. It may be sort of like "take the number of pixels in 1 degree at the center of the image and multiply by 360" that should give you a maximum for the size of the pano.
I will try that.
After some tests I found my fisheye being equisolid (or nearly) and this should work with long lenses too. For ultra-wide-angle lenses, on the contrary 
? - Some tests are shown there (with French comments): http://www.autopano.net/forum/t8381-tok … 6-mm-aps-c
Offline