Show undefined / unknown file formats as well.

[Mike]

iMatch is really great! But there would be hardly anything more reassuring than knowing, whether a folder is really empty, or contains more files, than we can see. If we don't know, we are afraid to make mistakes, e.g. accidentally deleting things. This leads to unfavorable behavior and increased effort:

a) Instead of acting directly, we often have to take a control look in Windows Explorer.
b) Or we have to spatially separate supported and unsupported files, which is an additional effort and more format- than needs-oriented.
c) And that also leads to separate management (iMatch, Windows Explorer, ...), which worsens the overview and increases the effort.

It would therefore be great, if the following solution could be implemented:

1. Always show all files, including "not well supported" ones! We wouldn't guess, if there was something, we'd know. If a file is visible in Win Explorer, then it would be visible in iMatch too.
2. Unknown file formats could - in the worst case - all share the same icon. A kind of "no-idea-what-that-is" icon. We'd know right away, that it was something exotic and at least see the file extension. In the best case we would have the same Icons displayed as in Win Explorer.
3. If we have time, we would deal with the unknown files and define the formats more precisely. But we would be free to decide whether and when to do it without having to give up the certainty, that we always know THAT something is there.
4. They could be reduced to only the simplest display, even without annotations, when this causes trouble for exotic formats. At least we know they are there.

Result: more time, more freedom, more safety

Thanks and Best Regards!

[Mike]

Some may only want to see image files, others want to keep an eye on everything.
If the displayed file types could be switched on and off, there would be no dispute ;-)

[Mario]

to make mistakes, e.g. accidentally deleting things.

One of the core principles of DAM is to not mix managed and unmanaged files in the same folder.
When you delete a folder that contains files IMatch has not indexed, IMatch will warn you. But it is always better to not mix managed and unmanaged assets.

IMatch is not a file system browser. It manages assets, and only the assets you tell it to manage.

Adding features which somehow replicate Windows Explorer and temporarily mix these unmanaged files with the assets managed by the IMatch database would be technically difficult and complicate all internal code paths dealing with files. And the file window. What if a filter is active? What if a file format filter is active or a search operation or ...?
I doubt that more than a few user will use that more than a couple of times a year. This was never before requested, which is a good indicator.

If you want to manage files not covered by the 100+ file formats IMatch knows about by default, you can either ask to include these formats into IMatch or you add them as user-defined file formats in File Formats

[sinus]

to make mistakes, e.g. accidentally deleting things.

If you want to manage files not covered by the 100+ file formats IMatch knows about by default, you can either ask to include these formats into IMatch or you add them as user-defined file formats in File Formats

That works fine for me, if I must have a new format, I add it in the preferences.
Lately I have to add quites some file-format (and still will have to, I guess).

Specially for 3D-images I had to add formats like stl, ocr, mtl and so on. It seems, with 3D-formats, there is quite a bit a jungle. 

[Mike]

I understand your reasoning.

A general Windows Explorer replacement would not be of interest to me either. Windows Explorer is sufficient for the system partition, Windows and programs.

But I think it would be great to organize entire workspaces (entire project folders) with iMatch because:
a) iMatch has organizational capabilities far superior to Windows Explorer.
b) Data could then be handled in exactly the way that is best for action efficiency. Organized according to meaning not according to format similarity.
c) All files involved would automatically follow the same organizational rules.

"If we don't know, we are afraid to make mistakes, e.g. accidentally deleting things." - I actually meant moving, renaming, etc. folders too. And yes, it is very helpful to have warnings in iMatch. However, I feel more secure when I can see files too. But it's not just about more security, you have a better overview and it's easier to remember ongoing processes.

To make it clear, my suggestion did not come about, because I find iMatch "incomplete", on the contrary, because I would like to extend valued properties to other things ;-) But as iMatch developer, of course, you have a much better overview of the feasibility and complexity of such a proposal.
Maybe I am challenging the limits of iMatch because my work differs from the presumably average use of a DAM system. I use a lot of image material, but my work is strongly networked with scientific research of a completely different kind. I work in systems and subsystems of networked things and less in typical assets, which I also have. Even so, iMatch still helps me a lot. I will try to optimize the interaction between iMatch and work system even better. At least we can define our own formats in iMatch, even if not automatically. This is very helpful!

