Shop Mobile More Submit  Join Login
Oh boy, since I've been tagged in a total unexpected and absolutely surprising way by C-91 (:iconteheplz:), I'm spamming you with my shit split-screen (1920x1080 next to 1440x900, somebody should whip me with barbwire fence for that...seriously!) fractal environment as well :lmao:

Unbenannt-3 by Xyrus-02

In it, you can see me having fun with 48 bit palette builds and particle systems in Apo7x!
To continue the mob squad, I'm tagging Fiery-Fire, SaTaNiA and Clepsidras. Show me your things!!
Usually I'm not the one who responds to tag but since C-91 insists :lmao: First and foremost, if you respond to my taggings (I apologize in advance haha) then you should do it the following way:

1. Make up your mind

Make a post to your DA journal. The post should contain your list of ten holiday wishes. The wishes can be anything at all, from simple and fandom-related ("I'd love a ______ icon that's just for me") to medium ("I wish for _____ on DVD") to really big ("all I want for Christmas is a new car/computer/house/TV."). The important thing is, make sure these wishes are things you really, truly want.

If you wish for real life things (not fics or icons), make sure you include some sort of contact info in your post, whether it's your address or just your email address where Santa (or one of his elves) could get in touch with you.

Also, make sure you post some version of these guidelines in your DA or link to this post so that the holiday joy will spread.

2. Tag along

