[library] Artal, work directly with .PSD files.

[Evine]

Loading .PSD files into LÖVE. Something that should be a simple problem solved in all game engines. Now I've fixed that though and as far as I'm aware, LÖVE is now the first open-source game engine that is capable of loading .PSD files directly.

The library only uses pure LuaJit, No external libraries. And it's as fast as Photoshop at loading files.

Library, Sample code and documentation is available on Github with MIT licence.
https://github.com/EvineDev/Artal
All of these libraries can be used independently.
- artal.lua is the core psd loading library.
- psdShader.lua is a small shader generator/ rendering library to render blendmodes/clipping layers.
- writetable.lua is a library to write tables. For debugging convenience.

psdShader.lua is very much incomplete. So you'll probably quickly run into problems rendering images accurately if you use a lot of blendmodes / clipping layers and folders in combination. This is just a very complex problem and I don't think I'll ever work on making a perfect system, as having a ton of complex layers will hurt performance anyway. But if anyone interested in contributing code I'd appreciate pull requests.

I'd advise only to use blendmodes outside of folders. Clipping layers with/without blendmodes should be baked into the texture it's clipped to.

Paint Tool Sai


LÖVE

[Sulunia]

Whoa dude. That looks awesome!

[pgimeno]

Great work.

[modog]

Nice work, very nice!

[mikeisinlove]

Good god that's insane, I've been working on drawing tools in love recently but this is incredibly dope.

[s-ol]

Using this right now to speed up design iterations in a small timeboxed project (autoreloading animation sheets straight from PSD file)
I thought I had to change something in the code (DAMN is it messy) but it turns out all I needed was already there I just didn't quite understand the docs. Submitted a PR to make it more clear for other people in my shoes.

I might release my autoreload thing as a library later on if it keeps being useful and I add a few features like a release export-to-png.

[Evine]

Glad to see it being used, and thanks for the feedback. At this point I'm completely blind to what makes sense or not in the documentation as I've simply worked with PSD files to much. So if there's anything you're curious about PSD files in general / my implementation feel free to ask in here.
There's a lot of things in the format I parse but don't expose in any way, simply because I want the library to be as simple as possible. There's also a ton of things I don't parse that could be nice to have access to. (Text strings and fonts in text layers, vector data, etc.)

The code is messier than I'd like because I started coding it in a experimental way, which I backtracked on after a while. So the code is in this limbo between two coding styles, PSD file format is also just extremely unnecessarily complicated.
If you want to read the code. I'd recommend loading up the adobe documentation and read it alongside the code. I parse the "Header", "Layer and Mask Information" and "Image data" sections. (And trust the code more than the documentation.)
http://www.adobe.com/devnet-apps/photos ... matashtml/
(My favourite is how the image data is slightly differently encoded between the composite "image-data" section and the "layer-data" section. Even though the documentation for them is the same and correct in both cases. )

Things I'd like to get done, and I hopefully will do some time:
- Better "Flatting" support. Right now it's difficult/impossible to compose images with complex structure. Folders, blend modes and clipping layers all mess with how the image should be composed.
- Shader implementation documentation. (It's complicated and simple at the same time)

And finally. Bad documentation is equally as much of an issue as raw code bugs. So do file an issue on Github if you feel you misunderstand something.

[s-ol]

Glad to see it being used, and thanks for the feedback. At this point I'm completely blind to what makes sense or not in the documentation as I've simply worked with PSD files to much. So if there's anything you're curious about PSD files in general / my implementation feel free to ask in here.
There's a lot of things in the format I parse but don't expose in any way, simply because I want the library to be as simple as possible. There's also a ton of things I don't parse that could be nice to have access to. (Text strings and fonts in text layers, vector data, etc.)

The code is messier than I'd like because I started coding it in a experimental way, which I backtracked on after a while. So the code is in this limbo between two coding styles, PSD file format is also just extremely unnecessarily complicated.
If you want to read the code. I'd recommend loading up the adobe documentation and read it alongside the code. I parse the "Header", "Layer and Mask Information" and "Image data" sections. (And trust the code more than the documentation.)
http://www.adobe.com/devnet-apps/photos ... matashtml/
(My favourite is how the image data is slightly differently encoded between the composite "image-data" section and the "layer-data" section. Even though the documentation for them is the same and correct in both cases. )

Things I'd like to get done, and I hopefully will do some time:
- Better "Flatting" support. Right now it's difficult/impossible to compose images with complex structure. Folders, blend modes and clipping layers all mess with how the image should be composed.
- Shader implementation documentation. (It's complicated and simple at the same time)

And finally. Bad documentation is equally as much of an issue as raw code bugs. So do file an issue on Github if you feel you misunderstand something.

I understood the code, what I found messy was how the ink and inkName methods save values on call when they could just return them and you could keep the scope much smaller like that and why it is one huge procedural chunk when you could clean it up a lot with different functions like parseLayer() that you call iteratively.

A feature that is easily implemented on the user side but should be available in the lib IMO is proper layer/group hierarchy.

Access to Vector information is something I would very much like to see, I want to (ab)use photoshop as a level editor for a point and click game and that would make a lot of things a lot easier.

[Evine]

ink and inkName methods save values on call when they could just return them.

Yup, the reason it became like that was that I wanted to make sure I didn't override previously set variables. But that might have been better achieved by doing some meta-table magic.

Why it is one huge procedural chunk when you could clean it up a lot with different functions like parseLayer() that you call iteratively.

Because a big procedural chunk is cleaner.

Access to Vector information is something I would very much like to see, I want to (ab)use photoshop as a level editor for a point and click game and that would make a lot of things a lot easier.

My personal plan was to make bitmap collision system, so you could just blop out the map with a simple brush. I don't know when/if I'll get to parsing the vector section.

A feature that is easily implemented on the user side but should be available in the lib IMO is proper layer/group hierarchy.

I have some code for this, but honestly I don't find it that useful in practice. I'll throw it into the documentation as a sample.

Code: Select all

function folderHierarchyAsTable(psdTable)
	local resultTable = {width = psdTable.width, height = psdTable.height}

	local recursivePosition = {}
	local recursiveTable = {}
	local POS = 1
	local currentTable = resultTable

	for i = 1, #psdTable do
		if psdTable[i].type == "open" then

			currentTable[POS] = {}
			for k, v in pairs(psdTable[i]) do
				currentTable[POS][k] = v
			end
			--print("open",POS)
			table.insert(recursiveTable, currentTable)
			table.insert(recursivePosition, POS)
			currentTable = currentTable[POS]
			POS = 0

		elseif psdTable[i].type == "close" then
			--print("close",POS)
			
			POS = recursivePosition[#recursivePosition]
			currentTable = recursiveTable[#recursiveTable]
			table.remove(recursivePosition)
			table.remove(recursiveTable)

		else
			--print("image",POS)
			currentTable[POS] = {}
			for k, v in pairs(psdTable[i]) do
				currentTable[POS][k] = v
			end
		end

		POS = POS + 1
	end

	return resultTable
end

[s-ol]

I figured out path loading, but while the code doesn't fit the rest of artal and is a bit hacked-in I would want to rewrite it completely which I dont have the time for right now. I attached the new artal.lua with DOS line endings so you can diff them easily, but you really should have unix line endings if you put it in a git repo.