If you want to manage files not covered by the 100+ file formats IMatch knows about by default, you can either ask to include these formats into IMatch

This ist great, I'll think about that.

A format that I can already name is ".mmap". These are Mindjet MindManager Mind & Concept Mapping files. I was able to define and display a format in iMatch, but without a thumbnail, as I see it in Win Explorer (a screenshot of the current concept map status). I tried several classes without success: Auxiliary, Image, PDF, Office.

[Jingo]

I understand your reasoning.

A general Windows Explorer replacement would not be of interest to me either. Windows Explorer is sufficient for the system partition, Windows and programs.

Funny - I am on the complete opposite end and would not own a PC without a Explorer replacement like XYPlorer.  The lack of multi-panes is the single biggest question mark so many decades after 3rd party software introduced it.  Scripting, filtering, highlighting, mousedown/over previews, the list goes on and on... like using a folder structure to manage your photos instead of a dedicated DAM... it functions but only goes so far.

[Mario]

A format that I can already name is ".mmap". These are Mindjet MindManager Mind & Concept Mapping files. I was able to define and display a format in iMatch, but without a thumbnail, as I see it in Win Explorer (a screenshot of the current concept map status). I tried several classes without success: Auxiliary, Image, PDF, Office.

I have never seen such a file. And probably every mind mapper tool out there has its own variety of formats.
When IMatch encounters a file which it has no internal handler for, it falls back to asking Windows to produce a thumbnail via the "shell handler". The results vary, but usually when you can see a thumbnail in Windows Explorer, IMatch can also show a thumbnail. This depends of course also on the generating software and it it has installed a thumbnail handler.

If Windows cannot produce a thumbnail, a warning W> will be written to the IMatch log file (log file) and the error message returned by Windows for the file. This may help to figure out why this does not work on your system.

I tried several classes without success: Auxiliary, Image, PDF, Office.

Did you force a rescan after changing the format assignment (Shift+Ctrl+F5 in the File Window)?


Regarding Managing all files

In my experience, the majority of users does not have/need/want unmanaged files and does not mix images or video with all kinds of other riff-raff.
When users encounter new standard formats (more or less) produced by applications, I'm happy to include them as official formats in IMatch.
The standard format list is growing a bit every year (also thanks to camera vendors who use 5 different extensions for the same file formats).
@sinus: Which application produces the formats you mention? Which extensions are used? Is there any kind of documentation?

In order to display a file in a File Window, IMatch has to ingest it into the database. Even if the file has no thumbnail, the basic file system data (and usually metadata as well) needs to be stored somewhere. This cannot be loaded just in time from the file system. This would require a totally separate "code path" in IMatch in order to display these non-managed files in a File Window.

And even if this would work, I would need to identify all edge cases, from the File Window Search Bar, sorting algorithms, the Filter Panel etc. which control how and which files are displayed in a File Window. And this could get nasty very quickly, binding a lot of development resources (unit = 1) for potentially a long time (weeks).

A potential solution would be to create a global switch for File Formats which is called "Ingest all files found". And then add logic and code to somehow deal with these uncommon file formats and put them into likely groups or a bucket group like Multimedia or maybe "Stuff".

I have no idea if and how many users would need this. Since this came never up before ("please add nnn as a standard format" or "My camera produces files with extension .nnn" requests come in one or twice a year), I doubt that many users would benefit from that.

But I'm always open to new features and ideas. Let's see what other users think about this. Please comment below.

[sinus]

@sinus: Which application produces the formats you mention? Which extensions are used? Is there any kind of documentation?

I am quite new (well, after a first jump-in in 2018) in 3D.
Hence I do not know a lot, except, that there are a lot of different formats.
I fact, they make such a "mess" of folders and files (they creates new folder and zip and ... automatically), that I  created for now a new IMatch-DB only for 3D (and some video-stuff).