Surf around your friends list (or friends' friends, or just random journals) to see who has posted their list. And now, here's the important part:

If you see a wish you can grant, and it's in your heart to do so, make someone's wish come true. Sometimes someone's trash is another's treasure, and if you have a leather jacket you don't want or a gift certificate you won't use -- do it.

You need not spend money on these wishes unless you want to. The point isn't to put people out, it's to provide everyone a chance to be someone else's holiday elf -- to spread the joy. Gifts can be made anonymously or not -- it's your call.

There are no rules with this project, no guarantees, and no strings attached. Give, and you might receive. and you'll have the joy of knowing you made someone's holiday special.

Here are mine

  • That you guys add more stuff to the fractal gallery to look at (there is a bunch of awesome stuff but I'm greedy, deal with it 8-) )
  • A bunch of time (yes, it's right. I don't have any!)
  • The cold/flu wave to be over (it's rather annoying to catch another virus every other week)
  • Not another train driver/plane pilot strike
  • A box of gingerbread (I love that shit!)
  • NVIDIA Shield
  • A custom icon (I stole that wish, sue me)
  • Snow
  • Xmas cards (yes I like those)
  • Happy holidays for all of you :)

Here be dragons tags

deadened-glow SymmetryBox SaTaNiA sil333 Yasny-chan
Hey guys,

since obviously it became a problem to share and consume resources in a once free and open-spaced fractal community lately, I've taken down any of my resources off deviantART.

But don't sweat, it's actually been on the roadmap for a long while since my deviantART profile is, in future, only about artworks.
Here is where you can find the resources I keep up instead:

If you want to learn when I upload a plugin or something else nifty, you can follow my Twitter.


PS: Yes, the download page is supposed to look like this. I just filled it with links but didn't add a style or anything :lol:
PS2: I think I'll also post updates on my activity feed here on DA since many people don't seem to use Twitter or have reasons not to do so.
Some of you know of my general distrust in GPL and other open source models. I think it can be helpful but in many cases, it leads to no good because especially GPL is forcing the model on any project which aims to derive from it. In some cases, it doesn't even have to be a direct derivation but merely the same idea or the same technical approach.

From my experience, I remember an example where dev A provided code to manage instances of shared objects / dynamic link libraries (.so, .dll) completely in-memory. It is okay if a non-technical person doesn't understand the purpose of such a technique - the point is: it is an idea with an approach and dev B came up with a similar idea, independently from dev A. Now dev A had his code under GPL and in the end, DCMA'd dev B because his code was similar (!), however completely independent from the code of dev A. Dev A now required dev B to put his code under GPL too because his license says so. Obvious, that this situation is - excuse my wording - shit.

This is my opinion and you don't have to agree. But recently, I found another example of a project which ran in a similar trap:…

In this case, a person named Mr. Wolfe is an ex developer of project "Spigot" to which he filed a takedown request. But why?

There is another project with the same purpose called "Bukkit" but this other project got acquired by a company called "Mojang" which incorporated it in a commercial product. During the aquiration, code from "Bukkit" migrated to the commercial product. Code, Mr. Wolfe allegedly wrote under GPL. In consequence, he offered two options: either the commercial product becomes GPL (completely illusional, IMO) or he would file a takedown request. And why is "Spigot" involved? Simple. "Spigot" uses the same code. Mr. Wolfe now states, that "his" code is belonging to Mojang (and the problem with them is that they don't have their product under GPL) and this means, "Spigot" is using code owned by Mojang through the acquiration of "Bukkit".

Yes, I know it sounds complicated and yes, it is. Did I understand and/or state the situation wrong? Please correct me in the comments in this case because it is really hard to see through it.

In any case: legally, he might be right because his license, the GPL, indeed allows him to make his claim. What he forgets, though: both, the other open-source project and the commercial product have a gigantic community behind them. This community does now not have access to the downloads and code folders the project offers. The project is essentially completely on halt and public access has been denied until the case is decided.

The question is: who is helped if somebody goes war vision just for the sake of GPL? The license itself is actually a not-so-bad idea but it simply can't work because there will always be someone who claims an idea or a piece of code is "his" (or "hers") and you can work with the best belief but once it happens, your project is doomed if you don't have resources to go legal on it.

Not that I expect it - it is simply taking the unfortunate example of Spigot and mapping it to the Apophysis project - but let's play a mind game: if now an old Apophysis/flam3 developer came and DCMA Apophysis 7x, do you think I would feel like going on court for it? Certainly not. The project would be closed, all downloads and code resources would be taken of the web, end of story. And who is helped by this? Exactly.

My personal way is that whenever I get to decide on the license (it is not the case for Apophysis because I have to stick to the provided license), I decide against GPL and in many cases, also against open source.

The above is a simple expression of my own opinion. Feel free to disagree, I won't blame you :) I just made really bad experience with GPL and I think it doesn't work as it was designed and the case of "Spigot" confirms me in my opinion which is why I wrote the journal. If you want to bring counter-arguments, I'm happy to hear from you in the comments or via note. You all know, I'm a friend of civilized discussions.
This gorgeous piece of art:

Glimmer on a Sunday Afternoon by C-91

...magically turned into this (quite physical) piece of art:
1010121 769779203032729 2058523483 N by Xyrus-02

...and landed in my mailbox :dummy: After I startled my minions to begin an investigation (not really, I kinda knew what's coming but I still was a tad bit surprised when I found the package tee hee), they came back to me with C-91's name. Oh joy! To reward her for this sweet gift, I shall praise her name, give her a hug (:hug:) and leave you to the quest of examining her profile and appreciate her art for which I give you a few examples:

Away She'd Fly by C-91Plasma Blossom by C-91Al Mattino by C-91
Parade by C-91Marbles by C-91Summertime Sadness by C-91

Thankies :huggle:
  • Mood: Thrilled
You might or might not know that I've been fiddling around with Turing McCabe-patterns in the past. Well the good news is: in the present too! For those of you who don't know what this is: it's an algorithm producing nice images like this one:

I've created an explorer utility for myself. Well, I created one for you too but it's old. I'm constantly changing mine and see what you can do with the algorithm. And I've come to a major progress I wanted to share with you.

One thing is a thing you might already know. The original algorithm initializes with a noise field. This means, the first frame is just noise and then the pattern develops. I had one thought which changed that concept a bit: why noise? The Jonathan McCabe seemed to need a field of unstructured data from where a pattern evolves through convolution. My idea was to replace that with something else. To the mathematical idea, an image is sort of unstructured too. It's man-made. Most of the time. So technically, you could use an image to ignite the algorithm. And I did.

The below video shows how that looks like:

Now imagine what it could do to a fractal (flame) rendered into an image file and loaded into the algorithm...!

The second thing was sort of not my idea. I want to say that right away because I was victim to a mistake. When I started to implement this thing, I wasn't aware of that somebody did that before me. I discovered when I was done. But through the fact that there are two independent implementations now, my version and the other author's version are unique in their own ways now. I'm talking about painting into the algorithm's data field using your mouse. Something which provided me HOURS of fun!

My way was to "reset" the areas I was painting on. So basically, wherever your brush strokes the field, there will be noise. It's sort of like you're "stirring" that reactive soup the algorithm paints on your screen. Effectively, you're agitating the algorithm in a limited area.

See how that looks like in the below video:


This gives the whole thing some more interactivity than just dragging sliders and pushing in images. I sort of want to experiment with more ways to influence the algorithm.

I'll keep you up-to-date!
To excuse myself from the artificial hoax from earlier, I have a hotfix release for 15C for you ;) Here the changes:

+ Fixed two strings regarding the Chaotica integration. They were always english. The language files have been adjusted accordingly.
+ Fixed the "dot"-bug with the waves2-, noise- and crop-variations (and possibly more) occuring when you use multithreaded rendering. The origin was a structural misconception with the opacity handling. It now works smooth & fine! No corrupted renders in my own tests. If you have some after this release, please report!
+ Added file type registration scripts in the portable (ZIP)-package

Installer (32 bit)

Installer (64 bit)

Portable package (32 & 64 bit)

Source code

I have made an installer for Apophysis 7X 15C available at

Please be aware that this installer is for Microsoft Windows only. It comes in two versions: for the 32 bit and the 64 bit version of Apophysis 7X 15C. The two versions can be installed side-by-side. Even in a single folder (but be careful - you might not want to uninstall the 32 bit version if you have the 64 bit version in the same folder so I recommend keeping the folders separate)

Unlike for the ZIP-package, 32- and 64 bit version do not come in a single file!

Currently, the german, italian and chinese language packs are shipped with the installer. The other language packs are outdated and for the vanilla version 7x15 only.

The 32 bit-installer offers you to install a collection of DC-plugins as well as two sample scripts. Please mind that upon uninstallation, these plugin .DLL-files will be removed even if they were there before. This also applies to scripts and other files. That's why you should not install Apophysis 7x over an existing version in the same folder. Choose a new folder or backup the old version first.

The installer includes the hotfix release #7 but future hotfix releases will not be included with the installer. A new installer is uploaded only on major releases (15D? 16?) so that a hotfix release is more like a "patch" and needs to be installed manually. The approach is the same as for 2.02 as the major release and 2.09 as the minor release:

1) Install Apophysis with the latest installer
2) Download the latest hotfix/patch if available and copy Apophysis7X.exe or Apophysis7X64.exe into the install folder

Installer (32 bit)

Installer (64 bit)

PS: A hotfix #8 seems likely because there is one bug remaining; apart from that, no other patch releases are planned. You are safe to consider this installer version the "final" 7x15C with a minor bug in the multithreaded renderer (known problem with "noise" and "crop"-variations)
Oops! Something went wrong with uploading the files when I added this hotfix. The download links pointed to Hotfix #6 still. Please re-download Hotfix #7 if you downloaded it already. It's now pointing to the correct version.
Thanks, fengda2870 for pointing it out.

I added two rather critical fixes to Apophysis 7x15c:

+ Fixed post_curl variation by doing the following on Zueuk's suggestion (more below)
+ Fixed a bug which created a spiral (why so ever) on the blur variation when using multithreading

post_curl_c3 got removed and post_curl was made a simple, 3D aware variation (Z-passthrough)
The functionality of the former, built-in post_curl was renamed to post_curl3D which essentially a post'ified curl3D where the latest post_curl behaves like the plugin (except for the Z-passthrough)
This fix was done as a result of the recent CDA.

The problem that the blur-variations as well as the crop-variations might malfunction if you use MT and render anything non-transparent PNG is known and subject to fix in a later release, still. The fix for the spiral problem is kind of rough and has a (very very tiny) impact on the performance. Most likely, you won't notice it. But I want a better fix in there too :)

Download binaries (32 and 64 bit)

Download source code

Okay. A few more TINY problems were addressed here:

+ Fixed author/language name loading code. Was still trying to read ANSI-characters which scrambled the display in non-ANSI languages (actually a not-so-tiny problem)
+ Added chinese localization contributed by fengda2870 - available from
+ Fixed a few strings which were not localized

I really hope this is the last hotfix release and it's perfect now :) Enjoy!

And again, the downloads are here:

Download binaries (32 and 64 bit)

Download source code

Aaaand another hotfix release. This time, these problems were addressed:

+ Fixed bwraps, pre_bwraps and post_bwraps (potential division by zero) - thanks again, Fred!
+ Added localization support for the curves panel
+ Changed the flame and translation loading/saving code to support and use UTF8 encoding
+ Updated german localization
+ Updated italian localization (with the help of the great lindelokse - thanks!)

You can get the updated localizations from The binary/source downloads are here (and also on the homepage):

Download binaries (32 and 64 bit)

Download source code

Oh mai, it seems that Apophysis 7X jumped on some kind of rapid-release schedule :lmao:

You kept reporting problems which I of course want to straighten out. This time, mostly about the newly introduced curves feature. I'm pushing updates on a daily basis - when possible - until they are kind of sorted out. At least the critical ones. Here is hotfix #4!

+ Changed color curves feature to use regular cubic béziér splines. They are weighted internally still but you can't change it from the GUI (which is not really necessary anyway...) ... it's kind of a hack, though, to bring you back the original coloring (not so vibrant and glary) but keep the possibility to adjust the color curves. I want to keep the weights - this is why I didn't remove them but it gives me a bit of time to fixing the maths!
+ Moved the curves window into the adjust window
+ Fixed the plugin loader code AGAIN to have the original list item coloring in the 32 bit version (white for basic built-in, blue for built-in plugin variations and yellow for external plugin variations)
+ Fixed the flame updating code so that changing the preset doesn't get reverted when you click on the curves panel

As always, download here:

Download binaries (32 and 64 bit)

Download source code

Two things changed:

+ Added color curves dialog
+ Fixed plugin recognition routines. Variations, which were already built-in were loaded anyway which lead to an "Access Violation" storm in the editor. Thanks again morphapoph for tracking the origin of the problem in such a masterful way!

The color curves dialog is very simple and straight forward. Works like the one in Photoshop. Or Chaotica. Or GIMP...and it's not perfect. It's a new feature and maybe a bit bugged. But we'll see how much better it gets over time ;)

As always:

Download binaries (32 and 64 bit)

Download source code

An updated version of Apophysis 7X15C is hitting the servers right now. The changes are:

+ Added possibility to specify a custom plugin path for the 32 bit version
+ Fixed bipolar variation (wrong constant used in preparation routine - M_2_PI is not 2 * PI. Thanks, Fred!)
+ Fixed "X"-button next to the search field
+ Fixed a memory leak in the renderer
+ Changed the 32 bit version to use 32 bit-floats (instead of double precision = 64 bit floats) which results in less memory use in the 32 bit version and higher image quality in the 64 bit version
+ Changed Chaotica integration so that 64 bit Chaotica is enforced if 64 bit Apophysis is running

I'm sorry for the update frequency but that's how it is in the first days after a new major release! People are actively tracking bugs and report the results to me. And I fix them and release hotfixes :) Once we - as a community - tracked down all the (not so hidden) bugs, the update frequency will drop to normal again :nod:

