User:Dvdkhl/Ideas: Difference between revisions

From AniDB
Jump to navigation Jump to search
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)
** &supe; Character(<u>Id</u>, Gender, DateOfBirth, DateOfDeath, Age, ...)
** &supe; Organisation(<u>Id</u>, ...)
** &supe; Vessel(<u>Id</u>, ...)
** &supe; 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 &isin; Characters | isMale Brother && &forall; Parent &isin; Characters( Sibling isChildOf Parent && Brother isChildOf Parent ) }
** Aunts = GetAunts(NephewOrNiece) = { Aunt &isin; Characters | isFemale Aunt && &exist; Parent &isin; 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

Latest revision as of 02:15, 8 October 2014

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

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(Id, ...)
  • Entity(Id, EntityType, GuiseId, Name, ...)
    • Used to describe an entity in a single state (Specific point in time or episode)
    • ⊇ Character(Id, Gender, DateOfBirth, DateOfDeath, Age, ...)
    • ⊇ Organisation(Id, ...)
    • ⊇ Vessel(Id, ...)
    • ⊇ Mecha(Id, ...)
  • EntityGuise(EgoId, GuiseOfId)
    • Connects characters which are the same character only in a different state (Aged, Transformed, etc.)
  • Anime_EntityEntityRelation(AId, RelationType, 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

Social

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.

Model

  • Additional Tables
    • FamilyRelations(RelationId, ChildId, ParentId, IsVirtualParent, IsAdopted)
    • SocialUnions(Id, TypeId)
    • SocialUnionTypes(Id, 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
Kyouran Kazoku Nikki (5580)
Papa no Iukoto o Kikinasai! (8686)

Views

Assisted Conversion

Add/Edit Form

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

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;
}

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).
    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).
    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

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 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

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;
}
  • 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