Another Miner bee

[DrLazer]

Had a little problem with the "beard" moving during the stack, must remember to not breathe at any point when I do the next one :p



Full size version

Hope you like it. I'm not exactly chuffed, but then I never am.

[rjlittlefield]

Nice!

The beard looks like maybe just one frame went astray.

In Zerene, you can quickly explore that by playing through the source images as if they were a filmstrip.

To do that, proceed as follows...

1. Do a Stack > Align & Stack All (PMax), or at least a Stack > Align All Frames.
2. In the Input Files window, put a checkmark on "Show as adjusted".
3. Press-and-drag within the list of Input Files. The file selection and image showing in the source window will keep updating to match the cursor position. This lets you quickly home in on the troublesome part of the stack and then joggle the selection back and forth to identify which frames are not like the others.

Once you have the troublesome frames identified, you can either remove them from the stack by highlighting them and File > Remove from list... > Input File(s), or you can use the Stack Selected trick to just exclude those from another run of the stack. To simplify using Stack Selected, remember that control-click will de-select an individual file. So, you can for example control-A to select them all, then control-click on the one or two that are causing trouble. I would probably use "Remove from list..." and save the project so I could come back to it later if I wanted to, but either method works fine.

--Rik

[DrLazer]

Thanks Rik! I wish I knew about that before I started. I spent so long retouching this bee that I couldn't possibly bare to spend any more time on it right now. I'm sure you are familiar with that feeling right?

I'll move onto to something else and keep the new techniques in mind. One day I will go back and reproceess this bee stack. I have all the source frames saved to disc.

Wow the Flickr magic donkey decided it liked me on the day I posted that bee. Wish I understood how that crazy donkey works.

[rjlittlefield]

I spent so long retouching this bee that I couldn't possibly bare to spend any more time on it right now. I'm sure you are familiar with that feeling right?

Oh yes, very familiar. In fact the whole reason Zerene Stacker exists and has the features it does is because I got so tired of retouching using other packages. I still get tired of it in ZS too, but that's because I'm pickier now. More improvements needed...

--Rik

[DrLazer]

I noticed a couple of things about Zerene that I thought were a bit odd. Firstly is the java. Did you choose Java to make it platform independent? Have you ever thought about porting it to C++ to speed it up? Not that the speed bothers me in any way but everyone likes stuff faster, it also seems to be the one thing that Helicon has over ZS.

Errrr also - I'm sure you know about this already but if you mess with the source files and try and run a restack it crashes. I'm being assumptive here but it looks like when it runs a stack it makes new realigned images and puts then in a new directory. Thats what confused me, I thought after that point it wouldnt matter about where the source images are. On the same note, why does it need to copy all the images - is there some reason that prevents it from being a possibility to just store realignment co-ordinates?

[rjlittlefield]

I noticed a couple of things about Zerene that I thought were a bit odd. Firstly is the java. Did you choose Java to make it platform independent? Have you ever thought about porting it to C++ to speed it up? Not that the speed bothers me in any way but everyone likes stuff faster, it also seems to be the one thing that Helicon has over ZS.

Lots of factors. Platform independence is the biggest one. The speed advantages of C++ over Java are largely a myth, partly left over from the very early days when Java was interpreted instead of just-in-time compiled, and partly maintained by people writing sloppy Java that runs inefficiently because it beats on the memory manager and makes a lot of unnecessary function calls. For well written computational work, Java and C++ are within a few percent of each other. It's true that Helicon runs faster than ZS does, but that's because it does different computations.

Errrr also - I'm sure you know about this already but if you mess with the source files and try and run a restack it crashes.

Yes, that's an annoying oversight in the coding. It really ought to handle that situation gracefully and just ask you where the images have been moved to.

I'm being assumptive here but it looks like when it runs a stack it makes new realigned images and puts then in a new directory. Thats what confused me, I thought after that point it wouldnt matter about where the source images are. On the same note, why does it need to copy all the images - is there some reason that prevents it from being a possibility to just store realignment co-ordinates?

The image files are not copied. If you look in a project file, you'll see the alignment parameters, just like you expect. Those image files you're seeing are heavily compressed "preview" images that are used to permit that trick of playing like a filmstrip and doing fast depth navigation while retouching. They're controlled by checkboxes at Options > Preferences > Image Caching. If you un-check those boxes, the cached images will not be generated. That will make stacking per se run somewhat faster, but in exchange navigation and retouching will be a lot slower.

--Rik

[DrLazer]

