7
\$\begingroup\$

Given a hue between 0° and 360°, generate an image file or display an image of an HSV (hue-saturation-value) color picker square for that hue, e.g. for the input 123:

HSV color picker square for the hue 123°

The output must be a square at least 256 pixels on a side with saturation varying from 0.0% to 100.0% left-to-right and value varying from 100.0% to 0.0% top-to-bottom. Each pixel should be a unique color, but rounding errors causing adjacent pixels to be equal are allowed.

Input

The input will be a single integer between 0 and 360 inclusive representing the hue in degrees.

Output

  • The output must either be displayed on the screen or written to a file or stdout in a common image file format.

  • Entries must include an example image file (converted to an SE-friendly format if necessary), screenshot, or snippet (for HTML/CSS/JavaScript entries).

  • Output using a lossy file format will necessarily have compression artifacts that may affect the uniqueness or order of the pixels. This is allowed.

Rules

Improve this question
\$\endgroup\$
5
  • \$\begingroup\$ Sandbox. \$\endgroup\$ Commented 20 hours ago
  • \$\begingroup\$ @Rhaixer Yeah, good catch. \$\endgroup\$ Commented 15 hours ago
  • \$\begingroup\$ Tcl/Tk has a very high chance to be on the shortest code posts for this challenge. \$\endgroup\$ Commented 13 hours ago
  • \$\begingroup\$ PNG is not "a lossy file format" \$\endgroup\$ Commented 9 hours ago
  • \$\begingroup\$ I think a lossy output should identify how much lossy it is. E.g. How many pixels are inexact, and the maximum color difference. Otherwise I can exploit the rule by making an all-white, 100%-except-one-pixel lossy image. \$\endgroup\$ Commented 1 hour ago

7 Answers 7

Reset to default
4
\$\begingroup\$

Desmos 3D, 19 (+ \$\log_{256}(7\times2)\approx 0.475919\$) bytes

n=0
a=hsv(n,x,z
y=0

Input into \$n\$. Requires you to set the colour of the equation \$y=0\$ to the defined custom colour, as well as tick the Extend to 3D option, for an extra \$\log_{256}(7\times2)\approx 0.475919\$ bytes. The square is defined by \$0\leq x\leq 1,0\leq z\leq 1\$.

Try it here!

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ @Rhaixer fixed now, whoops \$\endgroup\$ Commented 17 hours ago
  • \$\begingroup\$ why is ticking the Extend to 3D option equal to log256(7x2) bytes? obviously it makes sense that using a tool external to the code must be accounted for in the byte count, but i don't understand why specifically this number is the penalty \$\endgroup\$ Commented 1 hour ago
3
\$\begingroup\$

Scratch, 258 247 bytes

Highly suboptimal...

Try it here

define x(i
go to x:(-50)y:(-90
set pen(color v)to((i)/(3.6
set pen(brightness v)to(
repeat(256
set pen(saturation v)to(
repeat(256
pen down
pen up
[saturation
move(1)steps
end
set x to(-50
change y by(1
[brightness
define(c
change pen(c)by(.390625

code

For a bit of interactivity I customized it so that moving the cursor will redraw a new square, taking the normalized x-coordinate of the cursor as the input. Here is an example output, \$i=360°\$: img

Improve this answer
\$\endgroup\$
3
\$\begingroup\$

R, 74 bytes

\(h)image(matrix(1:1e6,1e3),c=outer(j<-0:999/999,j,hsv,h=h/360),ax=F,as=1)

Try it at rdrr.io

Improve this answer
\$\endgroup\$
3
\$\begingroup\$

Wolfram Language (Mathematica), 48 bytes

Image@Table[Hue[2#/a,j/a,1-i/a],{i,a=6!},{j,a}]&

Creates a 720x720 image using the Hue[h,s,b] builtin that expects its arguments (hue, saturation, and brightness in that order) normalized from 0 to 1. Some good fortune that 6!=720 is both shorter to code than 256 and also twice the 360 needed to normalize the hue argument. (Although I guess replacing 6! by 360 removes the need for the 2 and so yields the same code length.)

Improve this answer
\$\endgroup\$
3
\$\begingroup\$

JavaScript (ES6), 190 bytes

Generates a <canvas> of 256×256 pixels and fills it by converting from HSV to HSL. Most probably not the shortest approach.

h=>{for(i=!document.write`<canvas id=c height=256>`<<16;i--;a.fillRect(x=i%256,y=i>>8,1,1,a.fillStyle=`hsl(${h} ${v=1-y/255,v-=l=v-v*x/510,v/(l<.5?l:1-l)*100} ${l*100})`))a=c.getContext`2d`}

(Don't) Try it online!

Graphical output

f=
h=>{for(i=!document.write`<canvas id=c height=256>`<<16;i--;a.fillRect(x=i%256,y=i>>8,1,1,a.fillStyle=`hsl(${h} ${v=1-y/255,v-=l=v-v*x/510,v/(l<.5?l:1-l)*100} ${l*100})`))a=c.getContext`2d`}

document.write = _ => undefined; f(123)
<div style="float:left"><input type="range" min="0" max="360" value="123" style="writing-mode:vertical-lr;direction:rtl" oninput="f(this.value)" /></div><canvas id=c height=256>

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

R, 98 bytes

\(n)image(matrix(seq(m<-outer(k<-0:255/255,k,Vectorize(\(a,b)hsv(n/360,a,b)))),256),c=m,ax=F,as=1)

Draw it on rdrr.io!
check byte count

Improve this answer
\$\endgroup\$
1
  • 1
    \$\begingroup\$ I wrote mine independently while on a plane, but it came out pretty similar... \$\endgroup\$ Commented 13 hours ago
1
\$\begingroup\$

CSS, 102 bytes

div{--h:123;width:256px;height:256px;
background:linear-gradient(0,#000,transparent),hwb(var(--h)0 0)linear-gradient(90deg,#fff,transparent)
}
<div id=o></div><input type=number value=123 min=0 max=359 oninput=o.style.setProperty("--h",this.value);

The work is done by the second line of CSS in the snippet; the rest of the CSS makes the image visible and gives the input a default value for convenience; the HTML allows you to change the input's value. (Since CSS can't read input in any other way, I assume using a variable is legal.)

Improve this answer
\$\endgroup\$
1
  • 1
    \$\begingroup\$ I'm not sure if the dimensions should be included in the byte count. Either way, you can rearrange it further to get down to 82 bytes: background:linear-gradient(#0000,#000),linear-gradient(90deg,#fff,hwb(var(--h)0 0)) \$\endgroup\$ Commented 2 hours ago

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.