'16-'17 General Discussion for Lesson 2.4


Those questions about color range are from the video guide and I’ll admit they’re a little weird.

Can RGB values be any other range besides 0-255?

You could answer two ways:

  • No. On modern computers RGB values are expressed as one byte per color channel (0-255). End of story.

  • Sure, the could be another range as long as computers supported it. You could assign an arbitrary number of bits to each color channel. As long as the protocol/format is well defined then the image could be rendered. (There is probably a physical limit to how many gradations of light intensity can be produced in hardware. So if you went nuts and said each color channel could have 32-bit settings (~4 billion values) it might not be physically possible to make a screen do that.

This ^^^ is sort of an answer to what happens if you increase the range too. But the answer shown above is what I would expect. There are two things to consider though. 1) yes, you can increase the number of colors you can represent, but 2) you also dramatically increase the file size. Consider: every bit you add to the definition of each color channel adds 3 bits to the definition of each pixel. So for, say, an 800x600 image (small by today’s standards) every bit you add to the color channel definition results in an increase of (800 x 600 x 3) bits == 180 kilobytes. So that’s a consequence as well.


Thanks! This is better than my explanation. I told them the increase in bits per pixel and didn’t elaborate.


I have a question on the questions in the Rubric. #2 Reads as this:
Your classmate claims, “Switching my favicon from binary mode to hexadecimal mode is be an example of compression”. Do you agree with classmate? Justify your response.

I am probably missing it somewhere but I have not found an “answer key” to this, so my guess is that the answer is that it is a form of compression because the hex would need less characters to represent a value than say decimal or binary format. For example, if you wanted to send the number “255” if you sent it as a decimal number then you would be sending 3 characters. If you sent it as a binary value it would be “11111111”, but as a hexadecimal value it would be “FF”. Now, where I am not sure is are we really sending this value as “FF”? Or, since it is at some point going to be interpreted in binary are we sending “11111111”? Help…


@stephen_p_sell In the lesson plan they say it is NOT compression because the binary representation underneath uses the same number of bits - you still use 8 bits to send FF.


Ok thanks - should have read that.


Is there a key to the Hexadecimal Numbers (optional) - Activity Guide?


Can anyone explain why the bumble bee turns in to 2 purple/pink bees when the widget is changed from 12 bits to 24 bits (bubble #7)?? I understand what it’s doing but I’m having a hard time putting in to words to explain to the students.


The image doubles anytime you double the number of bits from the original image, however the color will be altered.


This is probably the most unexpected finding we had when making this widget. It is a bizarre effect, and non-intuitive at first, at least for me. Here is my attempt to understand it.

First, I wanted to see what was happening with the bits themselves. I used a simple example of a 4x4 image assuming 12-bits per pixel. When you change this to 24-bits per pixel the total number of bits remains constant, but every pair of 12 bits gets “smooshed” together to make a new 24-bit pixel.

Next I wanted to understand why the image appears to double. There are two issues that are WEIRD. 1) why does the shape of the image stay the same, only smaller…and there are two of them? 2) What’s going on with the colors?

Here’s a little experiment I did with a B&W image:

  1. For the geometry you can see how each row from the original, once smooshed, becomes half a row of the new image. Because it’s exactly half, you effectively get two copies of the original geometry, side by side, where the geometry of the LEFT half is sort like every even row from the original and and the RIGHT half is made from every odd row.

  2. For the color, in my example above you can see what happens. I used a black and white image with 12-bit colors of “FFF” and “000” only. If you smoosh two of these 12-bit sequences together the possibilities are:

  • “000000” - black
  • “FFFFFF” - white
  • “000FFF” - blue (…ish. Blue is full intensity and there is a very small amount of green)
  • “FFF000” - yellow (…ish, Red is full intensity, and there is a lot of Green as well)

In my example above, yellow is not possible because a white cell never precedes a black one. So you only get blue. Here is another example where yellow shows up. You really have to squint to see geometry preserved, but it is.

I wish I could make an animation that would show this interleaving effect - how each row from the original becomes half a row in the new one once the pixels have been smooshed together:

I’m not sure I’ve made this clear to anyone but myself. But it was fun to make the diagrams!

CSP Team



I don’t think an answer key currently exists for that activity.



In the Favicon Activity Guide it mentions that “You will be using this favicon in future lessons and web sites that you make, so be creative and thoughtful.” Can anyone tell me when this might come up later in the curriculum. This is my first year with the curriculum and I am curious about what is coming.


Hi @fallone,

The favicon is a fun activity for students to create cool images but you are right that it is not used later in the curriculum. We have changed the language on the activity guide to clarify. Thanks sharing your question here!



This was my attempt to draw a house. I think the issues that my students may have will be relates to ensuring that they have used the correct height and width for their image as well as understanding that the number of bits used is part of the metadata; and choose the number of pixel is the same as determining how may bits is needed to color 1 cell/square.