227
edits
m (Dvdkhl moved page User:Dvdkhl to User:Dvdkhl/Ideas) |
|||
(30 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 == | ||
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 | '''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. | The idea presented here tries to represent character relations completely text based without the help of any images which contain graphs. | ||
Line 84: | Line 243: | ||
==== Posession Relation Preset ==== | ==== Posession Relation Preset ==== | ||
e.g. Pokemon | 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 == | == Character Relations based on episode range == | ||
Line 93: | Line 268: | ||
== Tool for adding any kind of data to AniDB == | == Tool for adding any kind of data to AniDB == | ||
== MangaDB File/Chapter/Volume Hashing == | == 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