As usual, the download links for the latest files:

Download binaries (32 and 64 bit)

Download source code

Attention: I strongly suggest that anyone who updates to 15C uses the script "Reset settings.cmd" by just double clicking it in the Windows Explorer. This will ensure that you have no incompatible settings from old versions of 7X. There a lot of problems including Access Violation rages if something is wrong in your settings. PLEASE PLEASE PLEASE reset them using the script BEFORE you come to me and report bugs. Kay? :)
I have compiled a few hotfixes for the recent 15C release:

+ Fixed the MT renderer - was not properly reading transform opacity values
+ Fixed render log - was showing "32 bit integer" still
+ Changed the default settings so they comply with UAC-enabled systems
+ Fixed loonie variation code - had potential division by zero
+ Added scripting back in 32 bit-version - waiting for TMS to deliver 64 bit-support
+ Added a few one-click helper scripts to simplify things like settings reset and running 7X lite

Download binaries (32 and 64 bit)

Download source code

I get an error about Apophysis7X.rand and/or Apophysis.undo when I start Apophysis
It's a Vista/7-issue which spawned after using Delphi XE2 as the main compiler (since 15C) You have multiple possibilities:
1. Right click the Apophysis shortcut or EXE-file and select "Properties". Go to the "Compatibility" tab and check "Run as administrator". Try again.
2. Copy your Apophysis folder to the desktop (or "My Documents") and try running it from that location.
3. Go to the control panel and disable UAC ("User account control")
A permanent fix is on the way.

