Some enfuse questions from a serious and desperate user

[Mark Abeln]

Greetings,

I have been a user of enfuse since 2008, and I find it a great tool, especially when there are moving objects in my scene. I’ve used it extensively for my first three books, and right now I’m working on my fourth coffee table photo book using enfuse.

But I’ve hit some problems which I have difficulty overcoming. I started my book project on April 30th, and it is due to my publisher on June 1st, and so I am getting desperate.

My current book has subjects — brightly colored lights taken at dusk and night — where it is very important to retain as much of the color and saturation of highlights as possible. However, it is also important to avoid plugging the shadows too much — printers don’t like large areas of black with lots of ink, and in general it is bad photographic practice having large areas of a photo without texture.  In the past, the dynamic range of my subjects were not so great that this was much of a problem. I generally use alpha masks extensively, masking out areas of overexposure of any one color channel, while also masking out the darkest parts. I do make sure that I have a broad enough range of photos that I have well-exposed detail from the brightest highlights to the darkest shadows. 

To preserve my highlights, I am attempting to use the l-star gray projector, but am finding lots of green dots in the shadows. I’ve searched through these forums for an answer to this, but I haven’t found a specific answer to avoid this. 

Also, I find that l-star is often unpredictable: usually it plugs my shadows but sometimes it does not. What do you think may cause plugging in some situations and not in others? Now, I usually avoid the shadow plugging by manually blending together an “l-star” with an “average”, excluding the shadows from the l-star. But with the green dot problem, I find there are too many to detect reliably.

I am running OS X Lion on my Mac, and am running enfuse build 4.0-753b534c819d.  

Now, I read that enfuse 4.1.1 has some great features, and specifically has the pl-star gray projector which is designed to work with profiles with a gamma imposed. I assume that earlier versions of enfuse also wants a linear gamma for many of its projectors? I did not notice this caveat with early version of enfuse, but I noticed it in the version 4.0 manual. I haven’t had much success with blending linear images: it does not appear that Photoshop 32 bit images are supported (enfuse just outputs black images) and 16 bit images lack shadow detail, and so linear gamma tends to block up the shadows excessively.

I was unable to find enfuse 4.1.1 for Mac OS X, so I pulled out my old Windows XP PC, which I haven’t used since 2008, and attempted to run 4.1.1 on that.  But it always crashes. Now, Microsoft is having me install hundreds of updates, so perhaps it will eventually run. Is there something that I need to know about the operating system requirements of the Windows implementation?

If there is an OS X build of enfuse 4.1.1, that would be delightful! Where might I get it?  If not, I would like to get the PC version running.

Once I do have 4.1.1 running, what are the best practices for what I am trying to do? I am seeking well-colored tones from almost the deepest shadows to almost the brightest highlights. 

Thanks!

[___matthieu___]

Hi,

[...]

> If there is an OS X build of enfuse 4.1.1, that would be delightful! Where
> might I get it?  If not, I would like to get the PC version running.

you can grab my build of hugin that comes with a build of enblend
4.1.1

It should work on macosx 10.6 and up.

Please note that this is still a beta build so do not erase your
stable build.

http://matthieu.desile.free.fr/hugin/Hugin-Release-2013.0.0.6320-53691abbeb55-10.6.dmg

> Once I do have 4.1.1 running, what are the best practices for what I am
> trying to do? I am seeking well-colored tones from almost the deepest
> shadows to almost the brightest highlights.