How interesting. Well my experience of Java is pretty minimal, I probably haven't used it since learning to write code back in the bronze age. The main reason for that is the companies I work / have worked for immediately dismiss it as an option, even if platform independence is neccessary. I think it's almost always dismissed for speed too. I had the same opinion of it but I am always open minded when discussing such things. I thought that C++ would be faster because the code will be native, whereas Java is byte code that has to be interpreted on the fly by the JVM.

The other thing that makes me think it is faster is that whenever a system requires speed .. it is almost allways written in C++. Console games, critical systems etc.

Sorry about pointing out on the forum the moving of source files problem. Are you still working on the app and if so do you have a list or order of improvements/new features?

Thanks for clarifying that the folder of additional images are just compressed previews. Silly assumptive me saw the folder and thought "oh ... i guess I can shift my source files then".

[seta666]

Beautiful bee, you kept the whites very well; the beard reminds me of a robber fly
Regards
Javier

[rjlittlefield]

I thought that C++ would be faster because the code will be native, whereas Java is byte code that has to be interpreted on the fly by the JVM.

That's a common misconception. It was emphatically true in the very early days, but for quite a few years now, the runtime technology has involved a "just-in-time compiler" that essentially treats the byte code as an intermediate form of source code and compiles that into native. The runtime compilation takes some time, but it's a tiny amount for any computational task that takes long enough to worry about.

The main reason for that is the companies I work / have worked for immediately dismiss it as an option, even if platform independence is neccessary. I think it's almost always dismissed for speed too.

Easy to believe, and not an unreasonable position. You can't write "textbook Java" and expect it to run at the speed of C++. But if you specifically code to avoid the inefficiencies, the differences are pretty small. This was an issue that we looked at quite a lot in my previous career HERE, and it was one of the things I checked out when I started prototyping ZS.

The other thing that makes me think it is faster is that whenever a system requires speed .. it is almost allways written in C++. Console games, critical systems etc.

There are other factors involved here. Good games offload a lot of work to the graphics processor, and those interfaces are much more mature in C++. For critical systems, especially anything that has a hard realtime constraint, you need to strictly limit the amount of runtime involvement. This is fairly straightforward in C++, but difficult or impossible in standard Java -- there's always a memory manager lurking in the background that can consume time unpredictably.

Sorry about pointing out on the forum the moving of source files problem. Are you still working on the app and if so do you have a list or order of improvements/new features?

No problem; yes; and yes but not published. If there's something you particularly want, contact support@zerenesystems.com and we'll talk about what might be involved.

Thanks for clarifying that the folder of additional images are just compressed previews. Silly assumptive me saw the folder and thought "oh ... i guess I can shift my source files then".

Well, in an ideal world the relationships would have been spelled out somewhere. They weren't. On the bright side, I've just recently restructured the zerenesystems website so it'll be a lot easier to add and find little snippets of information like that. Life gets better...

--Rik

[DrLazer]

How incredibly knowledgeable you are rik. Being on this forum feel a bit like going back to school ... So much to learn. Thanks for the replies / time / info. Always appreciated.

[DQE]

Rik,

Do you think there is or should be much interest on computational efficiency and throughput re Zerene stacking?

An ad-hoc thought is to solicit users' hardware configurations and run a set of standard stack(s) through Zerene on each selected user's PC, establishing a basic database of execution times, I/O times, etc, etc.

I am guessing that you've already got the basics of such a database and thus may not really need to mount such an effort, or set up a test image stack, etc. I suspect that your user community has a fairly wide range of computer equipment and operating systems, so I thought I'd raise the topic and see if it has any merit. (I just ordered a new PC and this got me to thinking along these lines.)

Just some thoughts. I hope I'm not threadjacking here.

[rjlittlefield]

Being on this forum feel a bit like going back to school ... So much to learn.

It is the same for me. I learn new stuff here every day. Regarding computational tools, that just happens to be an area where I've made my living for some 40 years. Most of that was in a research environment where standard practice was to assume that half of what we knew was wrong, and the challenge was to identify which half was wrong, make half the rest obsolete, and somehow exploit the remaining quarter that happened to be both right and relevant. There was a line item on the HR form for evaluating interviewees: "Tolerance for ambiguity". I'm convinced that the person who wrote that was a genius, although in retrospect I've joked that perhaps it should have been "Fondness for confusion."

Do you think there is or should be much interest on computational efficiency and throughput re Zerene stacking?

Beats me. Everybody has their own priorities.

