Name des Programms:
Colorator

Beschreibung:
Mit Colorator kann man jede beliebige Farbe auf dem Bildschirm auslesen ohne erst einen Screenshoot machen zu müssen.

Tastenkombinationen:
Ctrl + C zum anzeigen einer Nachricht mit den Hex und RGB Farbwerten.

Screenshot:


Bekannte Bugs:

1. Das Panel zeigt die falsche Farbe an.
2. Es kann passieren, dass die Funktion der Zwischenablage aufgrund des Hotkeys überschrieben wird. Hier hilft ein Neustart von Windows. (Nicht so schlimm wie es sich anhört. Das Programm fängt die Tastenkombination einfach nur ab.) Nein, kann nicht. Es lag nur daran, das VS abgestürtzt ist.
   
3. Es gibt einen Fehler bei der verwendung von mehreren Monitoren.
4. Das Navigierkreuz liegt einen Pixel daneben.
5. Beim IBeam Cursor liegt die gemessene Farbe ein paar Pixel daneben.

Blau = wird nicht behoben da Fehler von Windows.
Grün = wird bald behoben
Orange = behoben

Credits:
Colorator verwendet die FastBitmapNet Library von Picoflop.

Verwendete Programmiersprache:
VB.NET
IDE: VB 2008 Prefessional

Systemanforderungen:
.NET Framework 3.0 (Sollte es jemand niedriger brauchen - einfach schreiben)
1.5 GHz CPU (GDI saugt Leistung...)

Lizenz/Weitergabe:
Freeware; ClosedSource

Die Idee ist gar nicht mal so schlecht, aber die umsetzung ist schlimm.


Es kann doch nicht sein das dein Programm nach 5 sek. (ruhiger) Mausbewegung 1,5k beansprucht.
Da mach ich wirklich lieber in 2 sek. ein Screenshot und such mir die RGB Werte mit Paint raus.
Desweiteren fehlt igendwie eine Zoom Funktion.

Da vergisst wohl wer, seine Bitmaps zu disposen.

Ansonsten... nützlich, wenn mans braucht.
Vielleicht verwende ichs manchmal, ansonsten muss ich immer meinen Bildschirm in Paint.NET kopieren...

Idee ist Top, Umsetzung eher Flop.

Irgendwie gibts auch nen schrecklichen Fehler bei 2 Bildschirmen:

Ich kann nur auf einen Bildschirm zugreifen (Wen ich auf den anderen gehe, bleibt der Colorator immer noch auf dem anderen).

Außerdem ist die erkennung der Farben auch nicht so der bringer.

Mach weiter, dann wird was..

lg.

Es kann doch nicht sein das dein Programm nach 5 sek. (ruhiger) Mausbewegung 1,5k beansprucht.

Ups, Dispose vergessen
Morgen wird das ausgeglättet.

Desweiteren fehlt igendwie eine Zoom Funktion.

Nö. Aber das vergrößern darf ich nicht der Picturebox überlassen. Wird ebenfalls verbessert.

@hayyu
Danke

nen schrecklichen Fehler bei 2 Bildschirmen:

Ja. Aber du musst das Programm ja nicht unbedingt auf dem zweiten verwenden, oder?
Multimonitor Unterstützung wird aber vllt. irgendwann mal umgesetzt.

Außerdem ist die erkennung der Farben auch nicht so der bringer.

Die ist top, nur MS Failt mal wieder mit dem Drawing.ColorTranslator.
Demnächst kommt eine selbstgeschriebene Funktion zum Einstatz.

Hier mal die ToDo Liste, die in der nächsten Version umgesetzt wird:

1. Bitmap und Image wird Disposed.
2. Zoom wird knackiger.
3. ColorTranslator wird entlassen.
   

So, das Update ist draußen.

Was ist neu?

• Bessere Performance
• Notify Icon
• Viele Bugs wurden behoben
  

Download ist, wie immer, im ersten Post.

haiyyu schrieb:

Ansonsten... nützlich, wenn mans braucht.
Vielleicht verwende ichs manchmal, ansonsten muss ich immer meinen Bildschirm in Paint.NET kopieren...

Für alle HolzShtos-nutzer merke ich kurz an, dass es so eine Funktion schon im ShotEditor gibt:
;)

Bei HolzShoots muss man aber immer noch einen Screenshoot machen.
Die Idee hinter diesem Programm ist aber, dass man dies nicht tuen muss

m9898 schrieb:

Bei HolzShots muss man aber immer noch einen Screenshoot machen.

Ja, ich weiß, dafür ist es auch da. ;)

m9898 schrieb:

Die Idee hinter diesem Programm ist aber, dass man dies nicht tuen muss :P

Und die Idee hinter meinem Post ist, zu sagen, dass man kein extra Programm braucht (welches 1,5GB RAM-Auslastung verursacht, lol), wenn man schon längst HolzShots am Laufen hat. So in etwa wie du. ;)


Anyways, wie wäre es, wenn man selbst Formate festlegen könnte?

welches 1,5GB RAM-Auslastung verursacht

1,5 Mb.

Anyways, wie wäre es, wenn man selbst Formate festlegen könnte?