Here are some formats, what I found, what seems to be quite often used in a 3D-world. But I am sure, there are dozens and dozens more out there: 
What I have lerned for sure are the 2 formats stl and obj, they are used very often.

A good explanations about formats is this link, I think: https://all3dp.com/3d-file-format-3d-files-3d-printer-3d-cad-vrml-stl-obj/
I believe, this is a german-company, but quite successful on 3D and they write for example:

The problem with 3D file formats is that there are literally hundreds of them. Every CAD software manufacturer such as AutoDesk and Blender has their own proprietary format which is optimized for their software. So if you use AutoCAD, you get a DWG file. If you use Blender, you get a BLEND file.

Here is also a link: http://edutechwiki.unige.ch/en/3D_file_format
Or here: https://www.marxentlabs.com/3d-file-formats/

I do not know, if this helps.

What I have lerned for sure, that for printing out 3D-stuff on a 3D-printer, very common and almost a standard it the format
stl
quote: Nowadays, STL is known to be the most common file format in 3D printing. Ever since its invention in 1987, it has remained to be the de facto standard in the 3D printing industry.
STL (Standard Triangle Language/Standard Tessellation Language) is the first file format developed for 3D printing. Its corresponding file extension is .stl.
STL files save 3D models as surface of geometrical shapes and turn it into a triangular mesh. But, it cannot display information about the model's colour or texture.

***

And another format, what uses a lot of 3D-software, is
obj
quote: OBJ (Wavefront OBJect) is a 3D printer file format that was originally used by graphics designers as a neutral interchange format for 3D graphics. It was first developed by Wavefront Technologies for its animation package. This file format has the extension .obj.
Unlike STL, OBJ can encode colour and texture information, it also supports both approximate and precise encoding of surface geometry. This means that it doesn't restrict its surface mesh to triangular facets. The designer can also use polygons such as quadrilaterals. However, OBJ doesn't support any kind of animation.

OBJ is often used when the 3D object requires more than one colour. It is also the choice of some developers because it offers a lot of flexibility on how it encodes the 3D model's geometry.
Aside from that, with OBJ, the designer can use more advanced schemes such as free-form curves and free-form surfaces. These schemes can be used to encode curved geometry without losing any data.
This file format is also widely used in industries such as aerospace and automotive which are demanding when it comes to precision.

***

Further I get a lot of mtl-file, but not directly, but somehow automatically, hence I am not sure aboout this
mtl
quote:     
The Wavefront Material Template Library (MTL) file is a companion file for one or more Wavefront OBJ files. Like the OBJ format, the MTL format was used and documented by Wavefront Technologies in the 1990s in association with its Advanced Visualizer software. The ASCII-based MTL file describes surface appearance properties to be applied to polygonal facets or freeform curved patches defined in an OBJ file. The MTL file is a "library" that can contain one or more named material definitions, each of which can specify color, texture, and reflection characteristics.

***

Then a format I found also quite a lot is
ply
quote: PLY is a computer file format known as the Polygon File Format or the Stanford Triangle Format. It was principally designed to store three-dimensional data from 3D scanners. The data storage format supports a relatively simple description of a single object as a list of nominally flat polygons. A variety of properties can be stored, including: color and transparency, surface normals, texture coordinates and data confidence values. The format permits one to have different properties for the front and back of a polygon. There are two versions of the file format, one in ASCII, the other in binary.

[Mario]

IMatch already supports Blender formats.
And .obj is used by many programming environments to store files in OBJ format. Looks like another hijacked file extension which now has multiple meanings.
I mean, the limit of 3 letters for file extensions has been lifted 10 or 15 years ago. Companies should really use more meaningful and unique file extensions, like Affinity does with .afdesign or .afphoto.

Regarding STL files for 3D Printers - not sure if we really would need this in IMatch?

If you look at the Wikipedia page for file formats you see why I cannot add all formats and usually just wait until users request the addition of a new format or I learn about new file formats uses by mainstream applications.

[sinus]

IMatch already supports Blender formats.
And .obj is used by many programming environments to store files in OBJ format. Looks like another hijacked file extension which now has multiple meanings.
I mean, the limit of 3 letters for file extensions has been lifted 10 or 15 years ago. Companies should really use more meaningful and unique file extensions, like Affinity does with .afdesign or .afphoto.

