SrcPanoImage's constructor doesn't take arguments any more. How to use it now?

[kfj]

In the latest version:

http://sourceforge.net/p/hugin/hugin/ci/default/tree/src/hugin_base/panodata/SrcPanoImage.h

SrcPanoImage's contructor doesn't take any arguments. There used to be a version of the constructor taking a filename:

SrcPanoImage(const std::string &filename) ...

This is gone now, and only the default constructor remains. How is one to make an SrcPanoImage from a file now? Probably some roundabout way like

SrcPanoImage i ;
i.setFilename ( "image.tif" ) ;
i.successfullEXIFread=readEXIF(fl, crop, true, true) ;

Anyway, is there a technical reason why the construction from a filename was thrown out? It breaks woa, so I'd like to know, and I'd like to have it back if possible ;)

Kay

[cspiel]

Kay -

    You are asking the wrong newsgroup.  It is preferable to
turn to the Vigra mailing list or to bug Uli directly.


On Friday, January 17, 2014 8:06:16 AM UTC+1, kfj wrote:

In the latest version:

SrcPanoImage's contructor doesn't take any arguments. There used to be a version of the constructor taking a filename:

    Vigra 1.10.0 changed the calls of object argument factories.
I'm looking forward to implement all the required adaptions to
Enblend/Enfuse.  No!  Just kiddin'.
 

Anyway, is there a technical reason why the construction from a filename was thrown out? It breaks woa, so I'd like to know, and I'd like to have it back if possible ;)

    In my experience, you don't get anything back.  You can write your own
wrapper functions or Facade patterns, though.  If the (Vigra or whatever) developers
later decide to subtly change the underlying semantics your are completely hosed.  See,
e.g. the history of Vigra's `stride' methods, which are extensively used in Enblend
and Enfuse.


/Chris

 

[kfj]

On Friday, January 17, 2014 1:29:54 PM UTC+5:30, cspiel wrote:

Kay -

    You are asking the wrong newsgroup.  It is preferable to
turn to the Vigra mailing list or to bug Uli directly.

I beg to differ. This is the hugin-ptx newsgroup, dealing with hugin amongst other things. If something bugs me in hugin's source code why on earth should I bug Uli with it? And where would you have me post? Particularly if it has nothing to do with vigra whatsoever?

Kay

[T. Modes]

Am Freitag, 17. Januar 2014 08:06:16 UTC+1 schrieb kfj:

SrcPanoImage's contructor doesn't take any arguments. There used to be a version of the constructor taking a filename:

SrcPanoImage(const std::string &filename) ...

This is gone now, and only the default constructor remains. How is one to make an SrcPanoImage from a file now? Probably some roundabout way like

Anyway, is there a technical reason why the construction from a filename was thrown out? It breaks woa, so I'd like to know, and I'd like to have it back if possible ;)

The old version was too inflexible. It resulted in too much read access to the files. This has been reduced as much as currently possible (and will therefore not restored).
Depending on the exact use case there are now different ways:

          HuginBase::SrcPanoImage srcImg;
          srcImg.setFilename(filename);

and then
          srcImg.setSize(size);
or
          srcImg.checkImageSizeKnown();
or
          srcImg.readEXIF();
          srcImg.applyEXIFValues();
or …

Thomas

[kfj]

On Saturday, January 18, 2014 2:23:40 PM UTC+5:30, T. Modes wrote:

Am Freitag, 17. Januar 2014 08:06:16 UTC+1 schrieb kfj:

SrcPanoImage's contructor doesn't take any arguments. There used to be a version of the constructor taking a filename:

SrcPanoImage(const std::string &filename) ...

This is gone now, and only the default constructor remains. How is one to make an SrcPanoImage from a file now? Probably some roundabout way like

Anyway, is there a technical reason why the construction from a filename was thrown out? It breaks woa, so I'd like to know, and I'd like to have it back if possible ;)

The old version was too inflexible. It resulted in too much read access to the files. This has been reduced as much as currently possible (and will therefore not restored).

I can't see the point. The version of the constructor without arguments was there before. If using the other version 'results in too much read access to the files', there is a simple solution to the problem: don't use that version; use the parameterless one. In C++ you can have as many constructors as you like, and having an extra one does no harm. Removing one which has been there constitutes an API change which is imho unnecessary.
 

Depending on the exact use case there are now different ways:

          HuginBase::SrcPanoImage srcImg;
          srcImg.setFilename(filename);

So I was right about the roundabout way... what makes it worse is that the other functions have also changed (readEXIF() took several parameters) or weren't there before (like checkImageSizeKnown()). So I'd have to write a new version of woa using the modified API. What's wrong about keeping the constructor-from-filename?

Kay
 

[kfj]

Grudingly, here's the patch. It also pulls all other plugins up to API level 2014.1, so that the Actions menu will show up. I've tested the plugins, they all run with this API version. In woa, I added code to reflect the loss of the SrcPanoImage coonstructor taking a filename.

https://www.dropbox.com/s/3jlhyyoosnis1g7/hsi.2014.diff

Kay

[Kornel Benko]

Am Sonntag, 19. Januar 2014 um 04:36:32, schrieb kfj <_k...@yahoo.com>

> Grudingly, here's the patch. It also pulls all other plugins up to API

> level 2014.1, so that the Actions menu will show up. I've tested the

> plugins, they all run with this API version. In woa, I added code to

> reflect the loss of the SrcPanoImage coonstructor taking a filename.

>

> https://www.dropbox.com/s/3jlhyyoosnis1g7/hsi.2014.diff

>

> Kay

 

Applied. Compilation was OK. Tested woa ... works again. Thanks Kay,

I opt for commit. (And for not changing the API again)

 

Kornel