I get a crap ton of access violations when I open Apophysis and/or the Editor window
My assumption is that there is an incompatibility in your settings. Reset them the following way:
1. Exit Apo, hold the Windows-Key and hit "R" on your keyboard. Enter "regedit" and hit return.
2. On the left side, browse to "HKEY_CURRENT_USER\Software" and find the folder "Apophysis 7X".
3. Right click that folder and click "Delete".
4. Try again.

My 3D flames look wrong
3D-Flames need tweaking if their particular case slipped through the stack of automatic conversion routines I added to the loading routines. Please manually tweak your flames with the following information:
1. All (!) variations which are built-in are 3D-aware since 15C. That means, they create OR preserve the Z-component of the 3D point (X, Y, Z); so let's say you used spherical on transform 1 and julia3D on transform 2. Before 15C, spherical was not 3D aware. But now it is and your flame will look different because julia3D creates a Z-component and spherical preserves it.  To fix this, add "flatten" to transform 1 (the one with spherical) to delete the Z-component again and restore the old behavior.
2. Linear3D doesn't exist anymore. The community expressed, that two linears were silly and unnecessary. I first removed the old "linear"-variation (the one which was 2D) and renamed the old "linear3D"-variation to "linear". So linear3D is gone AND linear is now 3D by default. If you want the old 2D-linear back, add "flatten" on the same transform to make it 2D.