Regarding STL files for 3D Printers - not sure if we really would need this in IMatch?

If you look at the Wikipedia page for file formats you see why I cannot add all formats and usually just wait until users request the addition of a new format or I learn about new file formats uses by mainstream applications.

Yep, all formats add in IMatch would be 

STL seems to be simply the format for printing things out.
Means, if someone deals with 3D and want print a file out, then the chance is bit that this format is stl.

Now, 3D is still (I guess) not that wide in use!?
And from the IMatch-users maybe only a handful!?

But if someone wants to store such 3D-stuff inside IMatch, and she/he prints works out, then stl should be there in IMatch.
BUT, as usually, if I find not a format in IMatch, I add it myself. 
(I should to clean this a bit up (Agisoft e.g.) but after all it works and works ...  )

No problem, see my attachement, maybe meanwhile are some formats also natively supported, but I have read, in such cases wins IMatch over user, so no problem.
At least, the formats works here. 

[ubacher]

I also keep only managed files in the folders which Imatch indexes, but.....

By pure coincidence I found that I had files which were left over from some (failed?) exiftool operations which I then
filtered for in explorer and deleted. Now I wonder if there are other stray files?

Because of this I would find an option/script etc useful which would show the number of unmanaged files in
Imatch managed folders. Maybe an option under Database tools?

[Mike]

Thanks for the answer Mario, I followed your tips and also thought about a few file-related things.

I apologize on one point (related to the .mmap files)
I recently started using an older version of MindManager for special reasons. Only now have I noticed that newly created concept maps no longer receive proper thumbnails in the Explorer file browser view. I do see a screenshot, but only in the Explorer preview area. It seems that iMatch cannot make use of the displayed preview. Probably not a big surprise in the situation?

I tested different classes in iMatch (yes, with forced rescan, whenever needed)
a) All support the display of the ".mmap" file.
b) Some of them show the original MindManager icon, others a kind of thumbnail. See attachement.
c) The log shows different messages of different lengths.

Example of used classes:

The "Image" class format uses the original icon. The log shows:
01.08 11:36:29+108687 [3438] 01 W> ETWARN:Error: File not found - C:/USERS/EGO/APPDATA/LOCAL/TEMP/IMT72D93C38-6507-4545-BA6A-ECC89A2EEB37.XMP
'V:\develop\IMatch5\src\IMEngine\PTETWrapper.cpp(2241)'
01.08 11:36:29+ 141 [2D9C] 01 W> PTPIP::LoadThumb failed with Unknown image type. 'V:\develop\IMatch5\src\ptpif\PTPIP.cpp(3099)'
01.08 11:36:29+ 0 [2D9C] 01 W> PTPIP::Load failed with Unknown image type. 'V:\develop\IMatch5\src\ptpif\PTPIP.cpp(2882)'
01.08 11:36:29+ 0 [2D9C] 01 W> Error loading D:\testordner 2\TEST D.mmap with error 1 'Unknown image type.' 'V:\develop\IMatch5\src\ptpicore\PlugIns\ptpipip\PTPIImage.cpp(572)'
01.08 11:36:29+ 0 [2D9C] 01 W> PTPIP::Load failed with Unknown image type. 'V:\develop\IMatch5\src\ptpif\PTPIP.cpp(2882)'
01.08 11:36:29+ 0 [2D9C] 01 W> Failed to load large size, falling back to preview 'V:\develop\IMatch5\src\ptpicore\PlugIns\ptpipip\PTPIImage.cpp(477)'
01.08 11:36:29+ 0 [2D9C] 01 W> PTPIP::LoadThumb failed with Unknown image type. 'V:\develop\IMatch5\src\ptpif\PTPIP.cpp(3099)'
01.08 11:36:29+ 0 [2D9C] 01 W> Error loading D:\testordner 2\TEST D.mmap with error 1 'Unknown image type.' 'V:\develop\IMatch5\src\ptpicore\PlugIns\ptpipip\PTPIImage.cpp(572)'