For my own photography, the priority is on "better images, less work". That's less work for me as the photographer. I'm not terribly concerned how hard the machine has to work unless that time gets in my way as a user. When I figure out how to double the computation time but get a big improvement in image quality, I'll jump on that because I can go do something else while the machine crunches.

I suspect that users like eurythyrea would have similar priorities, since he spends a lot of time in post-processing (e.g. HERE).

On the other hand, there are other users who are lark happy with the results they're getting from the current methods, but they'd be happier to get those same results faster because they're running in a production environment.

Given that there are limited resources to spend on code development, I think it's pretty clear that these two groups are in conflict with each other. Time spent making the same thing run faster generally doesn't contribute much to getting a better result. So there's a tension that I resolve by listening and contemplating and eventually taking the heat for deciding which direction to pursue. I'm not sure that collecting numbers would help much with resolving that tension.

On the other hand, perhaps your concern is more prosaic: given N $$, how should those be divided between processor, disk, memory, etc., so as to get the most bang for the buck. In that case, some carefully collected numbers could be useful. However, I have to say that I'm not particularly interested in collecting them myself because time spent collecting numbers and making sense of them is time not spent making the code and documentation work better for the majority of people who just want to run ZS on whatever machine they already have.

Is this helping?

I'll let DrLazer decide if it's threadjacking or not.

--Rik

[DrLazer]

I'll let DrLazer decide if it's threadjacking or not.

Absolutely not. I love this kind of stuff.

[DQE]

Being on this forum feel a bit like going back to school ... So much to learn.

It is the same for me. I learn new stuff here every day. Regarding computational tools, that just happens to be an area where I've made my living for some 40 years. Most of that was in a research environment where standard practice was to assume that half of what we knew was wrong, and the challenge was to identify which half was wrong, make half the rest obsolete, and somehow exploit the remaining quarter that happened to be both right and relevant. There was a line item on the HR form for evaluating interviewees: "Tolerance for ambiguity". I'm convinced that the person who wrote that was a genius, although in retrospect I've joked that perhaps it should have been "Fondness for confusion."

Do you think there is or should be much interest on computational efficiency and throughput re Zerene stacking?

Beats me. Everybody has their own priorities.

For my own photography, the priority is on "better images, less work". That's less work for me as the photographer. I'm not terribly concerned how hard the machine has to work unless that time gets in my way as a user. When I figure out how to double the computation time but get a big improvement in image quality, I'll jump on that because I can go do something else while the machine crunches.

I suspect that users like eurythyrea would have similar priorities, since he spends a lot of time in post-processing (e.g. HERE).

On the other hand, there are other users who are lark happy with the results they're getting from the current methods, but they'd be happier to get those same results faster because they're running in a production environment.

Given that there are limited resources to spend on code development, I think it's pretty clear that these two groups are in conflict with each other. Time spent making the same thing run faster generally doesn't contribute much to getting a better result. So there's a tension that I resolve by listening and contemplating and eventually taking the heat for deciding which direction to pursue. I'm not sure that collecting numbers would help much with resolving that tension.

On the other hand, perhaps your concern is more prosaic: given N $$, how should those be divided between processor, disk, memory, etc., so as to get the most bang for the buck. In that case, some carefully collected numbers could be useful. However, I have to say that I'm not particularly interested in collecting them myself because time spent collecting numbers and making sense of them is time not spent making the code and documentation work better for the majority of people who just want to run ZS on whatever machine they already have.

Is this helping?

I'll let DrLazer decide if it's threadjacking or not.

--Rik

Probably I should have mentioned that my personal interest is mostly based on a long-standing personal interest in: computational efficiency, algorithms, numerical analysis, as well as making my PC faster. Obviously, most others don't share these special interests! Then I began wondering if anything of interest might turn up if we compared notes using our own PC hardware.

Adding to this mix, I just ordered a new PC from Puget Systems, and naturally this stimulated my interest in PC performance, etc. I hope at least some of the hardware options and money I threw at my PC configuration are useful! I was able to track down generic Photoshop performance sensitivity with respect to things like RAM, CPU capability, and I/O parameters. Many PC sites use a Photoshop script of some sort as one of their test suite components.

I very much agree with placing image quality above computational speed, without many qualifications!

Thanks for the clarifications - it helped me to better see things from your perspective as the developer. Since Zerene *must* if possible run on a wide range of PC hardware, it's probably not of too much interest to learn that some hot new component(s) make it run somewhat faster. Optimizing a PC for stack computations is probably most interesting to PC enthusiasts.