Okay. But my flame is 2D and it still looks wrong. I used a plugin which got built-in.
I am a human and I might have made an error while porting the plugin. Please send me examples (in picture AND parameter form) to my e-mail at xyrus01(at) and tell me what variations you assume are buggy. I will then try to help you and fix the problem.

While using multithreading (MT set to anything else than "Off"), my flames which have a transform opacity between 0 and 1 look like the opacity was 1.
morphapoph reported to me about this problem and I indeed found a bug in the multithreaded renderer where the opacity is not properly implemented. Unfortunately, you can't do anything about that but it was a problem in previous versions of 7X too. I am fixing that right at the moment, though!

Using non-latin characters or special characters like backslashes, quotation marks et cetera in flame names or file names make Apophysis hang or crash.
With Delphi XE2, Apophysis internally supports Unicode. But the code was not fully updated yet (and it will take some longer) - I wanted to give you a release so you can play with it right now and not let you wait until I finished the entire transistion. Please be patient with me while I update the code to use proper unicode characters. I do not wish to force you to use latin characters. The Apophysis code does that until it got updated.

Apophysis crashes natively ("Do you want to send this problem to Microsoft?") or with a lot of "Access Violations" upon start or during the execution and/or the installer (only available up to 15B as of now) doesn't start ("Not implemented")
Apophysis and a few other programs are incompatible with a product called LiteStep. MindsEye69 pointed out that a similar product called BlackBox causes problems too. Based on this information, I can safely assume that shell replacements or enhancers (such as the Stardock-products WindowBlinds, DesktopX, WindowFX, ObjectDock as well as Aston, Samurize and Cairo) are incompatible with Apophysis. Please check for any of those and try to run Apophysis without those software products before reporting a problem of crash-nature. An exception from this rule would be RainMeter which has been proven to work just fine with Apophysis. But try to disable this as well before contacting me about a crash-related problem.

Anything else? Did I forget a problem you reported? Please let me know and I will add it here!
I have here a preliminary release of Apophysis 7X 15C. The following changes have been made:

+ Added log (from logn - included the variable log(n)_base)
+ Added polar2
+ Added cross
+ Added wedge
+ Added epispiral
+ Added (pre-/post-)bwraps
+ Added blur_circle
+ Added blur_zoom
+ Added blur_pixelize
+ Added (pre-/post-)falloff2
+ Added splits
+ Added separation
+ Added bipolar
+ Added loonie
+ Added escher
+ Added scry
+ Added ngon
+ Added foci
+ Added lazysusan
+ Added mobius (the one with Re_A, Im_A... - variables)
+ Added (pre-/post-)crop
+ Added elliptic
+ Added waves2
+ Added auger
+ Added pre_spherical
+ Added pre_sinusoidal
+ Added pre_disc
+ Added post_curl
+ Removed linear3D (the 3D-linear is now simply called "linear")
+ Changed all variations which were in Apophysis before so that they are 3D-aware. This means that all variations PRESERVE the z-position of their points instead of resetting it to zero like before. Your 3D parameters likely need tweaking HOWEVER I added some code in the loader which should automatically "fix" most of the parameters. BE AWARE THAT PARAMETERS SAVED WITH 7X ARE LIKELY TO BE INCOMPATIBLE WITH THE 3D HACK FROM NOW ON!
+ Added a variation search box in the editor
+ Fixed the multithreaded renderer. It is now safe to enable multithreading in the options. Leave a few threads open, however. If you got a dual-core, leave it at 1; if you got a quad-core, set it to 2-3; and so on.
+ Changed the general buffer depth to 64 bit floating point to improve numeric accurancy and speed (less conversion); MichaelFaber pointed out that this will require more memory for rendering, though. I will consider adding a 32 bit floating point mode for low-end computers.
+ Removed the EXIF-writing for JPEG-renders (couldn't find up-to-date and free library)
+ Temporarily removed scripting support. More info here. It will come back with a hotfix once I got enough donations for the component. I'm at 71 of 95 euros right now.
+ Introduced an experimental 64 bit version with no plugin support (which is why I added so many variations)
+ Fixed the editor toolbar glitch

As you can see from the changelog, one or two hotfixes will appear which bring back scripting and add a few more variations (glynnsim2, flux and circlecrop are in the works)

PLEASE MAKE SURE TO REMOVE ALL OF THE PLUGIN VARIATIONS WHICH ARE IN THE LIST ABOVE! Or you will get a lot of "variation already exists" errors!

Note that the variations (pre-/post-)bwraps2/7, Epispiral (capital E), cross2 and logn automatically translate to their corresponding new built-ins once you load or paste parameters. Note that 3D flames might break and need tweaking.

Important notice about the flatten-variation: the flatten-variation restores the old behavior of non-3D/built-in variations. It zeroes out the z-position so the pattern looks "flat" (like with a variation with no 3D support); use this to restore old flames :)