The "PDF" class format adds a thumbnail. The log shows:
01.08 10:51:04+1665938 [0510] 01 W> ETWARN:Error: File not found - C:/USERS/EGO/APPDATA/LOCAL/TEMP/IMT2A2D1190-A51F-4348-A9C7-B6DA3B6A59F0.XMP
'V:\develop\IMatch5\src\IMEngine\PTETWrapper.cpp(2241)'
01.08 10:51:09+ 5172 [2C7C] 01 W> EUQH: Failed to calculate CRC for file D:\VERWALTUNG\Verwaltung\IT\IT.mmap 'V:\develop\IMatch5\src\IMEngine\IMEngineUpdateQueue.cpp(375)'
01.08 10:51:31+21875 [2CB0] 01 W> ETWARN:Error: File not found - C:/USERS/EGO/APPDATA/LOCAL/TEMP/IMTA32BA47B-3F90-40EF-BE71-D44939CE297D.XMP
'V:\develop\IMatch5\src\IMEngine\PTETWrapper.cpp(2241)'

The "Auxiliary Files" class uses the original icon. The log shows:
01.08 12:25:09+223390 [0CFC] 01 W> ETWARN:Error: File not found - C:/USERS/EGO/APPDATA/LOCAL/TEMP/IMTEFFFE11A-7F83-45E4-8CB6-93901A8EEFCB.XMP
'V:\develop\IMatch5\src\IMEngine\PTETWrapper.cpp(2241)'

The "Office" class format adds a thumbnail. The log shows:
01.08 11:03:29+126312 [0510] 01 W> ETWARN:Error: File not found - C:/USERS/EGO/APPDATA/LOCAL/TEMP/IMTD712A8E4-959F-40D5-9D9D-35722FDA6ACE.XMP
'V:\develop\IMatch5\src\IMEngine\PTETWrapper.cpp(2241)'

The "Multimedia" class format adds a thumbnail. The log shows:
01.08 11:52:12+348781 [2698] 01 W> ETWARN:Error: File not found - C:/USERS/EGO/APPDATA/LOCAL/TEMP/IMTC3A2203C-D20C-4726-8D40-1196D3F7B60A.XMP
'V:\develop\IMatch5\src\IMEngine\PTETWrapper.cpp(2241)'


Does the assumption apply: the shorter the log text, the better in this .mmap case?
At least it looks like it would be better to use the classes that triggered fewer rows ... because iMatch may have had less to do. Is that correct? Do you think based on what you see, that one of the formats makes more sense than others for the .mmap files?


Special support for MindManager .mmap
I thought about it. It would probably help too few iMatch user as you suggested. It is OK, that it is displayed via user-defined formats. There is more useful work to be done than introducing too special formats.

[Mike]

General display of unsupported formats

A potential solution would be to create a global switch for File Formats which is called "Ingest all files found". And then add logic and code to somehow deal with these uncommon file formats and put them into likely groups or a bucket group like Multimedia or maybe "Stuff".

Your thoughts could be a good solution. I think it's important to basically know what exists and what doesn't. No matter how you want to organize yourself. "Stuff" sounds OK.

1. We would always have the full overview and no annoying surprises. (As e.g. with older, special folders or those with unclear content that we receive from project partners, etc.)
2. We could put files together, exactly the way we need them, no matter how common or exotic a project is, or how special our concepts are.
3. It would then be up to us, whether and when exactly we want to take the time to separate file formats from one another.
4. We would act completely freely, without risk or extra controls in Explorer.

BTW.: I was pleased to read that blender formats are supported. I'll have to work with it for a while too. ZBrush will be added later ... we'll see how that works.

[Mario]

The warning about the missing XMP is normal - if there is none yet.
None of the image handles understands this file - which is OK. I don't know if MindMapper installs a shell thumbnail handler.
Please attach a small sample file so I can test it here.

Your thoughts could be a good solution.

Let's see if a substantial number of users is in the need for this kind of change. The amount of work would be massive (aka expensive).

[Mike]

I've attached two files, one very simple and one with a few more details.

