Working with save-masks

72 views
Skip to first unread message

Martin Knowles

unread,
Mar 9, 2016, 5:46:19 PM3/9/16
to hugin and other free panoramic software
I've been experimenting with the save-masks option for dealing with architectural subjects, and what I'd like to do is load the images with their mask results as layer masks into Photoshop so that they can be tweaked easily, and then merge the final result in Photoshop, if possible.

Is this a workflow that ought to be workable? If it is:

1. since the masks are saved as float tiff, and they need to end up as Photoshop layer masks, the logical thing would be to convert the psd to 32bpp, then use Apply Image/channel paste to get the masks in. However, this is going to cause Photoshop to tonemap the output, which isn't ideal. Any good way around this?

2. What PS blending mode (or is there one?) would match how Enfuse merges?

3. Is there a good way to create the masks or convert them to a format that's more easily usable--like tif8 or tif16, rather than float tiff? (I've tried opening them in PS, and converting them down with linear gamma, but this seems not to work particularly well). Or is there something inherent to the algorithm that makes it work a lot better with float tiff masks?

Thanks!

-=Martin

Sean Greenslade

unread,
Mar 9, 2016, 11:11:56 PM3/9/16
to hugi...@googlegroups.com
On Wed, Mar 09, 2016 at 01:20:42PM -0800, Martin Knowles wrote:
> I've been experimenting with the save-masks option for dealing with
> architectural subjects, and what I'd like to do is load the images with
> their mask results as layer masks into Photoshop so that they can be
> tweaked easily, and then merge the final result in Photoshop, if possible.
>
> Is this a workflow that ought to be workable? If it is:
>
> 1. since the masks are saved as float tiff, and they need to end up as
> Photoshop layer masks, the logical thing would be to convert the psd to
> 32bpp, then use Apply Image/channel paste to get the masks in. However,
> this is going to cause Photoshop to tonemap the output, which isn't ideal.
> Any good way around this?
>
> 2. What PS blending mode (or is there one?) would match how Enfuse merges?

There is no (AFAIK) blending mode that matches what enfuse does. Enfuse
uses 4 different algorithms, each with their own adjustable weighting,
to do the fusion. To get the best results, you would want to modify the
masks, save them out, then run enfuse with --load-masks.

> 3. Is there a good way to create the masks or convert them to a format
> that's more easily usable--like tif8 or tif16, rather than float tiff?
> (I've tried opening them in PS, and converting them down with linear gamma,
> but this seems not to work particularly well). Or is there something
> inherent to the algorithm that makes it work a lot better with float tiff
> masks?

Not having explored the enfuse code, I would imagine it's easier to use
floats to avoid a bunch of conversions (since the enfuse engine likely
uses floats internally). However, if Photoshop doesn't like dealing with
float tiffs, you may need to convert them with an outside tool (e.g.
imagemagik). You would then need to convert them back after
modifications, of course.

Sorry I don't have any more specific advice, however I don't use
Photoshop.

--Sean

cspiel

unread,
Mar 10, 2016, 10:39:41 AM3/10/16
to hugin and other free panoramic software
On Wednesday, 9 March 2016 23:46:19 UTC+1, Martin Knowles wrote:
    I've been experimenting with the save-masks option for dealing with architectural subjects,
    and what I'd like to do is load the images with their mask results as layer masks into Photoshop
    so that they can be tweaked easily, and then merge the final result in Photoshop, if possible.

Another photoslop non-user here, but at least an Enblend/Enfuse developer.



    1. since the masks are saved as float tiff, and they need to end up as Photoshop layer masks,
    the logical thing would be to convert the psd to 32bpp  <snip>

Did you try to convert the masks with convert(1) of ImageMagick suite?

@Sean: Internally Enblend and Enfuse use fixed-point representations
for the pixels stored in the pyramids.  So, close but no cigar.  The
tantalizing templated traits class code making this happen lives in
http://hg.code.sf.net/p/enblend/code/file/2b82418c3fed/src/numerictraits.h



    2. What PS blending mode (or is there one?) would match how Enfuse merges?

The key feature of Enfuse (and also Enblend) is the multi-resolution
spline algorithm.  See the Enfuse documentation for details and also
for references to the original papers of Burt and Adelson and in
particular Mertens, Kautz, and Van Reeth.



    3. Is there a good way to create the masks or convert them to a format that's more easily usable
       Or is there something inherent to the algorithm that makes it work a lot better with float tiff masks?

Either write the mask files in a format that does not support
floating-point pixels, or use the parameter introduced in
rev 2b82418c3fed to force the pixel type of the masks.
http://hg.code.sf.net/p/enblend/code/rev/2b82418c3fed

Be aware that I have not tested the complete round-trip.
Give me a buzz if it breaks.


THX,
    Chris

Martin Knowles

unread,
Mar 10, 2016, 2:00:18 PM3/10/16
to hugin and other free panoramic software
Thanks for the explanation. I took a look at the original paper, and chunks of the enfuse source code (my, it's been a long time since graphics courses as part of my CS degree...;-) and it looks like the most efficient thing to do is to modify the alpha masks on the original input, rather than trying to do the final stack in Photoshop. Although: if enfuse's implementation matches the algorithm, the results from taking each image, setting alpha from the results of save-masks, and adding the results should produce the same result as assembling the final output via enfuse, correct? Or does weighted blending happen after mask computation?

cspiel

unread,
Mar 10, 2016, 3:12:13 PM3/10/16
to hugin and other free panoramic software
Martin -

On Thursday, 10 March 2016 20:00:18 UTC+1, Martin Knowles wrote:

>  Thanks for the explanation.

    You're welcome.


> ...

> and it looks like the most efficient thing to do is to modify the
> alpha masks on the original input, rather than trying to do the final
> stack in Photoshop.

        It depends.  ;)

If your input images contain unwanted parts you can mask them out in
the input images' alpha channels (as usual).  Enfuse will naturally
"fill the holes" for you if that is at all possible.  Tinkering the
input masks seems good for those all-or-nothing-at-all problems.

OTOH, if you modify the saved masks, all the pixel weighting
operations (exposure, saturation, ...) already were performed _and_
the alpha channels of all input images played their parts.  Modifiying
these masks and feeding them is better suited if you want to overrule
Enfuse's notion of weights.

There may be much more possibilities, but these are the ones that
come to my mind.



> Although: if enfuse's implementation matches the algorithm, the
> results from taking each image, setting alpha from the results of
> save-masks, and adding the results should produce the same result as
> assembling the final output via enfuse, correct?

        It is an "either/or", not both.  See e.g. Section 3.2
`External Masks' in the new documentation of the upcoming Release 4.2.
Enfuse _either_ computes the weights and blends the input images
accordingly _or_ it does not compute any weight, but takes the mask
images (passed in with `--load-masks') and then blends according to
the loaded masks' contents only.



> Or does weighted blending happen after mask computation?

        Multi-resolution blending kicks in either after all
weights have been computed or after all masks have been loaded.
It is always later in the processing queue.


Please let me know, if that answers your question, as I'm afraid I've
got to add a paragraph or two to the (new) documentation.


Cheers,
        Chris

Martin Knowles

unread,
Mar 10, 2016, 5:03:05 PM3/10/16
to hugin and other free panoramic software
Thanks! That was what I needed to know.

Reply all
Reply to author
Forward
0 new messages