Was meinst du damit? Die Anordnung von R, G und B? Da kommen bald noch ein paar neue Formate.

m9898 schrieb:

1,5 Mb.

m9898 schrieb:

Was meinst du damit? Die Anordnung von R, G und B? Da kommen bald noch ein paar neue Formate.

Eine Art von Feldvariablen, die dann entsprechend eingesetzt werden. Z.B. sowas:
Pattern: "Der Pixel hat den Rotwert RR, den Blauwert BB und den Grünwert GG."
Dann wird jeweils RR,BB,GG durch die entsprechenden Werte ersetzt. Dann noch andere Felder für Hex-Werte und Fließkomma-Farben/Prozentwerte (0-1).
Jeweils premultiplied Alpha und non-premultiplied. Das brauch' ich manchmal bei HLSL.

Konvertierung in YUV, HSV, HSL und CMYK wären auch noch hübsch.

nikeee13 schrieb:

Das war in der alten Version so. Dispose vergessen.
Naja, der Wert liegt bei ~11,5 Mb, ich hatte mich da etwas vertan.

Eine Art von Feldvariablen, die dann entsprechend eingesetzt werden. Z.B. sowas:
Pattern: "Der Pixel hat den Rotwert RR, den Blauwert BB und den Grünwert GG."
Dann wird jeweils RR,BB,GG durch die entsprechenden Werte ersetzt. Dann noch andere Felder für Hex-Werte und Fließkomma-Farben/Prozentwerte (0-1).
Jeweils premultiplied Alpha und non-premultiplied. Das brauch' ich manchmal bei HLSL.

Konvertierung in YUV, HSV, HSL und CMYK wären auch noch hübsch.

Das erste ist jetzt nicht gerade notwendig, weil es eh noch mit anderen RGB Formaten umgesetzt wird. HSL ist bereits in arbeit und das andere muss ich dann mal schauen.

Du sagst ja, man muss nich extra einen Screenshot machen, aber eigentlich wird ja trotzdem ein Screenshot gemacht

Blau = wird nicht behoben da Fehler von Windows.
Blau, ist doch eine andere Farbe, aber BTT:

Zu viel Auslastung.
Es wäre gut wenn man es in den TrayBereich minimieren könnte, damit man es schnell starten kann aber davor, würde ich erstmal die Auslastung fixen und das liegt 100% nicht an GDI+ weil ich z.B Welten mit GDI+ generieren lasse (ca. 200 Bilder) und das hat kurz gerade mal 13 k.

5/10
Mfg

Blau, ist doch eine andere Farbe, aber BTT:

Du sollst auf die Farbe, nicht auf den Text achten

Zu viel Auslastung.

Ok, 15% auf dem i7 sind eigentlich schon viel. Aber um ein flüssiges Bild zu erzeugen muss die Auslastung sein.
Ich kann es aber auch mit einer automatischen Erkennung der Leistung machen. Kommt dann im nächsten Update.

Es wäre gut wenn man es in den TrayBereich minimieren könnte,

Schon mal geschaut, was passiert, wenn du das Programm schließt?
Bei der nächsten Version werde ich das noch etwas verbessern.

100% nicht an GDI+

Fast. Der Rest ist Windows API.

Welten mit GDI+ generieren lasse (ca. 200 Bilder)

In deiner vollen Bildschirmauflösung? Der Bildschirm muss ja erst einmal abgelichtet werden.

m9898 schrieb:

15% auf dem i7

Wtf. 1,5GB RAM und 15% CPU (i7!). Nice. Wird das 'nen Benchmark?

m9898 schrieb:

Aber um ein flüssiges Bild zu erzeugen muss die Auslastung sein.

tinyurl.com/3w9ub3l

m9898 schrieb:

In deiner vollen Bildschirmauflösung? Der Bildschirm muss ja erst einmal abgelichtet werden.

GDI+ ist bei richtiger Verwendung schon zu ordentlichen Sachen fähig.

Blau = wird nicht behoben da Fehler von Windows.

Na klaaar. Unfähigkeit des Programmierers ist nicht auf das Betriebssystem abzuwälzen!

MfG Solaris

Schau dir den "Blauen" Punkt mal an. Es gibt genügend Programmierer, die solche Fehler noch nicht mal auflisten würden.

1. [Beta] FastGraphicsLib 1.0.0.5
Wusste gar nicht, dass die von picoflop ist...

2. Dein programm macht auch nen Screenshot...schreibts in nen Bitmap usw...
msdn.microsoft.com/en-us/library/dd183370%28v=vs.85%29.aspx
z.B. ist schonmal schneller...

1. [Release] FastBitmapNet (Ist zwar uralt, macht aber was es soll.)

2. Die "Performance" liegt eher an dem Vollscreenshoot. Demnächst werde ich es so machen, das nur der benötigte Bereich um den Mauszeiger abgelichtet wird.

Hier mal ein Screen der nächsten Version 0.3:

Dieses mal kommt noch mal eine viel bessere Performance, automatische justierung der FPS und die Farbwerte HSL und CMY. CMYK wird dann in der Version 0.4 kommen.