Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - rizer
Pages: [1]

General Discussion / Re: iOS pixel art app
« on: July 03, 2018, 06:08:19 pm »
Hi Shawn, sorry Iíve only just seen this. Are you still having issues with Pixaki? Thatís very strange, Iím not sure what could be happening (especially odd that the screen is white as the launch image for the app is dark gray). If youíre able to send crash reports to that would be amazing and Iíll do what I can to get it fixed. Thanks, Luke.

General Discussion / Re: iOS pixel art app
« on: April 02, 2018, 09:30:39 am »
There's actually a free trial of Pixaki so you can give it a go and decide for yourself if it's worth the money:

Other options for pixel art on an iPad are things like Pixen and Pixure. I've heard of some people configuring Pixelmator or Procreate to do pixel art. I haven't tried it myself so I'm not sure how well it works, but it might be worth a go as those two apps are great anyway ó there's no animation support though.


Luke (developer of Pixaki  :))

Pixel Art / [WIP] Old mouse character
« on: January 09, 2017, 11:01:38 pm »
Here's a quick doodle I did just for some practice:

I started off with just drawing random lines on a page, which ended up looking a little bit like a mouse's head and went from there. If it's not clear, it's supposed to be an old mouse in a ragged cloak wearing a scarf, with both of his hands on top of a cane. The hands were one of the trickiest bits.

I'd like to improve the shading whilst not increasing the colour count (I'm using the EDG32 palette, or some of it at least). I think there's definitely scope for making the subject more obvious, but I'm not sure how to proceed. Any feedback would be greatly appreciated.



Devlogs & Projects / Re: Pixaki
« on: June 07, 2016, 02:05:09 pm »
Thank @Ai  :) Yeah, I came across median cut when I was reading about colour quantisation  ó could be useful if I ever want to create a palette from an image.

I have some more user interface questions if anyone would like to help:

Firstly, with an indexed colour palette, what should happen if the user deletes a colour from the palette? Aseprite shifts all subsequent colours back and recolours the artwork so that the new indexes match, but I think that would be really confusing in Pixaki. The other options I thought of were to erase all pixels of the deleted colour, or to not allow the colour to be deleted if it's in use. Any thoughts?

My second question is to do with blend modes for layers. Would they be useful or is it not a high priority for most people?


Devlogs & Projects / Re: Pixaki
« on: June 04, 2016, 01:31:37 pm »
Thought I'd quickly implement the Delta-E 76 algorithm to see what the results are:

Certainly closer to my previous results than to GIMP's. I would guess that GIMP is doing some sort of smoothing, which is probably desirable for photos, but less so for pixel art.

Devlogs & Projects / Re: Pixaki
« on: June 04, 2016, 01:23:12 pm »
Thanks @Ai ó those images seem to be working fine. Yeah, I agree it's good to test results with images that are closer to what people are likely to be using. Here are my results with the image you posted:

It's certainly different. Do you think the GIMP results are better? I wonder whether they're either using a different Delta-E algorithm, or performing some other steps (or maybe both).


Devlogs & Projects / Re: Pixaki
« on: June 02, 2016, 05:45:38 pm »
And here are some results…

Original on the left, quantised to the Android Arts palette on the right.

Full size original | Full size quantised

It's pretty slow at the moment, particularly for such a large image, but the results seem good to me. Any thoughts?

A couple of sites that have been really useful for this are ColorMine and EasyRGB if anyone's interested in this sort of thing (and Wikipedia of course!).

Devlogs & Projects / Re: Pixaki
« on: June 02, 2016, 10:28:40 am »
That's a lot of options!

Thanks for the feedback, especially @Ai for pointing me to Delta-E  ;D

I've been busy writing the code over the last couple of days, and I've just finished my Delta-E implementation, which seems to be working. I went with the '94 formula, which seems to be a nice middle ground between accuracy and speed. Quantising an image is my next stepÖ maybe I'll post in the results.

@32 The shift in colours for the onion skin sounds like a good idea, and shouldn't be too hard to implement.

Thanks everyone!

Devlogs & Projects / Re: Pixaki
« on: May 30, 2016, 10:34:25 am »
Wow, amazing, thanks so much everyone! This is a real treasure trove  :)

So putting everything together, here's what I'm thinking I'll do:

Keep layer opacity as an option, just like in RGBA mode. If you choose to export the document and you have layers with semi-transparency, then you'll just get an image with more colours than you have in your palette ó I don't think I need to tell the user that they've done this, I think it should be pretty obvious.

If you select to merge a layer at 100% or 0% opacity, it will just merge down (the latter will just delete the layer).

If you select to merge a layer with any other opacity, you'll be presented with some sort of dialogue asking if you'd like to add the colours to the palette or quantise to existing colours.

Onion skinning will be available if you have more than one frame of animation.

Which leads me on to a few more questions:

  • Does anyone have any thoughts on how the colour quantisation algorithm should work? My first thought was maybe to calculate the difference in hue, saturation, and brightness for each colour in the palette and the target colour, then take the palette colour with the smallest ΔH + ΔS + ΔB?

  • I'm planning to allow the user to be able to import a palette from a list of palettes. If the current document palette has more colours than the imported palette, I thought it would be best to append the extra colours. So if you were working with a palette that was [#9CBD0F, #8CAD0F, #306230] and you import [#CC0000, #00CC00], you'd end up with [#CC0000, #00CC00, #306230]. I guess I could quantise, but it seems like it would be more annoying to lose colour distinctions in the document without being very explicit about doing so. I'm planning some sort of interactive colour merge feature too, so you could just merge the new colours if you didn't want them. What do you think?

  • With regards to onion skinning, what options would you want to see there? My current plan is that I'll show the frame in front and the frame behind (which will loop if you're on the first or last frame), and have a single opacity option that will change the opacity of both frame previews. I know there's lots more I could do, but would this cover what most people would be happy with?

Thanks again!

Devlogs & Projects / Pixaki
« on: May 27, 2016, 10:30:23 am »
Hi, I'm the creator of a pixel art app called Pixaki. I'm working on a new version, and I have some questions about how things in the app should behave, so I thought "those Pixelation people seem nice, and clearly know a lot about pixel art, maybe I should ask them"  :)

A big new change I'm making is the option to have indexed colour mode documents. The app supports layers, and at the moment it's possible to adjust the opacity of a layer, and then merge it down, which obviously has the potential to produce a whole load more colours. So I thought that maybe in indexed colour mode there should be no semi-transparency in the layers or the selected colours, but in RGBA mode people can do what they like. Does that make sense? Would it be annoying to not be able to adjust a layer's opacity when working with indexed colours, or is that what you'd expect?

I'd love to hear what you think. Thanks for your time,


Pages: [1]