But for now - you can get Apophysis 7X 15C here:

32 bit Windows (with plugin support)

64 bit Windows (no plugin support)

Source code

You should use the 64 bit version if:
- You don't need plugins and / or can work with the built-in variations
- You want to render very large images (for printing)
- You have 4 GB of RAM or more

Do you have a problem or bug to report? Please read this journal before you do so!
The often requested browse functionality is now implemented as well. You can reach all of the four selection types from the main page:
  • Recent shares: obviously all flames recently shared sorted descending by time. Theoretically, you can load more and more on the browsing page until you are down to the very first share.
  • Similar flames: clicking the red "similar"-tag shows flames which have one or more of the same tags (not owner-tags, "tags" as in "keywords") - the more tags are equal, the higher the result is in order
  • By tag: lists flames with the same keyword
  • By owner: lists flame with the same owner - you can not list flame with no owner (anonymous shares) using this selector

I hope you like this addition. Now go and build a nice flame database for the community to use :)
I just completed the update for the OAuth-module on It is now possible to use your deviantART account to tag your shared fractal flames.

There are some updates to the privacy. These are required to make this work. The deviantART-authentication solution is powered by the sta:sh-API. However, no (!!!) access to your sta:sh is done. All I am getting is your username and symbol (~, =, *, ^ etc) This data - username and symbol - will be stored in a second table in the database. This table stores either your username and symbol from deviantART or your user-ID from Facebook (decimal number of variable length) alongside with a connection identifier (string of 32 hexadecimal characters) and the service you were using to log yourself in. To identify you on, the corresponding connection ID is stored with the flame you share.

So please mind the following if you use Facebook to tag your flames:
  • Your Facebook-ID (decimal number) will be stored
  • Neither your username, your e-mail, your real name, your profile picture nor any other data from your Facebook account will be stored in my database. It all resides on Facebook and will be queried when it's needed to display the website.
  • No write-access to your Facebook profile is done - EVER! I will not post stories on your wall, will not send any of your shares to Facebook nor will I tell Facebook anything about what you were doing on Facebook only knows that you were using at some point in your life. Nothing else.

And the following if you use deviantART to tag your flames:
  • Your deviantART username and your symbol (which denotes your user group) will be stored
  • Neither your deviations, your journals, your profile data ("deviant ID"), tag line, statistics, favorites nor any other information from your deviantART-account will be stored. I just know your name and use the symbol to get your "display name". I use the name to get your avatar as well. I query the avatar on-demand and by using deviantART infrastructure
  • No write access to your sta:sh or your deviantART-account is done - EVER! I will not submit deviations, journals, I will not add favorites or write comments, critiques or forum posts in any way imaginable. Actually, with the infrastructure given, I could never do that anyway.

If you accept that I store the absolute minimum of data from the corresponding account to identify you within then you are free to use the connection-feature ("Log in using...") - if you are concerned about me or the provider storing information about you through your profile then please don't use this feature. The same rule applying in the entire internet does apply here as well: if you want to keep information secret - don't send information to the internet. By using the connection-feature, you are sending information about THAT (and not HOW) you use to the corresponding provider and the information that you have a profile at the corresponding provider (plus where I can find your profile) to me. Nothing more, nothing less.

I just finished the API and it's documentation for my flame sharing web service

It's a simple HTTP-based interface which can be accessed by any language or framework which offers a HTTP-client. You can interact with the database as well as browsing it. You can find the detailed documentation at