The version of MindManager I'll be using again this year is very old. May not be ideally supported by WIN 10.
Win Explorer does not show any real thumbnails either, but the preview.

A year ago I was still using Windows 7 and Adobe. Bridge showed the preview as thumbnails.
I don't use Adobe anymore, so I can't verify that this works in Win 10.

The current version of MindManager also uses the .mmap format. but it is currently not available to me.

PS. Would the contents of the MindManager Shell folder help you understand anything?

[bekesizl]

And another format, what uses a lot of 3D-software, is
obj
quote: OBJ (Wavefront OBJect) is a 3D printer file format that was originally used by graphics designers as a neutral interchange format for 3D graphics. It was first developed by Wavefront Technologies for its animation package. This file format has the extension .obj.
Unlike STL, OBJ can encode colour and texture information, it also supports both approximate and precise encoding of surface geometry. This means that it doesn't restrict its surface mesh to triangular facets. The designer can also use polygons such as quadrilaterals. However, OBJ doesn't support any kind of animation.

OBJ is often used when the 3D object requires more than one colour. It is also the choice of some developers because it offers a lot of flexibility on how it encodes the 3D model's geometry.
Aside from that, with OBJ, the designer can use more advanced schemes such as free-form curves and free-form surfaces. These schemes can be used to encode curved geometry without losing any data.
This file format is also widely used in industries such as aerospace and automotive which are demanding when it comes to precision.

I remember this format from the middle/end of 90's when 3D photorealistic rendering was not as common as today, so it is a rather old format.

[Mike]

I understand your reasoning.

A general Windows Explorer replacement would not be of interest to me either. Windows Explorer is sufficient for the system partition, Windows and programs.

Funny - I am on the complete opposite end and would not own a PC without a Explorer replacement like XYPlorer.  The lack of multi-panes is the single biggest question mark so many decades after 3rd party software introduced it.  Scripting, filtering, highlighting, mousedown/over previews, the list goes on and on... like using a folder structure to manage your photos instead of a dedicated DAM... it functions but only goes so far.

At least our basic needs aren't really that different, we probably just go different ways. At first I also tried to expand the Explorer functionality, much like you do. Over time, I felt the need to bring thinking, acting and management closer together. A manager like Explorer who exists outside of the thinking environment has started to bother me a lot.

a) I use a specialized reference manager for detailed work with large collections of linked scientific literature (annotating, connecting, thinking, writing, managing in one place)

b) I recently started using iMatch to manage visual information (research data or my own photo sessions, art and design). I might also use it for archiving literature titles that don't need to be linked internally. The well-organized keywords in iMatch are also very helpful and important, as I can better synchronize such structures with the reference manager or the codes and categories used in the analysis software.
At the same time, however, iMatch is also an excellent environment for detailed visual research in large amounts of data. Because it presents visual material so well to me, I can use it to accompany research as well as to support creation. (Visual aesthetic as well as analytical thinking combined with the management of data... again many things in one place)

c) Much of the data from the two groups mentioned above (books, image collections, videos, audio) later flows into special software for qualitative analysis, which also uses complex internal databases and interlinked projects. Many of the results from this third group flow into the other two databases and back again, which makes compatible data formats extremely important. (And again: reading, coding, analyzing, developing, writing and managing within the same environment.)

There is hardly any space left for the kind of functionality of Windows Explorer. So it just does very simple things for me, but it's perfectly fine for this job ;-)

Nevertheless, if iMatch saved me even more from looking at Windows Explorer, I would hardly experience anything other than joy

[Mario]

I've attached two files, one very simple and one with a few more details.

I don't see a thumbnail or preview for these files in Windows Explorer.
Which means that MindManager seems to install some sorts of shell thumbnail handler, which I obviously don't have.

That's not uncommon with proprietary file formats.
If the vendor does not provide a shell thumbnail handler or WIC codec, only software explicitly designed to handle the format will be able to show thumbnail or preview of sorts.

Also quite often, shell handlers don't age well (stop working when the software is not updated).

