Zerene Stacker and retouch color control

A forum to ask questions, post setups, and generally discuss anything having to do with photomacrography and photomicroscopy.

Moderators: rjlittlefield, ChrisR, Chris S., Pau

Luisifer
Posts: 112
Joined: Wed Sep 05, 2018 1:40 am
Location: Czech Republic
Contact:

Post by Luisifer »

BTW. it looks like whole thing about "Retain extended dynamic range" is very problematic. Maybe it would be easier to leave that option and hold rendered values unchanged in some 32bpch kind with possibility to use it as input file too (now the input files are accepted only 16bpch (i don't count 8bpch files as apropriate source if it is not some testing)).

(hope you will not have an headache from my words) :-)

rjlittlefield
Site Admin
Posts: 23561
Joined: Tue Aug 01, 2006 8:34 am
Location: Richland, Washington State, USA
Contact:

Post by rjlittlefield »

Luisifer wrote:But.... after commiting stable retouching there is created new ZSY file and new retouching from that ZSY file in some close location which can be so close that it is necessary to overlay strokes over the previous retouching that cause new change of brightness.
It sounds like you are saying that Edit > Commit Retouching, followed by Edit > Start Retouching from the new output image, gives a different result from just continuing to retouch, without a commit and re-start.

If that is what you're saying, then I can only think of two explanations. One is that you've made some error of observation or interpretation. The other is that you've discovered some very strange bug that has never been reported before. As I wrote earlier, the commit, save to file, and reload are all lossless operations. I can never rule out the possibility of strange bugs, but on the other hand I have no idea how to fix an unlikely bug that I cannot reproduce. If you can provide a project and a test sequence that shows the problem, I will be happy to investigate.

--Rik

Luisifer
Posts: 112
Joined: Wed Sep 05, 2018 1:40 am
Location: Czech Republic
Contact:

Post by Luisifer »

rjlittlefield wrote:It sounds like you are saying that Edit > Commit Retouching, followed by Edit > Start Retouching from the new output image, gives a different result from just continuing to retouch, without a commit and re-start.
Exactly. Ok, i am uploading pack of project now.

rjlittlefield
Site Admin
Posts: 23561
Joined: Tue Aug 01, 2006 8:34 am
Location: Richland, Washington State, USA
Contact:

Post by rjlittlefield »

Luisifer wrote:BTW. it looks like whole thing about "Retain extended dynamic range" is very problematic. Maybe it would be easier to leave that option and hold rendered values unchanged in some 32bpch kind with possibility to use it as input file too
That possibility is already on the short list for future enhancements, as an extension to adding slabbing as an integrated part of Zerene Stacker. As always, I make no predictions about when anything might happen.

-Rik

rjlittlefield
Site Admin
Posts: 23561
Joined: Tue Aug 01, 2006 8:34 am
Location: Richland, Washington State, USA
Contact:

Post by rjlittlefield »

Luisifer wrote: Point is that after few releasing of mouse (or pen) the brightness is stabilizated and other new click/drawing over that area doesn't change anything. But.... after commiting stable retouching there is created new ZSY file and new retouching from that ZSY file in some close location which can be so close that it is necessary to overlay strokes over the previous retouching that cause new change of brightness.
OK, I have studied your description, thought about this some more, and I think I figured out what's happening.

As background, let me first tell more about how the default brush works inside the code.

The default brush uses the Laplacian pyramid representation of source and target images. When you paint with the default brush, what you're actually doing is constructing a binary mask at the most detailed level of the pyramid. Pixel values in the retouched image are constructed from a combination of three things: pixel values in the target image before retouching, pixel values in the source image, and the mask. All operation is done in pyramid representation, except for conversion to ordinary pixel values for display. There are some shortcuts to get interactive speed, but for practical purposes the system acts as if each brushing operation adds to the mask and then completely reconstructs the retouched image from its initial state, the source image, and the current state of the mask.

As long as you keep retouching from the same source image, the mask only becomes more dense (unless you "undo" a change).

However, when you switch to a different source image, the effect of the mask gets applied to "lock in" changes from the current source image, and the mask itself gets reinitialized to zero for the new source image. Essentially the same thing happens when you switch from Details brush to Pixels, Darken, or Lighten.

Now for the important part: Edit > Commit also does this same thing. If you are using the Details brush, then the aggregate effect of the mask gets applied and the mask itself gets discarded, just as if you were going to a new source file or switching brush types. Then when you Edit > Start Retouching from the committed image, you start with a newly initialized mask, not the mask that you were using when you did the Edit > Commit.

So, my statement that Edit > Commit etc is lossless, was not correct. The commit sequence is lossless with respect to the pixel values, but if you were using the Details brush, the mask is discarded. As a result, a brushstroke with the Details brush, on the same source image, after the commit sequence, will not do exactly the same thing that it would have before the sequence. The differences will be particularly obvious when the brush is large and overlaps or comes close to other large regions that have been previously brushed.

Can you check whether this matches the behavior that you're seeing? A good test would be to just switch the brush type instead of doing a commit/restart sequence.

--Rik

Luisifer
Posts: 112
Joined: Wed Sep 05, 2018 1:40 am
Location: Czech Republic
Contact:

Post by Luisifer »

I just made short tests.

First case when i stabilize area with detail brush, switch to pixel brush, draw anywhere else, switch back to detail brush and yes, it is changing again like after mentioned commiting.

But second case, when i use only default brush, switch to other input image and come back to previous input image, i didn't find changing.


I already uploaded project so do you want it or it looks like it is not necessary now? :)

