227
edits
m (→Ideas) |
m (Dvdkhl moved page User:Dvdkhl to User:Dvdkhl/Ideas) |
||
(36 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
Just a place to write down my ideas for AniDB before they reach oblivion. | Just a place to write down my ideas for AniDB before they reach oblivion. | ||
'''Note''': These are my individual ideas and may not necessarily reflect where AniDB is heading! | |||
= Ideas = | = Ideas = | ||
== Character Relations Graph == | == Clubs == | ||
== User - Object Set - Analysis == | AYEAR: academic year | ||
CAYEAR: Current academic year | |||
Clubs | |||
*Status | |||
**Disbanded | |||
***Cannot be opened again without permission | |||
**Disbanding | |||
***Transitions to [Disbanded] after end of CAYEAR with no club activity in CAYEAR | |||
***Transitions to [Gathering] after club activity | |||
***Any member kind of member activity counts as club activity | |||
***Looses all privileges | |||
**Gathering | |||
***Transitions to [Disbanding] after the end of the current academic year if there was no activity in the current academic year | |||
***Transitions to [Club] after a member (who will become club president) request who has the approval of the <Student Council> | |||
**Club | |||
***Transitions to [Gathering] if <Student Council> NOTICES it has less than 5 members after CAYEAR | |||
***Club leaders must remove members after a SEMESTER of inactivity otherwise the <Student Council> MAY give the club a STRIKE | |||
***Has a "club room" which members may enter to update the inactivity date (of the club and member) | |||
***Must participate in "AniDB Fair" and contribute to it | |||
*Users | |||
**May only join one club simultaneously | |||
**May visit other clubs | |||
*Mandatory Clubs | |||
**Student Council | |||
***AniDB Board members | |||
****AniDB staff instructing the AniDB Club Leader | |||
***AniDB Club Leader | |||
****Responsible for looking after all clubs | |||
**AniDB Development | |||
***Recruiting users for development | |||
***Place to post development jobs to for recruits to do | |||
**AniDB Management | |||
***Recruiting users for maintenance | |||
***Place to post maintenance jobs to for recruits to do | |||
Events | |||
*AniDB Fair | |||
**At the end of AYEAR | |||
*AniDB Awards | |||
**Annual | |||
**Partner up with arc awards? | |||
**Participants: | |||
***Selectors: Any [Club] whose leader requested participation | |||
***Voters: Any [Gathering] who requested participation | |||
***Any club who requested participation must do so, otherwise the <Student Council> MAY give it a STRIKE | |||
***Drafting happens two weeks before voting | |||
***If enough participants are found the event commences | |||
**Procedure | |||
***arc awards style over one week | |||
== Character Relations Graph (2. Approach) == | |||
'''Note''': This model may not be project-able to the current model in use. | |||
The idea presented here tries to represent character relations completely text based without the help of any images which contain graphs. | |||
Instead of trying to generate a simple view over the complete dataset, this approach will use many simple views. | |||
The basic idea is to take each type of relation (family, enemy of, ally of, etc.) and create one view for each for a global overall view. | |||
In addition a local view is provided to show relations in detail. | |||
The local view is simply a cursor which points to an entity for which information of itself will be shown and in addition to that the nearest neighbours. | |||
When the user clicks on one of the neighbours the cursor will move to that entity. | |||
For this to be user friendly mouse scrolling needs to minimized. | |||
=== Views === | |||
* Contains a list of selected entities | |||
* Each view has to highlight a selected entity | |||
* If graph simple enough, fallback to different simpler view? | |||
==== Global View ==== | |||
* Layered: Each relation type is displayed in one (separate) layer | |||
* Each layer has a (can) have a more specialized model/view | |||
* Prefer small graphs, i.e. A family view should only contain its immediate Members (Parents, Children, etc.) | |||
** Some entities have to shown more than once | |||
==== Local View ==== | |||
* Convert each relation model to a single graph | |||
* A cursor which moves upon that graph | |||
* Take the first selected entity for the cursor | |||
* Switching cursor position replaces the selected items and with the new cursor entity | |||
=== Models === | |||
* Each relation type has exactly one model | |||
* The model is used to describe the relationtype as concise as possible | |||
* Model also has to define how its data is (de)serialized | |||
** Relational Database as storage (Anime_EntityEntityRelation.RelationId as Primary Key) | |||
* Avoid complex structures | |||
** No reference to other models allowed | |||
=== Prerequisites === | |||
(Assumed) Global DB Tables: | |||
* Anime(<u>Id</u>, ...) | |||
* Entity(<u>Id</u>, EntityType, GuiseId, Name, ...) | |||
** Used to describe an entity in a single state (Specific point in time or episode) | |||
** ⊇ Character(<u>Id</u>, Gender, DateOfBirth, DateOfDeath, Age, ...) | |||
** ⊇ Organisation(<u>Id</u>, ...) | |||
** ⊇ Vessel(<u>Id</u>, ...) | |||
** ⊇ Mecha(<u>Id</u>, ...) | |||
* EntityGuise(<u>EgoId</u>, <u>GuiseOfId</u>) | |||
** Connects characters which are the '''same''' character only in a different state (Aged, Transformed, etc.) | |||
* Anime_EntityEntityRelation(<u>AId</u>, <u>RelationType</u>, RelationId) | |||
** Anime_EntityEntityRelation.RelationId as Primary Key for Relation Models | |||
** Each model has its own tables | |||
** The usage is defined by each model/view pair | |||
=== Presets === | |||
<div style="margin-left: 1em; background-color: #F8FFFF; border: 3px black double;"> | |||
<h2>Social</h2> | |||
Replacement for the "family of" relation. Currently there is no standardized way to specify blood relations. | |||
This makes it impossible to form small groups of information like a group with only directly related characters (i.e. Father, Mother, Children). | |||
But since this Character-Relations approach is based on displaying small groups of information a more fine grained representation is necessary. | |||
<div style="padding-left: 1em;"> | |||
<h3>Model</h3> | |||
* Additional Tables | |||
** FamilyRelations(RelationId, ChildId, ParentId, IsVirtualParent, IsAdopted) | |||
** SocialUnions(<u>Id</u>, TypeId) | |||
** SocialUnionTypes(<u>Id</u>, Label, Style) | |||
** SocialUnionMembers(RelationId, MemberId, UnionId) | |||
; FamilyRelations | |||
: Represents the bloodline of characters | |||
: For sibling relations where the parents do not exist a virtual parent is created and the fields are set accordingly | |||
: For more flexibility IsAdopted can be set to true for adopted children or other kinds of families (e.g. Patchwork families where no blood relations exist) | |||
; SocialUnions | |||
: Used to describe bonds of social status (i.e. Marriage, PoliticalMarriage, PatchworkFamily) | |||
; SocialUnionTypes | |||
: Used by views to define default style | |||
; SocialUnionMembers | |||
: Used to map characters to social unions | |||
: If necessary add a Type field to describe directional relations (i.e. (King, Mistress) vs (Queen, Lover or whatever the equivalent for Male Mistress is)) | |||
: Redundant? When character A has child B (FamilyRelations) and forms a relationship with character C (SocialUnionMembers). Force add FamilyRelations entry between B and C? | |||
* Almost all (if not all) social relations can be derived from those tables | |||
** Brothers = GetBrothers(Sibling) = {Brother ∈ Characters | isMale Brother && ∀ Parent ∈ Characters( Sibling isChildOf Parent && Brother isChildOf Parent ) } | |||
** Aunts = GetAunts(NephewOrNiece) = { Aunt ∈ Characters | isFemale Aunt && ∃ Parent ∈ Characters ( NephewOrNiece isChildOf Parent && (Parent isSiblingOf Aunt || Parent isSiblingInLawOf Aunt) ) } | |||
** etc. | |||
; Example | |||
: [http://pastebin.com/GThbEJAy Kyouran Kazoku Nikki (5580)] | |||
: [http://pastebin.com/MxkJ2YtY Papa no Iukoto o Kikinasai! (8686)] | |||
<h3>Views</h3> | |||
<h3>Assisted Conversion</h3> | |||
<h3>Add/Edit Form</h3> | |||
</div></div> | |||
== Character Relations Graph (Abandoned) == | |||
'''Note''': This model may not be projectable to the current model in use | |||
The idea presented here tries to represent character relations completely text based without the help of any images which contain graphs. | |||
Instead of trying to generate a simple view over the complete dataset, this approach will use many simple views. | |||
The basic idea is to take each type of relation (family, enemy of, ally of, etc.) and create one view for each for a global overall view. | |||
In addition a local view is provided to show relations in detail. | |||
The local view is simply a cursor which points to an entity for which information of itself will be shown and in addition to that the nearest neighbours. | |||
When the user clicks on one of the neighbours the cursor will move to that entity. | |||
For this to be user friendly mouse scrolling needs to minimized. | |||
=== Prerequisites === | |||
'''Needs to be reworked: One model/view for all either too simple to represent all cases or too complex to display => One model/view for each relation type''' | |||
<pre>class Anime_CharacterCharacter_Relations { | |||
int AId; | |||
Anime_CharacterCharacter_Relation[] Relations; | |||
} | |||
class Anime_CharacterCharacter_Relation { | |||
Anime_CharacterCharacter_Relation_Type Type; | |||
ConnectedGraph[] Graphs; | |||
} | |||
class Anime_CharacterCharacter_Relation_Type { | |||
Label Name; | |||
EdgeInfoControl[] AllowedEdges; | |||
} | |||
class ConnectedGraph { | |||
Label Name; //For something like clubs/organisations/etc. | |||
Entity[] Entities; //Graph Structure Info | |||
Tuple<EdgeInfoControl, Relation>[] Relations; //Graph Structure Info | |||
} | |||
class Relation { //Edge | |||
EdgeInfo Info; //Informational purposes only! | |||
Entity A, B; //A is Start and B is end Vertex if graph is directed | |||
} | |||
class EdgeInfo { | |||
Label Start, Middle, End; | |||
} | |||
class EdgeInfoControl : EdgeInfo { | |||
bool IsWeakLink, IsDirected; | |||
} | |||
class Entity {//Vertex | |||
//Informational Data | |||
} | |||
class Label { | |||
string Text; | |||
Bitmap Image; | |||
}</pre> | |||
''Text needs to be updated to sync with the classes above'' | |||
* Anime_CharacterCharacter_Relations holds all information necessary for Character-Character of an Anime. | |||
* Each Character-Character Relation Type (family of, enemy of, etc.) is represented by Anime_CharacterCharacter_Relation, where Anime_CharacterCharacter_Relation_Type sets restrictions. | |||
* Anime_CharacterCharacter_Relation_Type contains the info whether the graphs are directed or undirected, a label (e.g. Family) and specifies the allowed edges for the graphs. | |||
* Anime_CharacterCharacter_Relation contains in addition to the type, a list of graphs (ConnectedGraph) which are required to be connected (i.e. every vertex is reachable from every vertex). <br/> If a Character-Character Relation cannot represented by a single Connected Graph it is split into several ConnectedGraphs until the condition is satisfied. | |||
* ConnectedGraph contains the graph structure (vertices, edges) and a label which serves as a header for the graph (i.e. Organisation). <br/> The Relations field contains all edges in addition to its type which must be contained in the associated Anime_CharacterCharacter_Relation_Type.AllowedEdges | |||
* Relation simply defines an edge in the graph which can contain additional information which only serves informational purposes. | |||
Add abstraction, i.e. allow subclasses for each Relationtype to allow special behaviours for views. | |||
=== Presets === | |||
==== Family Relation Preset ==== | |||
; Definition | |||
: Label: (Family, FamilyIcon) | |||
: IsDirected: Yes | |||
;Edges (IsWeakLink, IsDirected, StartLabel, MiddleLabel, EndLabel) | |||
:Undefined: (Yes, No, false, "", "", "") | |||
:Parents: (Husband, Wife) //Samesex Parents? | |||
===== View ===== | |||
Aim: Each connected graph shows to each other unrelated families | |||
Possibility1: Special Relation, Container with Parents as Header and Children as Content => Recursive display | |||
Possibility2: Simple edges describing Parent-Child Relations => May result in a lot of edges | |||
Adoption: | |||
==== Mentor Relation Preset ==== | |||
e.g. Marimite | |||
==== Posession Relation Preset ==== | |||
e.g. Pokemon | |||
=== Views === | |||
* Contains a list of selected entities | |||
* Each view has to highlight a selected entity | |||
* If graph simple enough, fallback to different simpler view? | |||
=== Global View === | |||
* Layered: Each relation type is displayed in one (separate) layer | |||
* Each layer has a (can) have a more specialized model/view | |||
=== Local View === | |||
* Convert each relation model to a single graph | |||
* A cursor which moves upon that graph | |||
* Take the first selected entity for the cursor | |||
* Switching cursor position replaces the selected items and with the new cursor entity | |||
== Character Relations based on episode range == | |||
== User - Object Set - Analysis (Snippets of Wisdom) == | |||
== AniDB Event: Anime of the Month Clean-up == | == AniDB Event: Anime of the Month Clean-up == | ||
== New API: Based on TCP and EBML == | == New API: Based on TCP and EBML == | ||
== AVDump2: Module for adding file entries (streamlining the adding process) == | |||
== Tool for adding any kind of data to AniDB == | |||
== MangaDB File/Chapter/Volume Hashing == | |||
* Image Hashing | |||
** http://www.phash.org/docs/pubs/thesis_zauner.pdf | |||
** Resizing based (not optimal?) | |||
*** http://www.hackerfactor.com/blog/index.php?/archives/432-Looks-Like-It.html | |||
*** http://www.hackerfactor.com/blog/index.php?/archives/529-Kind-of-Like-That.html | |||
** Detect Text Bubbles | |||
** Simple OCR | |||
*** Recognising which character set is used (Latin, Asian) | |||
**** Infer which language is used | |||
=== Image Hash Algorithm === | |||
* Convert to grayscale (Black and white with thresholding?) | |||
* Rotate image so the height is always greater or equal to the width | |||
** This is done to reduce the ratio distortions | |||
* Resize to a fixed Dimension | |||
** Needs to ensure that the written text is still readable | |||
** Proposed Dimension: 1024x2048 (common ratios: 1:3 and 2:3 => 1.5:3 => 1:2) | |||
* Tile the image into 64x64 blocks | |||
** With this we get 512 blocks for all images | |||
* Apply 2D DCT for each block | |||
* Take only a specific range of coefficients from the 2D DCT Block | |||
* Produce hash from the selected ranges | |||
==== Grayscale Conversion ==== | |||
<pre>byte ToGrayScale(r, g, b) { | |||
var min = Math.Min(r, Math.Min(g, b)); | |||
var rgDiff = 1 + Math.Log(1 + Math.Abs(r - g), 256) * 2; | |||
var rbDiff = 1 + Math.Log(1 + Math.Abs(r - b), 256) * 2; | |||
var bgDiff = 1 + Math.Log(1 + Math.Abs(g - b), 256) * 2; | |||
var val = (byte)MathEx.Clamp(0, min * (rgDiff + rbDiff + bgDiff) / 3, 255); | |||
return val; | |||
}</pre> | |||
* Grayscale images are unaffected | |||
* Pixel showing color are suppressed | |||
** Works as long as there are (black) contour borders | |||
** Might need border detection for contourless images | |||
==== Color Edge Detection ==== | |||
* Generate pairwise channel difference images r-g, r-b, g-b | |||
** No edges will be detected for grayscale images | |||
* Apply smoothing to reduce edges introduced by noise | |||
* Detect edges (steep gradiants) in each generated image | |||
* Combine edge images | |||
* Combine EdgeImage with grayscale image | |||
* ResultImage = Max(GrayScaleImage, Edge(Smooth(r-g)), Edge(Smooth(r-b)), Edge(Smooth(g-b))) | |||
== Remove/Change "hostile" judgemental anime/character tags? (Abandoned) == | |||
* Meh, just me overreacting a bit | |||
** Approval rating seems to take care of it |
edits