Preview behavior (philosophic consistency)

[ngc1535]

Just a thought on previews and their behaviors as defined by intended usage...

There exist a number of processes that spawn new views. StarMask is obviously one of them (as an example). However when applying StarMask to a Preview the newly created view (mask) breaks with the putative behavior of a preview. One might expect the new star mask to simply exist in the preview. It would only generate a new view when applied to the base data (entire image).

What I am suggesting is that the preview behavior takes precedence over the behavior of the process. If one wanted a new view using star mask of the preview- a copy of the preview would be made (dragging to desktop)  invoking a "real" view with its own base data.

Perhaps I should have started this with the question, is there a way to force a view generating process to keep it in the preview?
The way I see it is that a process' behavior is with respect to the base data. Yes, StarMask creates views- and previews can be seen as  no different than any other thing.... but in a way I think they are different- and sending the result to the preview instead of a new view could be a reasonable behavior?

-adam

[pfile]

i'm not entirely certain how this would work... previews are something of a second-class citizen; for instance you can't apply a mask to a preview. if you want to apply a mask, you can only apply it to the main view. the mask is present in the preview but only by virtue of inheriting it from the main view.

so if you use a process that generates a view from a preview, where would that view go...? meaning, what does "keep it in the preview" mean? overwrite the preview with the view created by the process? but then the preview is not a preview anymore; it does not inherit from it's parent but stands apart.

even when you apply a non-view generating process to a preview, there's no history there. if you apply a 2nd process to the preview again, it's as though the first process were never run.

rob

[ngc1535]

Hi Rob,

Interesting- this is certainly due to my misunderstanding of previews in general.

If taken literally, these things preview a process. So yes, the view generating process would write the new pixels to the preview. This would permit a user to quickly see changes in settings and (and this is what I was looking for) would allow a user to create a few previews- vary a parameter- and flip through the previews to see the results. By generating new views... this is not quite as elegant.

So now I need to square your comment "but then a preview is not a preview anyone." 
I am suggesting that preview creature would show me what I would get of that portion of the main view as generated by a process... a process which, yes, happens to create views... but why not write it to the preview? And maybe this was not clear... the resulting star mask of course is NOT being used on the preview. This is merely to preview the result of the process (not how the process is used). So if I applied StarMask again a second time... sure it overwrites the first instance. StarMask outputs pixels... it isn't the usage that is of interest- just the generated pixels.

I view previews as little windows into the possible worlds of processes. That is why I mentioned that the preview behavior as acting like this little window could take precedence over the view creation behavior of a process.

It is likely my philosophy isn't sound, and perhaps that is why I had not seen mention of this.

-adam

[pfile]

i see what you mean now. i guess you have to make an argument (which you have) that the semantics of previews are somehow different - after all, a view-generating process like starmask would never overwrite a target image, but in this case you want it to overwrite previews. in that sense it would be no different from the current behavior in that the pixels of the preview get temporarily modified.

i think this probably owes its behavior simply to the norms of computer programming.

generate a view from another view?

object = View1
newView = process(object.Xorigin,object.Yorigin,object.Xmax,object.Ymax)

generate a view from a preview? i already know how to do that!

object = PreView1
newView = process(object.Xorigin,object.Yorigin,object.Xmax,object.Ymax)

i can't read juan's mind, but i would assume that his idea of what a preview is is simply a subregion of a view, and so it behaves the way any other view would. that is what i meant by "not a preview anymore". if a preview works differently than a view under view-generating processes, then it's no longer simply a subregion.

rob

[ngc1535]

Thanks Rob. I totally understand what you are saying now. Indeed, my suggestion expands the role of a preview as something more than what would happen to the subregion in some perhaps special cases. An alternative could be as simple as an option in the view-generating tool to force it to replace pixels in the target image. The very idea of a view-generating process seems to be an implicit assumption (a conditional thing) that the result is to be used in a different way. But this seems ad hoc (though admittedly valid most of the time).  A democratic philosophy would be to say that like PixelMath- all processes come with the choice of overwrite target image or create new view. 

Anyway, I enjoyed discussing it. Thank you.
-adam