That I do not know :(

Cheers,

Matthieu

[Mark Abeln]

Dear Matthieu,

This works!  I was able to use some of the new features, which worked out very well for what I am doing. I suspect that this will speed up my workflow. 

I did get the error:

terminate called after throwing an instance of 'std::runtime_error'

  what():  Minimizer1D::set_bracket: minimum not bracketed

Abort trap: 6

which I was able to avoid by using:

—no-ciecam

Again, thank you very much.

Mark 

[cspiel]

Mark -

> My current book has subjects -- brightly colored lights taken at
> dusk and night -- where it is very important to retain as much of

> the color and saturation of highlights as possible.  However, it is

> also important to avoid plugging the shadows too much -- printers

> don't like large areas of black with lots of ink, and in general it
> is bad photographic practice having large areas of a photo without
> texture.

        Several ideas come into my mind.

(1) Utilize Enfuse's CIECAM-mode either by forcing it with option
    `--ciecam' on input images w/o ICC profiles or, much better, feed
    images into Enfuse that all have the same ICC profile.  16-bit per
    channel in conjunction with the ProPhoto RGB space are promising.

    However, CIECAM-mode is broken with newer versions of the
    LittleCMS library.  Preliminary fixes have been applied to the
    development branch ("compressor road"), but not yet to the
    stable branch.

(2) Play with the `--exposure-cutoff' option, which was designed to
    tame extreme over- or underexposure.  Usually one can leave this
    option's gray projectors alone.

(3) The current development version of Enfuse offers user-defined
    exposure weighting functions.  So, either given enough
    C++-programming proficiency or a grumpy, greasy, growling hacker
    near you, almost any exposure weight is possible.

> To preserve my highlights, I am attempting to use the l-star gray
> projector, but am finding lots of green dots in the shadows.  I've
> searched through these forums for an answer to this, but I haven't
> found a specific answer to avoid this.

        These are more or less expected artifacts from non-CIECAM
blending, which in fact is RGB-cube blending without any sensible
limiting.  Working inside the RGB cube is fast and good enough for
most Enfuse users most of the time, though.

Because of changes in the LCMS library, we depend on in CIECAM mode,
brightly colored pixel artifacts sometimes show up there too, where
they should not.  About half a dozen patches went into the current
development branch of Enblend and Enfuse to fix this problem.  Still,
neither am I sure that the artifacts are gone, nor can I guarantee
that the next change to LCMS does not cause new trouble.  Panta rhei.

> I did get the error:
    terminate called after throwing an instance of 'std::runtime_error'
      what():  Minimizer1D::set_bracket: minimum not bracketed
    Abort trap: 6
> which I was able to avoid by using:

>   --no-ciecam

        Gee, that sucks!  This exception is also related to changes to
LCMS; you ran into a "never reached" branch.  I have completely
revamped this part of Enblend/Enfuse in a way that this problem never
occurs again.  Instead a more general (but slower) optimizer will take
over.


HTH,
        Chris

[beku]

Am Samstag, 18. Mai 2013 08:58:58 UTC+2 schrieb cspiel:

(1) Utilize Enfuse's CIECAM-mode either by forcing it with option
    `--ciecam' on input images w/o ICC profiles or, much better, feed
    images into Enfuse that all have the same ICC profile.  16-bit per
    channel in conjunction with the ProPhoto RGB space are promising.

    However, CIECAM-mode is broken with newer versions of the
    LittleCMS library.  Preliminary fixes have been applied to the
    development branch ("compressor road"), but not yet to the
    stable branch.

Because of changes in the LCMS library, we depend on in CIECAM mode,
brightly colored pixel artifacts sometimes show up there too, where
they should not.  About half a dozen patches went into the current
development branch of Enblend and Enfuse to fix this problem.  Still,
neither am I sure that the artifacts are gone, nor can I guarantee
that the next change to LCMS does not cause new trouble.  Panta rhei.

Can you describe more specifically what you expected and what changed in which version of lcms. So it might be more easy to fill a bug report and get proper attention?

kind regards
Kai-Uwe
 

[cspiel]

Kai-Uwe -

Am Samstag, 18. Mai 2013 12:40:40 UTC+2 schrieb beku:
> Can you describe more specifically what you expected and
> what changed in which version of lcms.

        In fact, I can't.

My assumptions of the blending process are ridiculously naive:
        p' = t * p0 + (1 - t) * p1,  0 <= t <= 1.
where the ps are some relevant characteristics of pixels 0 and 1 to be
blended, e.g. some luminance measure.  Obviously, this equation can
return values for p' that are outside a color space for a specific
profile or even for an entire color space; think of p0 and p1 being
very close to the shell.  The Enblend/Enfuse code in question juggles
with three: RGB, JCh, and Lab.  And suddenly you're not in Kansas
anymore.

        In version 2.x LCMS introduced the "Unbounded CMM" (see,
e.g. http://www.littlecms.com/CIC18_UnboundedCMM.pdf), where the
library itself does not take care anymore to keep all values inside
the color spaces, but instead lets the user decide what to do with
"outsiders".  Enblend/Enfuse has picked up that idea and both programs
work on unbounded values as long as possible.  That way, the users get
most out of their input images (I'm talking about CIECAM mode only).
Finally, we have to catch all renegades and find a representation for
them _inside_ the RGB-cube defined by the input profile (per
definitionem our output profile).

Here we go to great lengths to pick a projection that minimizes the
deltaE of the unbounded renegade and the final in-cube image (see e.g.
"fixmath.h", method ConvertJCHPyramidToVectorFunctor::operator()).
During the process we evaluate the color space conversion formulas
outside of a regular color space (for the renegades) and barely inside
for the final pixel values.  I presume that not all formulas of LCMS
are numerically stable or even defined -- think of the notorious
pow(3) -- for all these values.  Furthermore, I can imagine that the
code of the formulas changes from time to time, "Unbounded CMM" being
a relatively new feature.  Maybe it returns exactly the same results
for inside-color-space pixels, but not necessarily for outside pixels
and we get hosed from time to time.  Just my thoughts, could be wrong,
nothing ex cathedra.

> So it might be more easy to fill a bug report and get proper
> attention?

        I have never called LittleCMS's behavior a "bug", as neither I
am aware of a mandatory specification, nor am I sure that Enblend/Enfuse
don't go over the top and LCMS simply gives.


Cheers,
        Chris

[Mark Abeln]

Greetings, 

I have nearly completed my book, and I would like to give thanks to the hard work of the developers. The stitched panoramas I created look magnificent and are particularly pleasing due to the General Panini projection, which gives me a convincing panoramic view with less obvious distortion. The many blends done with enfuse look excellent also, and have improved over my previous work thanks to the new “pl-star” option, which tends to give me a good blend the first time I use it on a set of images.

While it does not work with all my images, ciecam does a better job with rendering pleasing colors, and has allowed me to get a higher percentage of good blends on my first try. 

By the way, here is my previous book, and you can see the photo on the cover, which I blended with enfuse:

http://www.reedypress.com/book.php?show=9781935806332

Your software is essential to my work, and I am very grateful. 

Mark