Luisifer
Posts: 112
Joined: Wed Sep 05, 2018 1:40 am
Location: Czech Republic
Contact:

Post by Luisifer »

rjlittlefield wrote:That possibility is already on the short list for future enhancements, as an extension to adding slabbing as an integrated part of Zerene Stacker.
This would be super, i am looking forward when that happen. :)

rjlittlefield
Site Admin
Posts: 23561
Joined: Tue Aug 01, 2006 8:34 am
Location: Richland, Washington State, USA
Contact:

Post by rjlittlefield »

Luisifer wrote:I already uploaded project so do you want it or it looks like it is not necessary now? :)
Maybe it's not necessary, but since you've already uploaded it, send me a link and I'll pull it down just in case.

--Rik

Luisifer
Posts: 112
Joined: Wed Sep 05, 2018 1:40 am
Location: Czech Republic
Contact:

Post by Luisifer »

I noted one other issue. When i use retouching with faster strokes (doesn't matter if it is mouse or tablet, but tablet is easier to use faster strokes with enough reliability) so there are gaps without applicated brush.

https://12in.cz/temp/fast_stroke.jpg

Is it only my problem and/or is it possible to solve it over some setting or is it real problem of app? I am not very happy with this issue moreover with used quite strong HW (AMD 2700X, 64 GB RAM, WX7100).

(On printscreen are used all the brushes from Details on top to Lighten on bottom. With stroking from left to right.)

rjlittlefield
Site Admin
Posts: 23561
Joined: Tue Aug 01, 2006 8:34 am
Location: Richland, Washington State, USA
Contact:

Post by rjlittlefield »

When i use retouching with faster strokes (doesn't matter if it is mouse or tablet, but tablet is easier to use faster strokes with enough reliability) so there are gaps without applicated brush.
Zerene Stacker implements the brush by retouching a circle at each sampled position of the cursor. It does not interpolate between sampled points to retouch an extended stroke.

Typically the sampling is fast enough to present no problem unless either the brush is very big (hundreds of pixels wide) or the screen refresh rate is very slow.

Usually when people have trouble with this it is because they are running on one of the relatively few Macs that insist on repainting the entire window on every change, instead of just the area around the brush as ZS requests. In this case the problem also affects basic movements of the brush even when the mouse button is not pressed. It makes the brush very sluggish whenever you are in retouching mode. In this situation (on Mac) switching Options > Preferences > Look & Feel from "Native Look & Feel" to "Java cross-platform Look & Feel" has been reported to solve the problem. A few users have reported that they can avoid the problem on their machines by not running certain other apps at the same time as Zerene Stacker.

I do not recall anyone reporting the behavior as a problem on Windows, so I am wondering if there is something unusual about screen repainting on your particular machine, analogous to what happens on the troublesome Macs.

When you are in retouching mode, just moving the brush around, does the brush circle move smoothly or does it jerk around? If the latter, about how many updates per second do you see?

--Rik

Luisifer
Posts: 112
Joined: Wed Sep 05, 2018 1:40 am
Location: Czech Republic
Contact:

Post by Luisifer »

Thank you for the hint. I had running Boinc on background (but it use CPU on the lowest priority). With stopped Boinc it is better but not perfect (Like in PS O:-) ). With more apps runing it fells like about 10 frames per second and yes, it jerk on moving only the brush around too.

Peak of the CPU utilization with the brushing is about 30% but when all cores are used with other procesess and lowest priority the utilization jumps maximally to 16% (W10).

My previous post was thanks to noticing that behavior with default brush too (looks like main issue is sharing of CPU). Before that i noticed it only with other types of brush even with small brush diameter.



I tried to switch on "Java cross-platform look & fell" and it feels like step forward (i will stay with this setting) even with not utilized CPU by other processes. And it looks like the peak of CPU utilization jumps higher than in native look. (maybe i am too spoilt by PS where the strokes are very smooth)

rjlittlefield
Site Admin
Posts: 23561
Joined: Tue Aug 01, 2006 8:34 am
Location: Richland, Washington State, USA
Contact:

Post by rjlittlefield »

There's one other external setting that might make a difference: Options > Preferences > Look & Feel > "Use safer method to draw screen images".

Try that both ways and let us know what happens.

There's also one other internal setting that can be changed only by manually editing the zerenstk.cfg file. If you want to mess with that, please contact me as support@zerenesystems.com .

One last thing, be sure you have enough memory allocated -- between 100 MB and 200 MB per each 1 megapixel. It doesn't happen often, but if memory gets tight in just the wrong way, then screen painting can also trigger lots of garbage collection.

--Rik

Luisifer
Posts: 112
Joined: Wed Sep 05, 2018 1:40 am
Location: Czech Republic
Contact:

Post by Luisifer »

Ok, thanks, i can try it. :-) And i didn't noticed difference in brush when the setting of "safer method" was changed.

Maybe another idea which should help to "see" (helps to eliminate looking over of gabs), hot key (like "s"/ALT) which would show the "mask" (m?) over the retouched screen. Mask (for example transparent red) with already mentioned binary mask where would be easier to notice areas where the retouching miss.

Image

Post Reply Previous topicNext topic