Sometimes they work nicely when you look at a couple of files in Windows Explorer. But when IMatch tries to pull previews for hundreds of files, the shell thumbnail handlers fail or even crash, which then causes Windows to shut-down IMatch (without IMatch being able to produce a DUMP file, which is a good indicator).

I have a few small PDF files (A4 1 page) in my test suite which cause the Adobe PDF shell handler to allocate 3GB of RAM and then crash. Since I've found another PDF library and IMatch no longer uses the Adobe shell handler, these crashes on customer PCs and my PC are gone. Such a solution is not available for most other file formats of course, and IMatch has to rely on the WIC codec or shell thumbnail handler provided by the vendor.

WIC is a very workable concept for application vendors to provide Windows and other applications with at least rudimentary "preview" functionalities. I wonder why not more software vendors support it (including Microsoft, e.g. for their Office products). Money, perhaps. As always.

I cannot afford spending thousands of dollars annually to license 3rd party libraries which support a number of vector formats or other special file formats. Or spend weeks figuring out how to use code posted on Github that is supposed to read format X. Which then often ends it with support X, but only .1 and .2 but not .3 or .4.

IMatch supports RAW formats via WIC or LibRaw. PDF. Many video formats. Libre/Office. Some 3D formats like Blender. And many other mixed formats. Additional formats can be added as user-defined files to manage them.
This should cover 99% of what people need from a photography/video-oriented DAM. Good enough for me.

There are (expensive) document management systems out there which specialize in managing  "text" in all varieties, with all kinds of cool features aimed at text processing, conversion and analysis.
Specialized research databases with superb ways to reference all kinds of external documents and stuff.
Genealogy software.

[Mike]

I've attached two files, one very simple and one with a few more details.

...If the vendor does not provide a shell thumbnail handler or WIC codec, only software explicitly designed to handle the format will be able to show thumbnail or preview of sorts.

... I cannot afford spending thousands of dollars annually to license 3rd party libraries which support a number of vector formats or other special file formats. Or spend weeks figuring out how to use code posted on Github that is supposed to read format X. Which then often ends it with support X, but only .1 and .2 but not .3 or .4.

First of all, thank you for taking the time to investigate the .mmap situation. I can understand your arguments regarding the support of special Files very well. Therefore, I have no expectations, but at best hopes that it can sometimes work. I am aware of the enormous variety of existing aproaches and that there are several reasons, why it is completely impossible to deal with all of them equally. And it is also right to prioritize what helps as many users as possible.

There are (expensive) document management systems out there which specialize in managing  "text" in all varieties, with all kinds of cool features aimed at text processing, conversion and analysis.
Specialized research databases with superb ways to reference all kinds of external documents and stuff. Genealogy software.

Yes, there is very capable scientific research software out there, and also yes, unfortunately expensive, like my analysis software. They are so good because they set priorities, specialize and put all their energy into this development. But that also means, no matter how good they are, they cannot be equally good in all areas. Therefore, you often have to combine several packages, especially if the desired goals are of an interdisciplinary nature or can only be achieved by entering such areas.

Personally, I find iMatch excellent for the part of the job types it focuses on and the way its functionality suits me. It's a great DAM solution and is already helping me impressively well. Of course, I'm just a complete beginner when it comes to iMatch, but my assessment is based on several hundred thousand images that I have already loaded into the database, and which the program handles very well.

For me, managing images doesn't just mean putting them neatly on the shelf for a long time, but above all looking at them again and again almost every day, thinking intensively about them, taking notes and preparing for further processes, either artwork or scientific research. iMatch is a great help with these steps.

[Mike]

Idea: alternative feedback for unmanaged file formats.

If programming the display and management of exotic file formats is too time consuming, what if we were made aware of them in some other way? E.g. by marking the folder. In this sample symbolically represented by an asterisk.

Example 1 (more precise):

a) FOLDER (30 * / 3686) = 30 known and some unmanaged file types exist directly in this folder. Its subfolders only contain known types.
b) FOLDER (40/522 *) ... in this case the unknown file formats are somewhere in the subfolder.

Example 2:

FOLDER (50/4425) * ... Unknown file formats exist somewhere in the folder or subfolder.

