Hey im just wondering since photoshop brushes is a secret. How come artstudio pro can import .abr brushes perfectly without needing any adjustment?
I can’t remember which thread had talked about something like this, “.psd or .abr files can be opened in other proprietary painting software but not krita”. The answer is like, other software support the format have to pay Adobe for the code, and since Krita is under GPLv3 license, anyone can port krita’s code under GPL, it will be not accept by Adobe.
For now krita support for photoshop format are by reverse engineering, so it may not be full function as in other software.
Correct me if I’m wrong 
Cause i know procreate and csp say they can import .abr, but its the same thing, its not that good and need to adjust as well.
So maybe artstudio pay Adobe?
The brush engine in procreate and csp may work differently with photoshop, so they need some tweak to work the same.
Though these are just guessing.
I don’t know much about the license terms in the background. But I do know that Krita can only use the brush tips from an ABR file, so you have to assign them to an appropriate preset and set it up to replicate that brush’s settings in Krita. But that doesn’t bother me, as Krita’s brush engine is overall more versatile and powerful than Adobe’s. You “just” have to solve the “puzzle” of the chosen settings of the original brush. 
Michelist
Im not complaining about how krita import.abr brushes. I already liking all the free quality brushes from Ramon and others. Im only curious of how artstudio pro can achieve perfect or almost perfect translation of abr while other art apps cant. I also have a hundreds of kyle T. famous abr brushes and also there are lots of textures or any accessories brushes that i would like to have but im not going to tweak each one of those haha… but yea this topic only asking how artstudio can achieve that, while others cant.
That’s an easy answer @Lesqwe56 has already given: Money. They paid for it, would then be the more likely of the possibilities, because it takes time and therefore also money to unlock something like that via re-engineering and then implement that, and you don’t know if the time you’re investing is going to get to the goal, so payment is the more likely of the two possibilities.
Michelist
1 Like
I am not saying you should but … you can hack open the ABR files (if they are old enough) for the texture and then just mimic the engine behaviour by hand.
ABR files are but just a texture and some number values for the engine that are locked. Getting the texture is more than half way there.
Even it is a little off-topic, we’re still at ABR’s…
Until now, I was able to extract any ABR-Files brush-tip, the ABR-Files from newer CS can be opened with abrMate the older ones also with other tools like abrView.net or a script you can find on GitHub is said to be able to this too.
Michelist
So, the actual problem with ABR is that it is an undocumented binary format. Binary formats, unlike XML (which Krita uses 90% of the time), or stuff like JSON, is a file filled with nothing but values, and you have to manually figure out which values belong with which bit of data. For example, this is how a vector mask looks like in PSD:
When we program in support for a feature in a binary format like PSD, we need to look at the existing documentation to start with, then we also need a whole bunch of test files to check against, because the PSD documentation is filled with flaws and errors.
With an undocumented binary format, like ABR, it gets even harder, because you then need to reverse engineer it. This involves comparing a whole lot of files, and then sorta seeing where they differ and trying to guess from the patterns whether you are looking at a color, or a curve or a toggle. For example, all PSD blocks end with 8BIM (which is either 34 42 49 4D or 4D 49 42 34 depending on the computer it was saved with), so maybe something like ABR has the same thing going on. This is probably what the artstudio pro developers did.
Furthermore, after figuring out which value is what, you also need to figure out how exactly all the little numbers create a brush preset. Maybe the numbers are stored in percentages, or maybe the size is actually in ‘radius’ instead of ‘diameter’, so that too needs a ton of test files.
Here’s some very clear examples of reversed-engineered palette formats. For ASE for example, my code would look something like this:
QBuffer buf(&data);
buf.open(QBuffer::ReadOnly);
QByteArray signature;
signature = buf.read(4);
if (signature != "ASEF") {
return false;
}
Where I load the first 4 bytes (that’s the little blocks of numbers on the left), and check if I can read them as text, and whether the text spells out “ASEF”, if not, I have to break off loading, because the file is incorrect.
Developers are usually a bit hesitant to support binary file formats that haven’t got a proper standard or documentation (for example, most image formats are binary, but PNG and JPEG have standards documents that has been assembled and reviewed by a ton of programmers and has example code), because it can take a ton of work to get the data out, saving is even scarier: If you make a mistake with the order of the bytes, you end up with a corrupted file that cannot be reopened anymore.
(This is also why hard drive failures corrupt files, the hard drive starts making mistakes as its components deteriorate, jumbling up the bytes when it’s writing or reading files)
Because time is scarce, there’s a good chance a dev might rather want to spend it on something else, like adding a new feature, speed improvements, or fixing bugs. I hope this helps getting an idea of the kind of challenges we face when dealing with binary formats.
10 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.