Universal Media Server | Forum

Hi,
I try to get answers to "The problem of the display by renderers of the documents with attaches titles and informations build by scripting from metadata"

The reason : I wish i could get an understandable presentation of the documents (photo, video, records), because after testing a lot of renderers, the best information which can be displayed is the "title" by Kodi (extracted from IPTC "Title" but I have not been successful when testing the function... not solve), the other proposal seems to be use PLEX (following the documentation but not tested ) with offer ways to display metadata (but I could not display dlna documents delivered by UMS with PLEX : obviously the media preparation is done by PLEX server).

The common problem is that the "rendering chain" (form server used by the renderer) used to display the hierarchy and give access to the media seems to be always built from the files names and folders names where the media are physically stored (except the case of "libraries" which provides a head-folder.
More the auto sorting and filtering process of the renderers suppose the unicity of the names of files (of the leaves of the original tree of folders of the documents). Constraint which is not easy to perform (see my example).

What is for you the way to display data on renderer (which one) which could be built from media metadata ?

Best regards,

Trebly
__________________________________________________________________________________________________

Explanation of the problem of the process which generates the physical directories in my case and particular needs that are linked :

My problem is that the Canon photo and video numbering generates duplicate files names (on each support - SDHC card - the auto created folders name are "CANON100" to "CANON900" (note : you can name your folders manually but this must be done when you have the time when you change of subject, and many time you have no time before shooting).
There is no possibility the get a unique name for a media while you don't use the hierarchy of folders as data source for identification (this name into this branch...)
Each photo can be (option) sequentially numbered independently of the support and folders (my option) but only from 1 to 10,000 and after, the counter is reset to 1 (after a forced change of folder), so the unicity is not a guaranty.
To have the unicity of filenames the unique solution is to build after transfer to PC a : unique coded filename to replace the original filename after the first transfer from data source (with a batch treatment which is using the original names - date and number - and the folders hierarchy. This renaming process must have a reverse version to go back to the original name.
Why to do this : simply to have to original media and a backup before any treatment and remain able to compare or restore.

The following treatments are :
- Cleaning images (sometimes exposition errors occurs for a long sequence of images) which must be treated. Others treatment can from a default (I got once a spore sticken suddenly on the mirror Iand I had near 2000 photo to clean. This is done at this step as for exposures problems and basic notation and metadata. The result is to split the previous directories. Generally at this step all photo can be filtered using keywords (metadata IPTC). Each of these subdirectories can be duplicated but with modifications in image format (i.e. dlna compatible, web diffusion etc...), for these photos an "extension" is added to the name to have a significant difference with the name of the original wh.

This process is perfect, combined with "galleries" to prepare the images to send to the renderer.

But the generated names of files are simples codes with no meaning as those of the folders and if you have not a book on your knees with this list of your photos organised by theme you cannot find back them. More you are far from a presentation to a public.

This is studied only for images, for video and for audio there are other processes.

Currently KODI seems to be the alone renderer able to choose to display the "title" to replace the file name (test not successful)
The best should be a script language to build a "description" from exif and iptc data, description accessible by any renderer and produced by the server.

A very heavy process could automatically build a tree of folders and files (leaves of the tree) with significant name.
This process would use the metadata to build directories and names.

But modify an image or add new images become complex and all of this job must be saved...

But this do not solve the question which is to display pleasant panel of informations about the media. Why not html compliant.

Normally VLC has a "display metadata button" but the content is currently appearing empty... ?

I have not found any renderer able to display an "info" panel, user defined, built from EXIF and IPTC data, and something equivalent for video and au

I don't understand everything, but I think you want UPnP AV/DLNA to do something that it can't. There is no support for Exif or IPTC metadata in the protocol, the protocol is pretty limited in which metadata can be given. It's limited to think like name, date, size and maybe a couple of others that I don't remember. This has not been designed with any kind of "professional" or "advanced" use in mind, it has been designed to be as simple as possible to enable different devices from different vendors to work together to transfer media between each other.

UMS can read the metadata, so it would theoretically be possible to let UMS construct a name based on certain rules from the metadata - but I don't quite see how that could be done in any easy way. Implementing a scripting system to generate names sounds like a very complicated arrangement, and I doubt you will find any UPnP AV/DLNA server that does this.

The reason VLC for example doesn't show the metadata when accessed via UPnP AV/DLNA is because these metadata aren't a part of the protocol. When you view a local media file, VLC can extract metadata as it wants to, but when using UPnP AV/DLNA it only has the metadata supplied by the protocol available.

I think I understand what it is you are looking for.

using the example for mp3
if you have your files all mixed together in a directory with unhelpful filenames like Most players can extract the tags like Track number, Title, Artist, Album, Year and display that instead of the file names
but those that can't you are left with this mess. A work around it to rename the files using the tags to something like as Nadahar says there is no support for similar tags in the protocols and most players for images so the workaround is to do the renaming on the PC side, but I don't think that is something UMS could do and probably difficult to automate something in windows explorer.

My suggestion is try Directory Opus, Something I cannot live without. It can be run to replace explorer and can do many things that are too long to list here.
But one of it's features is very powerful renaming tool which is able to take the metadata to make better meaningful filenames and scripts that can automate repetitive tasks It is not free though but has a 60 day trial, but is worth the price if you want to stick with it. It is one of the few pieces of software that have actually made me want to part with my money

Hi,

Please tell me what you don't understand.

I have several sources which clearly declare that uPnP AV, and the independant extension for metadata DLNA, support necessarily the metadata and for the images EXIF and IPTC structures.

The reason is that there are (a different problem is the management of XMP metadata) an integrative part of the formats supported by the protocols.

For this I produce some references into notes.

The consequences, because of the evolution of the normalisation while various format were developed is that the various conversion tools do not support generally the same core of data.
This means that the transmission by the servers to the renderers have not to be particularly specified. This means too that the renderers can or cannot read the whole or some EXIF and IPTC data and can be able or not to display or use these informations.

For video and for audio the data are not the same but the principe is identical.

The servers can or cannot use any of the informations transmitted as integrated part of the format.

I my knowledge the alone way for a server to not transmit the metadata with the format JPG is to treat this part of the format to clear it...

So, for now, I just see that servers and renderers don't care and are not using these data.
A renderer can read these metadata and display what it wishes automatically or depending of user parameters to display only a part of these data or to combine them to produce a document.
The server can check these data and if planned can deliver an image modified (add or replace some metadata) as it is done with a format converter.
An option of KODI is to display the metadata "Title" if it exist to replace the file name.
Consequently the use of metadata depends only of the volunty of the developers.

The metadata are an integrative part of the images and should be displayed or used (as the keywords for filters) by the renderers or servers DLNA compliant.

Best regards

Trebly
______________________________________________________________________________________________________________________________________

Note 1 :
UPnP AV The technology basis of DLNA : http://upnp.org/resources/documents/UPn ... ly2014.pdf
IPTC Photo Metadata Standard 2019.1 : https://www.iptc.org/std/photometadata/ ... toMetadata

Note 2 : The software : XNVIEW allows to view and update the metadata EXIF and IPTC, this usage is transparent for servers and renderers.

Note 3 : Metadata can know be managed separately (as for sub-titles of video) since 1.3 and now at level 1.5 (2019) with the format XMP. The XML-based XMP technology is much more flexible and can deal better with globalisation requirements. In 2012 the core definition of the data model and the XML syntax were defined by ISO as standard 16684-1 [ISO-XMP].

I don't understand 30-40% of your sentences, it's too much to quote. But, I think I get the general idea of what you're saying.

You can download the DLNA guidelines from https://www.dlna.org/ (but it's illegal to "share" this, everybody must register and download directly from them so that they can spam you).

You are in a sense correct that UPnP AV is "open to custom extensions". Anyone can define additional metadata, but that's not really very relevant. Unless there is broad support for said metadata, nobody is going to want to implement it. If UMS introduced new metadata fields, no renderer would understand them. That's why standards are needed when cross-application collaboration is needed.

DLNA builds upon UPnP AV and places a lot of additional constraints on what is and isn't allowed. In addition it defines properties and "rules" that applies. Therefore, things not found in UPnP AV that is specified in DLNA instead, usually have reasonably good support among renderers.

It's simply not viable for any UPnP AV/DLNA server to "make up" new metadata properties unless you are some very dominant player that is sure to make such an impact on the market that others are likely to pick it up.

As for the browsing part I don't think you quite understand how it works. It is true that the metadata is available in the file itself, but to access these, the renderer would first have to download the file. When browsing, the renderer doesn't download all the files, instead it asks the server to list the content of said folder, and the server replies with something called a DIDL document describing the content. The metadata available to the renderer are all found in the DIDL document. That's why only metadata that is specified by either UPnP AV or DLNA is available at browse time.

In addition, the server will often have to transcode the source, if the resource doesn't comply with the specifications or with what the renderer supports. When this happens, the metadata are lost, since a new file is created. I guess you could argue that it would be possible to retain the Exif or XMP metadata when doing the conversion, but that's a huge oversimplification. There are many things that prevent this from happening. First of all, I don't even know of a Java library that let you write such metadata, second there is a myriad of file formats and only a few supports Exif and/or XMP. Even among those that do support it, rules aren't always consistent. Especially bad are all the "raw" formats, the formats invented (and most often not documented) by camera vendors like Canon, Nikon etc. It would be a gigantic task to even try to sanetise these in such a way that you could consistently transfer them to another file format. So, for all intents and purposes, unless somebody has 2000 hours to put into making this, this isn't possible.

UMS already parses Exif metadata, they are used for several things internally. The problem is that there's no (standardized) way to present this information to the renderer.

Hi,

First of all I don't understand why you tell about "an illegal" reproduction of a content. I give the reference of the text and the law and common rules allows short explicit citations, but here I don't use this except in an non significant context at the end off my whole text, but sorry missing the "_" .

The problem of my way to build sentences seems to remain, this problem is extremely difficult because the translations given to French by Google (and others sometimes when I see what seems an error) are perfect and could be publicated directly in a French forum. Without the capability to know what is not understood by the other a better communication cannot be set.
The solution could be simply to use in a separates message the full citation and highlight (italics for example) what you don't understand clearly. Then I will be able to rewrite the same in another way.

I agree 90% of what you are telling, but I don't reach the same conclusions.

I have not immediately the time to comment all your sentences, but I a whole view, I can say this :

• It is not because not all the would have to use the metadata (IPTCI for images) that they must clear off all or be obliged to use nothing of the metadata.
• It is not because any metadata can be used by any user (or any group of users) that everybody have to use them (users of a group of servers and renderers using a specified subset of parameters (into all) defined transparently by the user).
• Nobody cannot be satisfied by the fact that it is currently impossible to display for images any of : "title" (or explicit name), "comments on subject", "localisation", "author", "commentaries of the author" etc... depending of the purpose of the diffusion. Currently you (I) cannot get anything by the renderers. This is the unique problem.
• The problem that I evoque is not the fact that XMP allows to add exotic and specialized metadata but that the IPTC Core schema 1.2 and now 1.5 specifications define already many capabilities which covers probably 99.99% of the needs which cannot be transmitted by anyway.

As for the browsing part I don't think you quite understand how it works. It is true that the metadata is available in the file itself, but to access these, the renderer would first have to download the file. When browsing, the renderer doesn't download all the files, instead it asks the server to list the content of said folder, and the server replies with something called a DIDL document describing the content. The metadata available to the renderer are all found in the DIDL document. That's why only metadata that is specified by either UPnP AV or DLNA is available at browse time.

Perfectly right, there are several separate problems :
1- Integration of metadata (where, from where etc.) of the DIDL document at level of the a folder level n-1
2- Integration of metadata for the Icone of an image, the didl of a summary (icone) of a document (level n) but a didl for a "display summary"
3- Extraction of metadata and building by the renderer for the documents for image rendering with his metadata level n full display defined to the renderer (or to the server) from the current known well filled data for any and various packages of images on a server.

only metadata that is specified by either UPnP AV or DLNA

: which are they and where are they defined ?

For now for example when Kodi displays the summary of an image the "description" is declared not found (because a parameter exist to tell to kodi "display a message if a description is not found", Until now I have not found where Kodi searches this description ( I don't spent a long time to check this). Later or on other displays the same problem have been present.

You told me "you seem not to know..." please tell we where I should find these informations as any user which wishes to get a "title" for his images and videos. A user which wishes a title for the "folders" and read for a full displayed image, a display of the known metadata.

You must admit that the fact of getting images without the capability to view any title else that the file name (which is currently and noshort encoded unique name for identification on a system, not by humans) is impossible a non sense. Also when browsing folders to understand what the user is browsing needs to be a system conceptor which has near him a computer to help him to remember what is the content of what he is showing (with for example the help of an Excel folder containing those informations...).

Another way is to forget Images servers and build videos containing images, videos developed with products like Adobe first or Corel VideoStudio, but add an image or change a comment is something quite different.
Since now because I have no time to do so, just a few exceptions, I do myself the whole operation, choose a folder and call people to view, sequentially in one unique and prepared sequence, only the images of the folder while I provide orally the needed comments. Navigate into the existing folders proposed is admitted as a job for specialists.

I tell of of this to insufflate new thought, new expression of need of user, which seems not to be satisfied at all and which seems nevertheless be at the origin and final purpose of the sNtP AV and DLNA metadata spécifications (1.2 to 1.5).

Thanks,

Best regards

Trebly

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm First of all I don't understand why you tell about "an illegal" reproduction of a content. I give the reference of the text and the law and common rules allows short explicit citations, but here I don't use this except in an non significant context at the end off my whole text, but sorry missing the "_" .

It seems to me like the communications problems go both ways. I've said no such thing, I only tried to explain why I didn't link directly to the standards. You need to download them yourself, but they are available here:

https://openconnectivity.org/upnp-specs ... ources.zip
https://spirespark.com/dlna/guidelines

It now seems that they have made it "even harder" to get the DLNA specs, now you have to actually contact them. You should still be able to get them though.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm The problem of my way to build sentences seems to remain, this problem is extremely difficult because the translations given to French by Google (and others sometimes when I see what seems an error) are perfect and could be publicated directly in a French forum. Without the capability to know what is not understood by the other a better communication cannot be set.
The solution could be simply to use in a separates message the full citation and highlight (italics for example) what you don't understand clearly. Then I will be able to rewrite the same in another way.

It isn't that simple. I'd have to highlight most of the text. I think I get the meaning of many things, but I'm not sure, and the probability of misunderstandings is high. It doesn't surprise me that a Google translate back to French "looks good" in French, because what it seems to me like you're doing is building French sentences using English words. So, when Google replaces the English words with French ones, the end result is probably pretty "normal" French

The problem is to try to discuss something that is somewhat complicated when I'm just 70-80% sure of what you mean in most cases. When you combine many 70-80% "certainties", you end up with a pretty low "total certainty".

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm It is not because not all the would have to use the metadata (IPTCI for images) that they must clear off all or be obliged to use nothing of the metadata.

This I don't understand at all, except that it has to do with metadata.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm [*]It is not because any metadata can be used by any user (or any group of users) that everybody have to use them (users of a group of servers and renderers using a specified subset of parameters (into all) defined transparently by the user).

Here I think you try to say that metadata can exist even if not every renderer use them. I agree. But, it's not really relevant. The problem here is that NO renderer supports them, if UMS were to invent some of its own. It would thus be pointless.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm [*]Nobody cannot be satisfied by the fact that it is currently impossible to display for images any of : "title" (or explicit name), "comments on subject", "localisation", "author", "commentaries of the author" etc... depending of the purpose of the diffusion. Currently you (I) cannot get anything by the renderers. This is the unique problem.

Again I'm not sure, but I think you're arguing that having only the filename available for images isn't enough. You need much more information to be able to navigate the images the way you want to. My answer is that I can understand that, but it's not really relevant as the standards are what they are. You're "barking up the wrong tree", you would have to tell this to the UPnP forum or the DLNA "maintainers".

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm [*]The problem that I evoque is not the fact that XMP allows to add exotic and specialized metadata but that the IPTC Core schema 1.2 and now 1.5 specifications define already many capabilities which covers probably 99.99% of the needs which cannot be transmitted by anyway.[/list]

I really don't understand this, and I'm not familiar with the details of IPTC. If what you're saying is that you don't need all the "exotic" metadata, but only the "core" ones, I understand that buy again. There is nowhere to "put" this information, so it's not relevant.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm 1- Integration of metadata (where, from where etc.) of the DIDL document at level of the a folder level n-1
2- Integration of metadata for the Icone of an image, the didl of a summary (icone) of a document (level n) but a didl for a "display summary"
3- Extraction of metadata and building by the renderer for the documents for image rendering with his metadata level n full display defined to the renderer (or to the server) from the current known well filled data for any and various packages of images on a server.

I get a vague idea of some thoughts you might have around the generation of DIDL documents, but i really don't understand anything more than that. Again, the problem remains the same: It's not a problem to include additional metadata in the DIDL if there was some kind of a standard that defined how to present the data.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm

only metadata that is specified by either UPnP AV or DLNA

: which are they and where are they defined ?

See the links I've given above. There's no "short" answer to this, it all depends on the format etc. You'll have to read the standards to see what the rules are. Generally though, none of the information I think you're interested in is specified. This was never meant for "professional use", it was meant as an easy way to share your photos between your camera and your TV. When browsing the images in your camera, I guess the names and maybe data would be sufficient.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm For now for example when Kodi displays the summary of an image the "description" is declared not found (because a parameter exist to tell to kodi "display a message if a description is not found", Until now I have not found where Kodi searches this description ( I don't spent a long time to check this). Later or on other displays the same problem have been present.

I really don't know what you're referring to with Kodi. All I know is that their UPnP implementation is very "basic", it seems to me like they mostly ignore DLNA and only stick to the very core UPnP AV functionality. That said, I haven't read the Kodi source code, this is only my impression from using it.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm You told me "you seem not to know..." please tell we where I should find these informations as any user which wishes to get a "title" for his images and videos. A user which wishes a title for the "folders" and read for a full displayed image, a display of the known metadata.

I don't understand at all.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm You must admit that the fact of getting images without the capability to view any title else that the file name (which is currently and noshort encoded unique name for identification on a system, not by humans) is impossible a non sense. Also when browsing folders to understand what the user is browsing needs to be a system conceptor which has near him a computer to help him to remember what is the content of what he is showing (with for example the help of an Excel folder containing those informations...).

Again pretty unclear to me, but it seems like you're yet again arguing why it would be helpful to have more metadata available. I completely understand that, I'm not the one who decided what should and shouldn't be in the standards.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm Another way is to forget Images servers and build videos containing images, videos developed with products like Adobe first or Corel VideoStudio, but add an image or change a comment is something quite different.
Since now because I have no time to do so, just a few exceptions, I do myself the whole operation, choose a folder and call people to view, sequentially in one unique and prepared sequence, only the images of the folder while I provide orally the needed comments. Navigate into the existing folders proposed is admitted as a job for specialists.

Don't understand any.

Trebly wrote: ↑Wed Jun 17, 2020 12:11 pm I tell of of this to insufflate new thought, new expression of need of user, which seems not to be satisfied at all and which seems nevertheless be at the origin and final purpose of the sNtP AV and DLNA metadata spécifications (1.2 to 1.5).

Not sure what you mean, but if you're asking me how to influence the standards, I have no idea. I think it's pretty much impossible unless you're a big commercial company.

I don't know if you know how all this works, but the "committees" that makes these specifications generally consists of huge commercial players, primarily device manufacturers. DLNA was founded by Intel with support from Sony and Microsoft, although Microsoft later withdrew as far as i know. There's nothing much you or I can do to influence their choices, they only make choices they think can benefit themselves and the sale of their products.

On top of this, both UPnP and DLNA have now been discontinued. Private companies have been formed that now "owns" the standards, and which makes money by charging companies a lot of money to "certify" their devices with the standards so that they are allowed to marked them as supporting the standards.

Unless you're ready to start a collaborative effort between all the major open-source projects involved, I think the chances to making any changes to the standards are nil. Even if such a broad open-source collaboration materialized and additional properties was defined, I doubt it would get picked up by the commercial manufacturers that actually supply the TV's, game consoles, set-top boxes or other devices that is used as renderers.

Hi,

With your post, I think that there is the basis to build an answer to all my questions, even if my way to write in english is not always understandable.
I know what you could not understand but for my own I am sure to have understood everything of your thoughts.
I agree fully with your point of view, but I think that it can exist a way of life for opensource.

This could be a main one of next subjects, I believe.

Before I will answer to your message using a numbering and clear separation of the different subjects.
Each block will contain the quoted (two levels) of your text followed be the explanation (clear I hope) of what I told previously (badly) and my comments.
I will too join some attachments or introduce links to explained videos, much more clear than a text (a sample is kodi).

I am quite sure that this will be the last loop before splitting some generated subjects or conclude and close others ones.

For now, I am sorry, I have a main family problem and I cannot answer inside next eight days.

Thanks,
Best regards

Trebly

Hi,

This has been much more. I am back.

I mainly give you here the "translation" of what I mean. I answer to each of your previous citations and remarks separated by a line to be more easily to read and sometimes complements of conclusions or proposals.
_______________________________________________________________________________________________________________
-1-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

First of all I don't understand why you tell about "an illegal" reproduction of a content. I give the reference of the text and the law and common rules allows short explicit citations, but here I don't use this except in an non significant context at the end off my whole text, but sorry missing the "_" .

It seems to me like the communications problems go both ways. I've said no such thing, I only tried to explain why I didn't link directly to the standards. You need to download them yourself, but they are available here:

I little complex misunderstood : come from confusion between the references of documents that can be read (and downloaded) on the site dlna.org and their contents. This while I was thinking to both IPTC and DLNA
A title and a link, I had this in my mind...
_______________________________________________________________________________________________________________
-2-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

The problem of my way to build sentences seems to remain, this problem is extremely difficult because the translations given to French by Google (and others sometimes when I see what seems an error) are perfect and could be publicated directly in a French forum. Without the capability to know what is not understood by the other a better communication cannot be set.
The solution could be simply to use in a separates message the full citation and highlight (italics for example) what you don't understand clearly. Then I will be able to rewrite the same in another way.

It isn't that simple. I'd have to highlight most of the text. I think I get the meaning of many things, but I'm not sure, and the probability of misunderstandings is high. It doesn't surprise me that a Google translate back to French "looks good" in French, because what it seems to me like you're doing is building French sentences using English words. So, when Google replaces the English words with French ones, the end result is probably pretty "normal" French

The problem is to try to discuss something that is somewhat complicated when I'm just 70-80% sure of what you mean in most cases. When you combine many 70-80% "certainties", you end up with a pretty low "total certainty".

You are right, but as I read currently English documents and book and have discussions since long years, I am not sure to build French sentences nor translate word by word. I directly build the sentence in my mind in English and sometimes I translate to French and tell me "this is not exactly what I mean" then I ty various translator from French to English to find what is wrong. I think that I write in a very literary language (using French structures) but versus sometimes when I read English literature or Press I am sometimes lost a while by very English structures.
I don't feel and see many differences between what I read or listen (understanding without any translation) and what I tell or write. This is the problem.

___________________________________________________________________________________________________________________________________
-3-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

It is not because not all the would have to use the metadata (IPTCI for images) that they must clear off all or be obliged to use nothing of the metadata.
This I don't understand at all, except that it has to do with metadata.

You cannot understand. Sorry, this has no more meaning for me... words missing or miss written and quite full sentence missing also (cut-past ?) (. A rare exception where I have not checked my text with a translator (English to French).
The right full sentence is :
" It is not because the whole world would have not to use all of the metadata structure (IPTCI for images) that they (dlna and equipments and software builders) must or will clear all off and implement to use only XMP with more only new models. Even they would want they could not. The core of IPTC (currently 2019.1) will remain as it is currently included into XMP, this even XMP allows a lot of new features with new models. This new features and associated data which will be developed by DLNA (Spirespark) and not usable by "the others".

Added : My current conclusion about this : There is no reason that open Servers and renderers should not be able to transmit and analyse the content of IPTC and XMP with user parameters (i.e. list of metadata used and that are to be taken in account for a defined renderer, by default all of a model or a subset).
____________________________________________________________________________________________________________________________
-4-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

[*]It is not because any metadata can be used by any user (or any group of users) that everybody have to use them (users of a group of servers and renderers using a specified subset of parameters (into all) defined transparently by the user).

Here I think you try to say that metadata can exist even if not every renderer use them. I agree. But, it's not really relevant. The problem here is that NO renderer supports them, if UMS were to invent some of its own. It would thus be pointless.

It is what I mean and consequences.
You tell :

The problem here is that NO renderer supports them

, I am not sure of this.

• VLC has an IPTC metadata viewer but I have not found the fit space between IPTC model and VLC metadata that can be displayed. I have not found quickly the way (quite sure that it exists) to define what to show. I have not not begin the necessary inquiry, until now.
• KODI on summaries of images found (search DLNA servers and finds well UMS) has a place to display metadata and more an option to tell to who is viewing the summary if data are "missing - not found" or leave the space empty.
• There are VLC and KODI a zone at top of images (and video) a space which can show others metadata. No information how to use or if they are usable.
• It seems that on the old smartHub of my TV and the FreeBox Media data which are displayed (for example IPTC "title" replaced by default by file name).

Then I think that it is the problem of a "user" who want to enhance his display of media to use the capabilities of his renderer (Coherent definition set by user by filling IPTC metadata for his media, configuration of the server and of the renderer)

It is not in my mind that UMS could have to invent any, only, may be, fill some existing in the IPTC model to tell (even not used) this images had been configured by UMS (as defined by conf file).
One question could be : As icons are sent as images to produce the summaries of the images of a folder a part of the iptc of the main image (particularly the title) could be duplicated with (stored into) the generated icon image, is-it something foolish to let the renderer able to produce a list of the images of a folder with the titles displayed next to the reduced images ? This can be an action of an Upnp server if the renderer is able to do this (which can be a standard of the capabilities of renderers which is the lonely solution). Nota : currently KODI displays the list of images on the right and the left contains the icon and under a zone of "content" but I ignore if it exists any correspondence between this content and IPTC metadata or where KODI is seeking this content. So, something is done, or planned in Open world.
____________________________________________________________________________________________________________________________
-5-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

[*]Nobody cannot be satisfied by the fact that it is currently impossible to display for images any of : "title" (or explicit name), "comments on subject", "localisation", "author", "commentaries of the author" etc... depending of the purpose of the diffusion. Currently you (I) cannot get anything by the renderers. This is the unique problem.

Again I'm not sure, but I think you're arguing that having only the filename available for images isn't enough. You need much more information to be able to navigate the images the way you want to. My answer is that I can understand that, but it's not really relevant as the standards are what they are. You're "barking up the wrong tree", you would have to tell this to the UPnP forum or the DLNA "maintainers".

Yes, this is the meaning, except that I don't tell here about the purposes and the use of metadata.
I just tell (not fully explicitly), standards EXIF and IPTC for metadata have been built during twenty year to give informations to renderers with three main purposes :

• Organize the media, with tools used be the libraries author
• Display these informations to who is viewing the media
• Filter the media to display using various criteria built on metadata and build libraries

More extended comment : Currently I don't know how to get the metadata (some ones may be) displayed or used as filter else than for building libraries (catalogs).
Some renderers does something or seem to have wish todo.
The case of VLC is that there is a panel to display metadata into "tools" on right-click on an image, but the content is empty and there is no documentation at all.
For KODI there is more documentation but I have not found the required, I must send a message.

It is sure that I must go in these questions with the others involved actors of the process.

For UMS the basic question was : does UMS changes anything of the EXIF and IPTC data of images (note that I have to look at the video and sound records also) ?
After, the question is why renderers don't take in account simply the most common IPTC data like "the title" to display (even a title is defined in IPTC and EXIF VLC displays the filename with label "title").

One consequence of the fact that the "title" of an image cannot be displayed under the image by renderers but most of time a field named "title" containing the filename is that someones have developed software to rename the files with a title built from metadata extracted from EXIF and IPTC !!! (the problem is that this operation is not reversible for mental and you cannot get the filename back if you have not created a reverse conversion table, a no-solution for libraries management).
I think that sometimes technology development leads to stupid situations (why by simple if we can find very complicated solution : the advantage : create occupation).

I agree about the fact that the center of the subject concerns more renderers than servers, but not entirely on renderers because they are both involved because of the needed continuity of solutions. Authors (concept and development) of servers and renderers should collaborate (the case of the reencoded images for example) even the center of the work is nearer from the developers of renderers, no solution without concertation with the developers of servers. The question is "where", it is not pure DLNA or UpNp it is "metadata creation, transmission and rendering".

I am going to begin with this last subject to build questions to VLC and KODI (may be you can suggest others open renderers). I have found on their forum and wiki several question on this subject.
The reality is not so black. In fact everything looks like, while a standard is existing since long years (for EXIF, IPTC and XMP) the development of renderers has not taken in account the minimum elements. Renderers developers seems to have taken in account the need of displaying titles and comments of images, author (fields placed info display panels for example, because it is stupid to display a image without a title) etc. but this regardless to standards and have not developed the connector. The fields remaining empty.
This lead that VLC fill a field names "title" with the filename. This could be the default if the title is not defined into EXIF and/or IPTC-XMP metadata.
For KODI it is more developed. The displays are based on XML which uses the media object (current pointed into a list or current viewed) and metadata libel1 and libel2 can be displayed (seen in xml description of display). For now I I had no time to go to the code to know how these data are filled and from where, if they are. All of this comes from the same needs, developers have planed a display but the connection with the data which can be easily filled into the source media objects (using xnView for example) has not be done but it is ready (may be in Kodi just some lines of code are missing : using the existing library to extract the right metadata from the object and then fill the corresponding data items). Nevertheless the wiki of KODI is well done (but not very active) and could be considered as on the way of the level of the Codex or Wordpress. Note that the XML pages used for rendering can be easily adapted.
__________________________________________________________________________________________________________________________________
-6-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

The problem that I evoque is not the fact that XMR allows to add exotic and specialized metadata but that the IPTC Core schema 1.2 and now 1.5 specifications define already many capabilities which covers probably 99.99% of the needs which cannot be transmitted by anyway.[

I really don't understand this, and I'm not familiar with the details of IPTC. If what you're saying is that you don't need all the "exotic" metadata, but only the "core" ones, I understand that buy again. There is nowhere to "put" this information, so it's not relevant.

Ok, we are alright for the basis.
The first and most important thing is that the metadata of all type are currently weared by the media objects. If the user has added (filled) the metadata they are transmitted with the object (I say the user, I should say the user who have to fill data as description, author and title etc., while a lot of metadata are filled by the equipment used to get the media, everything is ready to use it. The user can use a lot of products to manage media (for images particularly products as xnView), but in fact each hardware producer - media production - Canon, Nikon, Sony, Olympus, Panasonic & co have defined their own exif metadata, IPTC metadata and now finally the EXF - XML - "exotic" metadata, used by their own tools that they propose to manage technically the media (mainly for professionals) but there is a common core containing the same data for "titles, descriptions and technic ref as GPS data etc... KODI offers the show on a map where the images have been generated if GPS data have been filled... but unable to display the title of the image...). All of this can be found here : https://www.exiv2.org/metadata.html and https://www.exiv2.org/tags.html and https://iptc.org/standards/photo-metada ... -standard/ and XML the extension of IPTC the XMP record. This for images but we can found same standards (with a same core) for video and sound (not so developed).
All users can use the metadata to create for the documentation of libraries, and create the content of libraries by filtering these data that are included into the object.
For development of software built to manage these data, store, extract there are soft-libraries which makes the job easy (I have some references).

The current problem is that all these data cannot be used (are not) into display of lists of media and the "info" about a media by the renderers. the chain is not completed. Some bridges have to be developed for the user becoming able to define the display of these (his chosen) metadata. Really for example, define is own zone to display metadata by the render. The reason of the feasibility is that tools to define, build XML/HTML code to display an information zone and at the other end of the chain to display the content for a particular item, these tools are existing and it is easy to implement... Inserting the "scripting" into XMP data and the renderer displays the content, this need only a name for the field, name used by everybody.

Note that for servers, the lonely problem is with the EXIF data when there is a transcode. The module which writes the exif data used by the renderer must write both the new image parameters and too the full remaining (not changed) metadata blocks.
____________________________________________________________________________________________________________________________________________
-7-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am
1- Integration of metadata (where, from where etc.) of the DIDL document at level of the a folder level n-1
2- Integration of metadata for the Icone of an image, the didl of a summary (icone) of a document (level n) but a didl for a "display summary"
3- Extraction of metadata and building by the renderer for the documents for image rendering with his metadata level n full display defined to the renderer (or to the server) from the current known well filled data for any and various packages of images on a server.

I get a vague idea of some thoughts you might have around the generation of DIDL documents, but i really don't understand anything more than that. Again, the problem remains the same: It's not a problem to include additional metadata in the DIDL if there was some kind of a standard that defined how to present the data.

Sorry when I read now what I wrote everything is not immediately clear for me (because separated of the context).
It seems that renderers (sample of KODI) have already dealt with this by requesting only the metadata from the server to build lists. I will follow separately this subject when I would have read the KODI and VLC wiki about this subject.
Conclusion : it seems that the job is already fully done by renderers. It just remains to verify what currently UMS answers to KODI (or VLC or others). I think that UMS trace will give me informations.
You tell

It's not a problem to include additional metadata in the DIDL if there was some kind of a standard that defined how to present the data

I don't understand, the data blocks for EXIF, IPTC and XMP are in my knowledge perfectly defined and there are libraries to manipulate these data when needed. http://www.exiv2.org et http://libiptcdata.sourceforge.net the https://sourceforge.net/projects/exiftool/ for Php env http://github.com/dchesterton/image a "TOP 25 Exif (and IPTC-XMP) Open source projects : http://awesomeopensource.com/projects
_________________________________________________________________________________________________________________________________
-8-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am
only metadata that is specified by either UPnP AV or DLNA
: which are they and where are they def ... ufficient.

I have been too fast (for one time).
The metadata have professional application but we must separate "professional tools for media jobs" built often by media acquiring equipments, from the "professional software for media exchange, distribution, rendering and manipulation".
I was thinking that the standards for UpNp and DLNA would define a metadata core "included by authors (media builders)" should be able to be rendered using a metadata canal protected by UpNp and DLNA. The evolution of these standards, that I was ignoring until you tell me about, let me change my point of view.
The EXIF-IPTC_XMP must be considered as a black box transported by the media canals (DLNA). At one extremity the author defining the metadata (except the core which describe technically the content : classically : file definition, extension, container, encryption, size etc. but too know the rights on media, all metadata which are used by the transmission systems) to the renders at the other extremity.
For all the metadata which are not of the precedent package the transmission must be seamlessness and assure the continuity : anything in mediasource, anything found back at the end of the tube.
My recent thought is that when this transparency makes these data independent of UpNp DLNA. There are 3 steps :

• - metadata creation
• - definition of way to render (not existing, may be I could write a prototype in php - javascript env)
• - metadata transmission by servers when there is a transcoding
• - metadata reception by the renderer (extraction to get the data structure - existing tools)
• - rendering using the "definition of way to render"

nota : I currently uses something very near in a site development (a plugin for wordpress that I manages) : a script defines a "zone" to render containing data (metadata) and the renderer displays the content (in my application the script allows to write html which is displayed into a box)
________________________________________________________________________________________________________________________________
-9-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am
For now for example when Kodi displays the summary of an image the "description" is declared not found (because a parameter exist to tell to kodi "display a message if a description is not found", Until now I have not found where Kodi searches this description ( I don't spent a long time to check this). Later or on other displays the same problem have been present.
I really don't know what you're referring to with Kodi. All I know is that their UPnP implementation is very "basic", it seems to me like they mostly ignore DLNA and only stick to the very core UPnP AV functionality. That said, I haven't read the Kodi source code, this is only my impression from using it.

With KODI :
- go to network and UpNp : you will find you UMS server (noted DLNA compatible)
- then Kodi offers (quite like VLC but more refined) :
- various selection of media and sorting
- display of list of media (list of images for example) with a
- right zone containing the list (currently the file name, but can surely contain the exif or iptc title)
- left zone displaying data about the pointed item into the list (this zone is described by an XML file and can contain various data -data items Kodi named - which can come from metadata, this quite surely I must investigate this to find if and where metadata are extracted.

I have to ask some question in forum, participate to the wiki (sent the request to get the right to write on the wiki), read code.
_________________________________________________________________________________________________________________
-10-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

You told me "you seem not to know..." please tell we where I should find these informations as any user which wishes to get a "title" for his images and videos. A user which wishes a title for the "folders" and read for a full displayed image, a display of the known metadata.

I don't understand at all.

Ok this is "charabia", I translate :
- your message on Mon Jun 15, 2020 9:02 pm explains a lot of important things combining common informations and your informations and today I would have to rewrite my answer. I would know at this time where to find complementary documents about these subjects. Since this time I found quite all to get another view of your answer.
- at the end I way just saying :
"It is natural that a user should be able to transmit by the mean of the server and the renderer simply the title that he has given to his media, and currently it cannot. This title should be able to be displayed for the list of items and on the main display of the media (the full page image)."
If he is not, something is really going wrong.
I already note that the current XML description of KODI can display this (and more) but they seem not to be connected to the metadata of the item (you give an explanation of this and I must read the code to understand where is the "locking" point : UpNp protocol not able to send metadata of the item while full item content is not transmitted you seems to tell me - a discussion into the wiki of KODI is treating this point I must go farther).
_____________________________________________________________________________________________________________________________________________________
-11-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

You must admit that the fact of getting images without the capability to view any title else that the file name (which is currently and noshort encoded unique name for identification on a system, not by humans) is impossible a non sense. Also when browsing folders to understand what the user is browsing needs to be a system conceptor which has near him a computer to help him to remember what is the content of what he is showing (with for example the help of an Excel folder containing those informations...).

Again pretty unclear to me, but it seems like you're yet again arguing why it would be helpful to have more metadata available. I completely understand that, I'm not the one who decided what should and shouldn't be in the standards.

Ok, my default in French too : too long sentence. I clarify.
" You must admit that the fact of getting images without the capability to view any title is impossible (not acceptable) and is a non sense.
The lonely information is the filename but because of the needs a the files management it is generally a simple encoded number for the use of the system.
When, on renderers, somebody who is browsing the lists of media cannot access to the meaning of such list of numbers. It should be a system engineer able to read these lists, myself author and manager I am unable to understand the browsers and I cannot access my media (200,000 to 300,000 into 20,00 folders told picasa). I was telling that the lonely way to understand what is render is for the engineer to have near him a computer with the conversion tables from "system numbering" to "human understandable titles and labels"
I add that : this is the job not done by the current systems of servers and renderers for private and most of companies, only done by public media distribution for video (NetFlix), Spotify & co for sound, and (curiously) by the media tools of the social networks. For Clouds "Google photo" as a command "add a description".
_______________________________________________________________________________________________________________________________
-12-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am

Another way is to forget Images servers and build videos containing images, videos developed with products like Adobe first or Corel VideoStudio, but add an image or change a comment is something quite different.
Since now because I have no time to do so, just a few exceptions, I do myself the whole operation, choose a folder and call people to view, sequentially in one unique and prepared sequence, only the images of the folder while I provide orally the needed comments. Navigate into the existing folders proposed is admitted as a job for specialists.

Don't understand any.

Sorry again not clear at all red one month later. As for many of these cases I had built a mental image of what I was telling but I have written only keywords, but when I read I perceive the whole sentence. I was meaning :
If we (users) must forget servers and renderers, it remains just one solution.
We can use video tools (like Adobe I, Corel videostudio) and mount a video from images. Then it is easy to add comments by text or voice etc... while picking the photo into our local libraries. Then the result is something that a human can view. In this the job is not at all the same and add or change a description of a photo need several hours of computer. With video it is one lonely view of the author there no navigation capabilities etc.
For some exceptions I have built video and record my voice comments of the photos.
Sometime I prepare a folder of images and when I am ready, I ask to people to whom I want to show the photos to come and I show sequentially the photo with full manual control. I tell comments.
I have no possibility to let anybody use the navigation tools of the renderers that I have tested The navigation tools are into a company or a family for the use of specialists.
____________________________________________________________________________________________________________________________________
-13-

Trebly wrote: ↑Wed Jun 17, 2020 2:11 am
I tell of of this to insufflate new thought, new expression of need of user, which seems not to be satisfied at all and which seems nevertheless be at the origin and final purpose of the sNtP AV and DLNA metadata spécifications (1.2 to 1.5).

Not sure what you mean, but if you're asking me how to influence the standards, I have no idea. I think it's pretty much impossible unless you're a big commercial company.

Again I have been not clear, may be very tired and wishing to send my answer...
I was not necessarily telling about standards. I was supposing that to have good tools to display media in private circle or for internal needs of small and medium companies, could be a general purpose. You have explained to me, clearly that this is wrong and how is the evolution of the organisation of standards and development.

_________________________________________________________________________________
You have concluded :

Unless you're ready to start a collaborative effort between all the major open-source projects involved, I think the chances to making any changes to the standards are nil. Even if such a broad open-source collaboration materialized and additional properties was defined, I doubt it would get picked up by the commercial manufacturers that actually supply the TV's, game consoles, set-top boxes or other devices that is used as renderers.

I think that surely a collaborative effort between all the major open-source projects involved is the lonely solution. But this can be independant of standards because what is needed already exists and will not be changed.

I will work on the current behavior of uPnP AV and DLNA regardless the transmission of the metadata, and the functions of the libraries.
I am not sure but it seems to me currently that there is a solution with a metadata "tunnel" using XMP transmitting a blackbox of metadata.
Then everything depends of

• the media creation with his metadata
• the definition by the author of the content of an area of the renderer (defined as XMP metadata) A new open tool.
• the renderer able to treat the content of the area using the description of the content. An element of library

In fact encapsulate at media generation with XMP into a metadata :
- a copy of involved metadata
- the description of rendering XML/HTML script (using same structure as the "shortcodes" of wordpress if you know)
A renderer module (part of a library) able to display into an area the defined content.

This could be an open project, a complement of the IPTC library for example. Then if the development of the renderer uses the library the functions capability is assured.

Again thanks for your long and elaborated answer.

Best regards

Trebly

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am Hi,

This has been much more. I am back.

Answering these are becoming more like writing a book than making a comment

I'll try to answer the things I think I understand to the best of my ability.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am "It is not because the whole world would have not to use all of the metadata structure (IPTCI for images) that they (dlna and equipments and software builders) must or will clear all off and implement to use only XMP with more only new models. Even they would want they could not. The core of IPTC (currently 2019.1) will remain as it is currently included into XMP, this even XMP allows a lot of new features with new models. This new features and associated data which will be developed by DLNA (Spirespark) and not usable by "the others".

Added : My current conclusion about this : There is no reason that open Servers and renderers should not be able to transmit and analyse the content of IPTC and XMP with user parameters (i.e. list of metadata used and that are to be taken in account for a defined renderer, by default all of a model or a subset).

I still don't understand. As far as I know, there is no way to embed XMP, IPTC or any other structures in the DIDL-Lite documents defined by UPnP AV and DLNA, neither a subset of or complete. I think this is the core of the problem that I'm trying to communicate, but that seems to get lost on the way. I understand that a server could simply "dump" any XML data inside the DIDL-Lite structure, but it wouldn't meant that it was useful. You would need renderers to be implemented to read these structures, and I really, really doubt anybody would bother doing this unless there was some kind of broad support. Making these things usually isn't trivial at all, it requires many hours of work and testing. But, what is worrying me the most, isn't that most renderers couldn't read it, but the fact that most renderers don't expect it and would therefore fail when parsing and reject the resource as invalid. Another big problem is that the specification has a very low max-size (in number of characters) a DIDL-Lite structure can contain. I don't remember the limit, but it is very low - in fact so low that I don't think many implementations respect it (512 characters or something like that). This is because UPnP/DLNA is supposed to work on quite "simple" devices with limited resources, so the buffers required by the standard is very small. So, even if a renderer ignored what it didn't understand, many would probably fail simply because it wouldn't fit in their processing buffer.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am It is what I mean and consequences.
You tell :

The problem here is that NO renderer supports them

, I am not sure of this.

• VLC has an IPTC metadata viewer but I have not found the fit space between IPTC model and VLC metadata that can be displayed. I have not found quickly the way (quite sure that it exists) to define what to show. I have not not begin the necessary inquiry, until now.
• KODI on summaries of images found (search DLNA servers and finds well UMS) has a place to display metadata and more an option to tell to who is viewing the summary if data are "missing - not found" or leave the space empty.
• There are VLC and KODI a zone at top of images (and video) a space which can show others metadata. No information how to use or if they are usable.
• It seems that on the old smartHub of my TV and the FreeBox Media data which are displayed (for example IPTC "title" replaced by default by file name).

Then I think that it is the problem of a "user" who want to enhance his display of media to use the capabilities of his renderer (Coherent definition set by user by filling IPTC metadata for his media, configuration of the server and of the renderer)

I'm quite sure that no renderer does this. I think you're conflating two different things. I understand that many players can show these metadata, and have space reserved for this in their GUI or otherwise indicate a capability of showing them. I am convinced that the reason for this, is that these players can utilize different sources, including filesystem access to the source media. When reading a media from a filesystem, these metadata can easily be read, parsed and presented by the player. This is NOT the case when using UPnP AV, since there is no defined way to transfer the information. So, even though you see locations meant to the information you're after, you will never see these populated when using UPnP AV as a source, except of course for the very basic metadata defined by UPnP AV or DLNA.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am It is not in my mind that UMS could have to invent any, only, may be, fill some existing in the IPTC model to tell (even not used) this images had been configured by UMS (as defined by conf file).
One question could be : As icons are sent as images to produce the summaries of the images of a folder a part of the iptc of the main image (particularly the title) could be duplicated with (stored into) the generated icon image, is-it something foolish to let the renderer able to produce a list of the images of a folder with the titles displayed next to the reduced images ? This can be an action of an Upnp server if the renderer is able to do this (which can be a standard of the capabilities of renderers which is the lonely solution). Nota : currently KODI displays the list of images on the right and the left contains the icon and under a zone of "content" but I ignore if it exists any correspondence between this content and IPTC metadata or where KODI is seeking this content. So, something is done, or planned in Open world.

I don't quite understand the first part, but when it comes to putting some of the metadata in the thumbnail as a text overlay, that would be possible. It would make thumbnail generation even slower, but the main problem would be that most renderers display so small thumbnails that I doubt it would be readable.

One thing I'd like to mention, that I just realized now that you might have been trying to say for a long time, is that it would of course be possible to replace the "title" in the DIDL-Lite with a title extracted from Exif, XMP or other metadata instead of using the filename. The problem is that it's only one "title", so you would either have to concatenate them both into a combined string, or not specify the filename at all. While this might be good for you, I'm not so sure that it would for everybody. I think that the number of people that actually edit the metadata in their images is relatively limited, so you could risk that there were lots of images with the same "standard" title for example. It could of course be a configuration option whether UMS should use title from metadata or filename. For audio with embedded tags like ID3, this is already done so that the title from the tag is used instead of the filename. But then again, it's much more common for people to actually edit the tags.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am Yes, this is the meaning, except that I don't tell here about the purposes and the use of metadata.
I just tell (not fully explicitly), standards EXIF and IPTC for metadata have been built during twenty year to give informations to renderers with three main purposes :

• Organize the media, with tools used be the libraries author
• Display these informations to who is viewing the media
• Filter the media to display using various criteria built on metadata and build libraries

More extended comment : Currently I don't know how to get the metadata (some ones may be) displayed or used as filter else than for building libraries (catalogs).
Some renderers does something or seem to have wish todo.
The case of VLC is that there is a panel to display metadata into "tools" on right-click on an image, but the content is empty and there is no documentation at all.
For KODI there is more documentation but I have not found the required, I must send a message.

Again, you don't need to convince me of all the reason why you'd want the metadata available in the renderer. That part I understand, the problem is that I don't think there's anyway to actually transfer the information from the server to the renderer.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am For UMS the basic question was : does UMS changes anything of the EXIF and IPTC data of images (note that I have to look at the video and sound records also) ?
After, the question is why renderers don't take in account simply the most common IPTC data like "the title" to display (even a title is defined in IPTC and EXIF VLC displays the filename with label "title").

UMS doesn't alter the files in any way if the renderer can read accept them as they are. If they must be transcoded/converted because the renderer doesn't support the image, all metadata are lost since UMS then actually reads the image raster data into memory and then creates a new image in the new format. This generated image will have no metadata. It is not possible, or at least practical, to "transfer" metadata when converting images. That would require some very advanced processing, as the rules for how to store metadata is so different for different formats.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am One consequence of the fact that the "title" of an image cannot be displayed under the image by renderers but most of time a field named "title" containing the filename is that someones have developed software to rename the files with a title built from metadata extracted from EXIF and IPTC !!! (the problem is that this operation is not reversible for mental and you cannot get the filename back if you have not created a reverse conversion table, a no-solution for libraries management).
I think that sometimes technology development leads to stupid situations (why by simple if we can find very complicated solution : the advantage : create occupation).

As I mentioned above, the title would be possible to use instead of the filename, but you can't get both.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am I agree about the fact that the center of the subject concerns more renderers than servers, but not entirely on renderers because they are both involved because of the needed continuity of solutions. Authors (concept and development) of servers and renderers should collaborate (the case of the reencoded images for example) even the center of the work is nearer from the developers of renderers, no solution without concertation with the developers of servers. The question is "where", it is not pure DLNA or UpNp it is "metadata creation, transmission and rendering".

I don't think such metadata would have any relevant connection to DLNA. It is possible to create "UPnP extensions", UPnP is built to be extendable, and the most realistic way of achieving the transfer of metadata would be that somebody made a specification for a metadata extension, and then somehow convinced both server and renderer implementations to implement the extension. I think it would be very difficult to achieve in reality though. UPnP AV and DLNA both seem to be "half dead" standards, nothing new of relevant has happened for years, and both working groups have been dismantled. That doesn't mean that an extension couldn't be made, but I don't think the interest in UPnP AV/DLNA is very high on the list of priorities with many of the involved parties. These days it seems to revolve more about streaming online media, and local media seems to be "how they did it in the old days". In addition to that, images have always been a kind of "afterthought" also for UPnP AV/DLNA. The primary focus is on video, then audio, and then finally, if everybody didn't fall asleep already, somebody did a little something on images. Sadly.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am I am going to begin with this last subject to build questions to VLC and KODI (may be you can suggest others open renderers). I have found on their forum and wiki several question on this subject.
The reality is not so black. In fact everything looks like, while a standard is existing since long years (for EXIF, IPTC and XMP) the development of renderers has not taken in account the minimum elements. Renderers developers seems to have taken in account the need of displaying titles and comments of images, author (fields placed info display panels for example, because it is stupid to display a image without a title) etc. but this regardless to standards and have not developed the connector. The fields remaining empty.
This lead that VLC fill a field names "title" with the filename. This could be the default if the title is not defined into EXIF and/or IPTC-XMP metadata.
For KODI it is more developed. The displays are based on XML which uses the media object (current pointed into a list or current viewed) and metadata libel1 and libel2 can be displayed (seen in xml description of display). For now I I had no time to go to the code to know how these data are filled and from where, if they are. All of this comes from the same needs, developers have planed a display but the connection with the data which can be easily filled into the source media objects (using xnView for example) has not be done but it is ready (may be in Kodi just some lines of code are missing : using the existing library to extract the right metadata from the object and then fill the corresponding data items). Nevertheless the wiki of KODI is well done (but not very active) and could be considered as on the way of the level of the Codex or Wordpress. Note that the XML pages used for rendering can be easily adapted.

Again, it's not that the standards doesn't exist, and I don't think it's that the renderers doesn't implement these standards (many do, if you use local files instead of a media server). The problem is that neither UPnP AV nor DLNA defines any way to transfer the information. As a consequence, it is impossible for servers and renderers alike to support this.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am Ok, we are alright for the basis.
The first and most important thing is that the metadata of all type are currently weared by the media objects. If the user has added (filled) the metadata they are transmitted with the object (I say the user, I should say the user who have to fill data as description, author and title etc., while a lot of metadata are filled by the equipment used to get the media, everything is ready to use it. The user can use a lot of products to manage media (for images particularly products as xnView), but in fact each hardware producer - media production - Canon, Nikon, Sony, Olympus, Panasonic & co have defined their own exif metadata, IPTC metadata and now finally the EXF - XML - "exotic" metadata, used by their own tools that they propose to manage technically the media (mainly for professionals) but there is a common core containing the same data for "titles, descriptions and technic ref as GPS data etc... KODI offers the show on a map where the images have been generated if GPS data have been filled... but unable to display the title of the image...). All of this can be found here : https://www.exiv2.org/metadata.html and https://www.exiv2.org/tags.html and https://iptc.org/standards/photo-metada ... -standard/ and XML the extension of IPTC the XMP record. This for images but we can found same standards (with a same core) for video and sound (not so developed).
All users can use the metadata to create for the documentation of libraries, and create the content of libraries by filtering these data that are included into the object.
For development of software built to manage these data, store, extract there are soft-libraries which makes the job easy (I have some references).

The current problem is that all these data cannot be used (are not) into display of lists of media and the "info" about a media by the renderers. the chain is not completed. Some bridges have to be developed for the user becoming able to define the display of these (his chosen) metadata. Really for example, define is own zone to display metadata by the render. The reason of the feasibility is that tools to define, build XML/HTML code to display an information zone and at the other end of the chain to display the content for a particular item, these tools are existing and it is easy to implement... Inserting the "scripting" into XMP data and the renderer displays the content, this need only a name for the field, name used by everybody.

You don't need to explain image metadata to me, I know quite well what it is. In fact, I have contributed code to Metadata-extractor on a couple of occations, including low-level parsing of old bitmap (BMP, CUR etc) images. I know very well what Exif and XMP are for example, but I'm not familiar with the IPTC standard. As I've said before, this information is already parsed by UMS, so UMS "knows" the information that you're after. The problem is that there's no way for UMS to transfer this information to the renderers.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am Note that for servers, the lonely problem is with the EXIF data when there is a transcode. The module which writes the exif data used by the renderer must write both the new image parameters and too the full remaining (not changed) metadata blocks.

This isn't actually a problem, since the renderers doesn't read the metadata from the image itself when using UPnP AV/DLNA. All metadata that a renderer knows of when you browse, must be sent from the server to the renderer in a DIDL-Lite segment. The renderer doesn't receive the file itself until you have chosen to "play"/"view" the image, which is too late to present this. If UMS had to transcode an image, it could still use the metadata from the original image, IF there was a way to transfer the information. But, it is not.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am I don't understand, the data blocks for EXIF, IPTC and XMP are in my knowledge perfectly defined and there are libraries to manipulate these data when needed. http://www.exiv2.org et http://libiptcdata.sourceforge.net the https://sourceforge.net/projects/exiftool/ for Php env http://github.com/dchesterton/image a "TOP 25 Exif (and IPTC-XMP) Open source projects : http://awesomeopensource.com/projects

As stated before, it doesn't help if the data blocks are defined and well-known. The fact is that there is no "room" for these blocks in the DIDL-Lite segments, and THAT is the sole problem.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am I have been too fast (for one time).
The metadata have professional application but we must separate "professional tools for media jobs" built often by media acquiring equipments, from the "professional software for media exchange, distribution, rendering and manipulation".
I was thinking that the standards for UpNp and DLNA would define a metadata core "included by authors (media builders)" should be able to be rendered using a metadata canal protected by UpNp and DLNA. The evolution of these standards, that I was ignoring until you tell me about, let me change my point of view.
The EXIF-IPTC_XMP must be considered as a black box transported by the media canals (DLNA). At one extremity the author defining the metadata (except the core which describe technically the content : classically : file definition, extension, container, encryption, size etc. but too know the rights on media, all metadata which are used by the transmission systems) to the renders at the other extremity.
For all the metadata which are not of the precedent package the transmission must be seamlessness and assure the continuity : anything in mediasource, anything found back at the end of the tube.
My recent thought is that when this transparency makes these data independent of UpNp DLNA. There are 3 steps :

• - metadata creation
• - definition of way to render (not existing, may be I could write a prototype in php - javascript env)
• - metadata transmission by servers when there is a transcoding
• - metadata reception by the renderer (extraction to get the data structure - existing tools)
• - rendering using the "definition of way to render"

nota : I currently uses something very near in a site development (a plugin for wordpress that I manages) : a script defines a "zone" to render containing data (metadata) and the renderer displays the content (in my application the script allows to write html which is displayed into a box)

It seems that what I'm trying to say doesn't get through. There is nowhere to put these "black boxes". I don't know what "media canals" you refer to, but there simply is nowhere to put this information. That is why an extension that defined where to put this information would be needed.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am " You must admit that the fact of getting images without the capability to view any title is impossible (not acceptable) and is a non sense.
The lonely information is the filename but because of the needs a the files management it is generally a simple encoded number for the use of the system.
When, on renderers, somebody who is browsing the lists of media cannot access to the meaning of such list of numbers. It should be a system engineer able to read these lists, myself author and manager I am unable to understand the browsers and I cannot access my media (200,000 to 300,000 into 20,00 folders told picasa). I was telling that the lonely way to understand what is render is for the engineer to have near him a computer with the conversion tables from "system numbering" to "human understandable titles and labels"
I add that : this is the job not done by the current systems of servers and renderers for private and most of companies, only done by public media distribution for video (NetFlix), Spotify & co for sound, and (curiously) by the media tools of the social networks. For Clouds "Google photo" as a command "add a description".

Once again, you don't need to convince me that it would be useful. A lot of things would be useful that isn't currently in the standards. The problem is that it is the commercial companies that have created the standards, so they have only included the things that they thought they needed to sell products to consumers. Anything that wouldn't be explicitly useful for them, isn't in the standards. There's not even any standardized way to handle subtitles for video files...

I think what you're looking for is much more "advanced" use then UPnP AV/DLNA was ever intended to be. These standards are meant for consumer devices only, and only aims to do the most basic things like showing an image or playing a video.

Trebly wrote: ↑Tue Aug 04, 2020 4:56 am I think that surely a collaborative effort between all the major open-source projects involved is the lonely solution. But this can be independant of standards because what is needed already exists and will not be changed.

I will work on the current behavior of uPnP AV and DLNA regardless the transmission of the metadata, and the functions of the libraries.
I am not sure but it seems to me currently that there is a solution with a metadata "tunnel" using XMP transmitting a blackbox of metadata.
Then everything depends of

• the media creation with his metadata
• the definition by the author of the content of an area of the renderer (defined as XMP metadata) A new open tool.
• the renderer able to treat the content of the area using the description of the content. An element of library

In fact encapsulate at media generation with XMP into a metadata :
- a copy of involved metadata
- the description of rendering XML/HTML script (using same structure as the "shortcodes" of wordpress if you know)
A renderer module (part of a library) able to display into an area the defined content.

This could be an open project, a complement of the IPTC library for example. Then if the development of the renderer uses the library the functions capability is assured.

You lose me on the way here, I don't quite understand what you're describing, but I can repeat one thing: There MUST be a standard defined (an extension for example) because many different people would have to implement this. There can be no ambiguity or room for misunderstandings, or things simply won't work. The standard doesn't have to be "official" as in published by ISO or others, but it must be a document that precisely describes all the details of how this should work, and it must be generally available to anybody that wishes to implement it. It must also be known and adopted by some major parties.