@linlux

I still have my old code for the bitmap reading.
If you're interested, I could provide you with it.

But doing trying to do that on your own first, should be better.

@linlux:

I did not solve it the same way.
But it's not hard to come to this solution when you understand binary and are familiar with shifting / logical operations.
It's not something you see often in Java but more in something like C or C++.
If you want to come up with solutions like that, you should try projects like reading an RLE encoded bitmap and manipulate it in C.

You can start with https://msdn.microsoft.com/en-us/library/windows/desktop/dd183392(v=vs.85).aspx

If you have any questions, feel free to contact me.
When I did something like that, it had support for 8 bit and 24 bit Bitmaps and RLE8 encoded only.
The reading and saving are about 300 - 350 lines of code.

Things you should utilize in a project like that:

• File operations
• Structs (typedef in headerfiles)
• Length of variables and when to use signed / unsigned (int, short, char, etc.)
• Macros
• Pointers
• Shifting (mainly when you want to get / set the color of a RGB pixel https://msdn.microsoft.com/en-us/library/windows/desktop/dd162939(v=vs.85).aspx)

You could start with something simple like calculating how often each color occurs.

If that project would be too big for you, you could also go for short bit manipulating methods.
Like writing a method that is doing a Circular Shift https://en.wikipedia.org/wiki/Circular_shift

Or write something that is doing a Circular Shift on 2 bits that run in opposite directions like this:
100000001
010000010
001000100
000101000
000010000
000101000
001000100
010000010
100000001
100000001
010000010
...
// ignore that i accidentally used 9 bits ...
Print an ascii character at the position where the 1's are and enjoy how they are moving around.

TIL: you can't reply to a reply on codewars ..

@linlux:

The bits get shifted to the left.
take for example the binary number: 1000 (8)
In the first iteration, you get:    0001

The loop runs as many times as
there are digits.
Take away the first iteration cause
there is nothing shifted
And you end up with 3 more shifts:  1000
Every digit that is added at the
right most position is shifted by
the remaining amount of loop iterations

If you use a TreeSet, why do you check if the String is allready in the TreeSet before adding it?