hugin-devs team mailing list archive

[Christoph Spiel <cspiel@xxxxxxxxxx>]

Your proposal sounds sensible and I wonder why nobody came up with
something comparable before.  Also surprising for me was the general
ignorance of your suggestions in the news group.

Adding all your technical-merit parameters would put a lot of baggage
into Enblend and Enfuse.  The next day someone has a another new idea
what to put into his/her weighting functions and we need even more
code.  This seems unmaintainable over the long haul -- in particular
as we have almost no "developer resources".

I have two possible (non-mutually exclusive) solutions in mind.  By
the way, each of them would lend itself to an interesting GSoC
project.

1. Implement a dynamic-load interface for Enblend and Enfuse.
1.1 Make Enblend/Enfuse extensible with the help of the dlopen(3)
      interface to the dynamic linking loader.
1.2 Insert one or more interface classes into Enblend/Enfuse through
      which dynamically loaded extensions can access _all_ data
      (including e.g. meta data and ICC profiles) of _any_ input image
      and the output image.
1.3 Allow the dynamic extensions to register call-back functions.
1.3.1 Enfuse: the user-defined extensions are called for each pixel
      in each input file.
1.3.2 Enblend: the user-defined extensions are called for the
      lightness levels (only 2^8 calls necessary), contrast levels,
      etc.
1.3.3 Supply the user with a script that compiles and links simple
      extensions in one pass without detailed knowledge of the
      underlying build process.
1.4 Prospects
1.4.1 Fast, because the user code gets compiled.
1.4.2 The user must compile her extensions with a compiler (and
      compiler settings) that are compatible to the binaries.
      However, 1.3.3. helps here.
1.4.3 Supplying new command-line options with a dynalinked extension
      could turn out "interesting" to implement correctly.


2. Integrate a Guile interpreter into Enblend and Enfuse.
2.1 Use a Guile interpreter to dynamically extend Enblend and Enfuse.
2.2 Like 1.2.
2.3. Supply "enough" hooks for Scheme user functions to allow the user
      to implement her own weighting strategies and much more.
2.4 Prospects
2.4.1 Guile has been developed for exactly this use case: extending
      existing applications.
2.4.2 Easy to use; Scheme is simple to learn.
2.4.3 No extra tools required.
2.4.4 Many internals of Enblend and Enfuse can be made
      configurable with user-accessible Guile functions.
2.4.5 Probably slow; certainly slower than 1.
2.4.6 Some interpreted user functions could be called from parallel
      regions of the C++-code.  This certainly raises "interesting"
      problems with races, deadlocks, and of course performance of an
      interpreted language in such an environment.


** Changed in: enblend
       Status: New => Triaged

** Changed in: enblend
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/927509

Title:
  enfuse feature proposal: weighting 'technical' qualities

Status in Enblend:
  Triaged

Bug description:
  Hi all!

  Enfuse assesses the intensity values of corresponding pixels in the
  set of source images, or values derived from intensity values. Yet at
  times, it would be desirable to look at qualities which have nothing
  to do with intensity-related values. You may ask what these qualities
  might sensibly be, so let me propose a few:

  - focal length of the source image

  when stacking images done with different lenses, if priority is given
  to an image taken with a longer lens, forcing patches with higher
  resolution into a lower-res image becomes simple. Often only a section
  of the target image is covered with the longer lens - like a horizon
  sweep with a standard wide angle lens which is to be layered on top of
  a fisheye set. In this situation, actual blending of the low-res and
  high-res content is undesirable, and using a steep weighting function
  or a hard mask, this could be used to use only the high-res content
  where available. This would make the process of layering higher-res
  content simple and much more convenient than having to deal with masks
  and layers in an image processor further down the line, yet may
  provide perfectly adequate results.

  - other photographic parameters

  analogous to focal length, other parameters spring to mind which might
  be used for prioritization, as exposure time and aperture

  - additional band information

  weighting might have already been derived from some external
  mechanism. This weight might have been stored in a band of the image -
  be it an additional band specifically added for this purpose, or, for
  example, the alpha channel coerced into this function.

  - sequence in the list of input images

  currently, weighting is independent of the order of the input images.
  Yet at times it might be desirable to give more weight to some images
  than to others based on considerations which needn't concern enfuse.
  Giving weight to argument order would be a simple way of allowing
  this. Alternatively one might use

  - explicitly modified weights

  currently, weighting is 'egalitarian' insofar as a pixel which has
  'more' of a certain quality will score 'better' and only global
  statistic parameters can be used to modify this behaviour. At times
  one might wish to 'cheat' and simply prefer some images over others.
  Passing explicit weight modifying factors in the command line could
  provide for such a feature.

  - distance from nearest transparent pixel

  when blending in patches, this parameter could be used to effect a
  smooth transition into the content of the patch, like a feathering.

  so much for my bit of brain storming. I'm certain that the concept of
  'technical' weighting can produce new possibilities for enfuse, making
  it an even more verstile tool. I'd be curious to see more ideas
  following this template, as I'm sure there must be.

  You may have noticed that some of my proposals would conventionally be
  seen to belong to the blending domain rather than to the fusing
  domain. In fact both might benefit from relaxing the boundaries.
  Enblend would do well to offer parameters to prioritize certain
  content. Yet again the field where I have most missed such
  functionality is in insertion of higher-res patches, which is
  cumbersome and circuiticious in my current work flow.

  Kay

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/927509/+subscriptions