We would know right away, that there are files that we are not going to see. This can influence our behavior in a timely and meaningful way. Which symbol we use exactly, or in which way the folders are marked, is another topic.

[sinus]

Idea: alternative feedback for unmanaged file formats.

If programming the display and management of exotic file formats is too time consuming, what if we were made aware of them in some other way? E.g. by marking the folder. In this sample symbolically represented by an asterisk.

Example 1 (more precise):

a) FOLDER (30 * / 3686) = 30 known and some unmanaged file types exist directly in this folder. Its subfolders only contain known types.
b) FOLDER (40/522 *) ... in this case the unknown file formats are somewhere in the subfolder.

Example 2:

FOLDER (50/4425) * ... Unknown file formats exist somewhere in the folder or subfolder.

We would know right away, that there are files that we are not going to see. This can influence our behavior in a timely and meaningful way. Which symbol we use exactly, or in which way the folders are marked, is another topic.

I have no clue, if this is doable.
But it would be, like you wrote, this would be very good for some users.

I tend to manage a lot of files with IMatch, not only images and videos and simple stuff like that, also different files from exotic programs.
At least I can see, that there are other files in a folder instead of empty, if I want delete them, because then IMatch warns with a pop-up, that there are unknown files in it.

For me this would be a kind of more "security-feeling".
But maybe in contrary to me, it is not very important, but I would be glad to see such an enhancement, like you propose or to see in another way, that there are more files in a folder, that I can see.

[thrinn]

My personal opinion:
I use IMatch to manage my digital assets which is not the same as all files. A count of all files in a given folder would be of no interest to me: For example, a folder containing 500 RAW files will most likely contain the same number of XMP files. If I am shooting RAW+JPG, the folder might contain 500 RAW files, 500 JPGs, and 500 XMP files. So the total number of files would be 1500 - but this is no relevant information for me. The number of RAWs and JPGs is relevant, but these are already shown - because the corresponding file types are managed by IMatch.

So for me, the current behaviour (with a warning shown when trying to delete a non-empty folder) is completely sufficient.

[Mike]

A count of all files in a given folder would be of no interest to me

Just to be sure my suggestion wasn't misleading. It is not about the exact number of files that are not managed, but about knowing that they appear in a folder, regardless of whether it is intended or not.


To make it clear:

1. This is the current display of a folder: FOLDER (30/300)
It means 30 files are directly in the folder and 300 more in sub-folders.

2. This is the suggestion: e.g. FOLDER (30* / 300)
That means exactly the same with the difference that you now know that there are also unknown files in the folder.
Wherever there is an asterisk, there are unknown files, i.e. (30* / 300) or (30/300*) or (30* / 300*), depending on if and where such files exist, in the folder, subfolder, in both ...

It would be possible and perhaps also useful to exclude XMP files from this procedure if they are really sidecars and not leftovers. If they do not accompany a file, i.e. are orphans, then we would find out, and that would be a good thing because the orphan state is rather unwanted.

So maybe this would even help people with your file organization to recognize irregularities earlier.

[Tveloso]

Wherever there is an asterisk, there are unknown files, i.e. (30* / 300) or (30/300*) or (30* / 300*), depending on if and where such files exist, in the folder, subfolder, in both ...

Although it might not benefit me personally, I like the idea of being able to see at a glance that a given folder contains files that are not being managed in IMatch. 

For me, it would likely mean that I have made some sort of mistake, and need to clean out the folder, but I can see where it would be useful to others to keep the "foreign files" where they are, and know (by virtue of this indicator in IMatch) that they are there.

And perhaps this "Unmanaged Files Exist" indicator (whatever that might be) can be a clickable element, that will pop up an App Window, to list those files (perhaps just a Windows Explorer Details view type listing?).  This would be "separate" from core IMatch, so the core features could continue to behave as they do today...

--Tony

[Mike]

This is just an addition and not suggested instead of the "ASTERISK"

When we try to delete a folder that contains unmanaged files, iMatch will warn us and give us YES and NO options.
I propose a third option: "Don't delete, show folder in Explorer instead".
In almost all of the cases I've come across, this would have been the most appropriate behavior.