Sean,
I think that an API to provided overloading to SetFilename() would be nice.
SetFilename(std::string myfilename) …. Of course keep the old name.
{
NewIOStreamObjectExtractorThingy * nios = NewIOStreamMultiFileObject();
nios.SetHeaderInformation( myfilename );
SetFilename( NewIOStreamObjectExtractorThingyBaseClass * nios);
}
NewIOStreamObjectExtractorThingy * nios = NewIOStreamMultiFileObject();
nios.SetHeaderInformation(“my.hdr”);
nios.SetDataStream(“my.img”);
SetFilename( NewIOStreamObjectExtractorThingyBaseClass * nios) … To support new
IO mechanism flexibility.
===========
I’m trying to think of an interface that would support interfacing with
databases or URL’s.
Hans
On 1/8/16, 1:00 PM, "Insight-developers on behalf of Sean McBride"
<[email protected] on behalf of [email protected]> wrote:
>Hi all,
>
>Some (annoying) file formats like Analyze and PhilipsREC come in pairs: one
>metadata file and one data file, ex: .hdr & .img and .par & .rec.
>
>The reader classes currently take the path to one of the files and then
>auto-guess/construct the other path. Of course this works most of the time,
>but is fragile for a few reasons:
>
> - the file name parsing code assumes ASCII.
> - the code has to guess the case of the pair file. ex, if you provide
> foo.HDR, it has to guess either .img or .IMG, and this may succeed or fail
> depending if the file system is case sensitive or not. To say nothing of
> users maybe having mixed case names like "foo.imG".
> - OSes these days often sandbox access to the file system and this guessing
> around of paths can cause sandbox violations (which could be merely warnings
> or errors depending on OS).
>
>I'd like to propose new API for such file readers, specifically that clients
>can pass the path to *both* files. Then no fragile is guessing is needed. We
>wouldn't need to change existing API, merely add new ones.
>
>But before starting, I'd like to know if this would be accepted...
>
>Thanks,
>
>--
>____________________________________________________________
>Sean McBride, B. Eng [email protected]
>Rogue Research www.rogue-research.com
>Mac Software Developer Montréal, Québec, Canada
>
>
>_______________________________________________
>Powered by www.kitware.com
>
>Visit other Kitware open-source projects at
>http://www.kitware.com/opensource/opensource.html
>
>Kitware offers ITK Training Courses, for more information visit:
>http://kitware.com/products/protraining.php
>
>Please keep messages on-topic and check the ITK FAQ at:
>http://www.itk.org/Wiki/ITK_FAQ
>
>Follow this link to subscribe/unsubscribe:
>http://public.kitware.com/mailman/listinfo/insight-developers
________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the
Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and
may be legally privileged. If you are not the intended recipient, you are
hereby notified that any retention, dissemination, distribution, or copying of
this communication is strictly prohibited. Please reply to the sender that you
have received the message in error, then delete it. Thank you.
________________________________
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php
Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-developers
