[Feature Request]: Model Title & tags added to JSON information

[JingJang]

Is there an existing issue for this?

• [X] I have searched the existing issues and checked the recent builds/commits

What would your feature do ?

In the JSON info file store:

• Model title with ability to sort by title
• Model tags to have an ability to filter out the models.
• Model homepage URL (Updated)

[w-e-w]

what model sd checkpoint? Lora? or something else others? what title specifically are you talking about this?

Click to show image

you should already be able to sort by title unless you're referring to something else as the title

Click to show image

if lora then by are you talking about training tags for lora

Click to show image

[JingJang]

The title is not name of file. So title can include characters and be more descriptive than filename. Now I slept on it maybe its not a good idea.

As to the tag, I meant descriptive tags rather than trigger words. So an alternative to directories you have ability to filter out through descriptive words. So example, "female", "blonde", "White", "European" would be descriptive words for a specific actress.

[w-e-w]

basically you're asking the ability to give custom titles and custom tags that can be used for grouping and filtering I can see this being useful for some people

I do have plans of to implement a sort by use frequency if I do so I would try and see if I can also work that in as well no promises

[JingJang]

Thank you

[JingJang]

Add to the list Model Homepage URL for extra information.

[w-e-w]

Add to the list Model Homepage URL for extra information.

is that really necessary? why not just put it inside descriptions models itself doesn't have a homepage URL yes users often download model from some places like huggingface or civitai as opposed to creating models themselves but URL is not part of the metadata of the model so there's no standardization which means it cannot be automated in other words you just be creating a new field specifically named URL but it serves exact same function as description extension can read from custom fields if they want to

there's nothing stopping you from inputting the URL in the metadata itself it's just not read and displayed by web UI so it's currently meaningless to webui I suppose it is possible that we can allow certain custom fields to be displayed if user choose to be able to

when we talk about metadata we not talking about the metadata you grab from civitai, we are talking about the metadata embedded inside the model itself

if this is going to be implemented I can only see it being something that the user choose to enable which would allow a key matching a certain name to be automatically displayed and editable

[JingJang]

Point taken.

[w-e-w]

no, please voice your opinion I'm not shutting the audio down I'm just expressing my own thoughts if you can make a compelling argument as to convince whoever is going to end up making it then someone might actually do it

when making a future request the most important thing is to convince people that this is a good idea and this is needed and if people took interest they might make it a reality

[w-e-w]

currently I think the best approach is to make the UI extendable by settings and extensions settings allowed basic extensions like extra fields that user might want to input and extensions allow it to do more things depending on what the extensions go are

[zixaphir]

Just adding my two cents here since I got pinged into this: If the metadata JSON file is meant to be extensible, I'd prefer a standard format for the main structure of the JSON that is static and concrete, with a separate standard field for extensions to dump whatever they want in to reduce incompatibilities in the underlying format. IE, something like this:

{
    "description": "This is an example",
    "sd version": "Unknown",
    "activation text": "dummy_text",
    "preferred weight": 0,
    "extensions": {
        "my_extension": { 
            ...whatever I want to put here...
        },
        "somebody_elses_extension": { ... },
    }
}

[w-e-w]

good idea if you're going to make it extendable it's best to have each extension place it's value under a separate dictionary this doesn't prevent extensions from modifying the values but it should be a convention

[dthmax]

Hello, sorry for bothering.

But may i ask if this still in consideration?, im very interested in the custom tags part, it would help a lot when searchinf for especifics.

basically you're asking the ability to give custom titles and custom tags that can be used for grouping and filtering I can see this being useful for some people

I do have plans of to implement a sort by use frequency if I do so I would try and see if I can also work that in as well no promises

Thanks for your time and thanks for all work done