Computing desk
< June 3	<< May \| June \| Jul >>	Current desk >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is a transcluded archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

June 4

Challenge

Challenge: can anyone make the following image smaller than 724 bytes and still be a valid PNG file?
(Used on User:Example#Example image.)

How small can you make it using JPG, GIF, or any other format?
--Guy Macon (talk) 04:52, 4 June 2020 (UTC)[reply]

"Any other format" opened up for me the fun puzzle of "describe these color bars as tersely as possible." Is there a file format, somehow solely in love with rectangles, whose only data is (x1, y1), (x2, y2) (color)? --jpgordon^{𝄢𝄆 𝄐𝄇} 06:53, 4 June 2020 (UTC)[reply]

Jpgordon, there should be no reason you couldn't SVG this and make it very tiny. I don't know what that format's overhead is, but yeah, its contents would basically be what you describe. Elizium23 (talk) 07:20, 4 June 2020 (UTC)[reply]

It has 22 rectangles, and you have 32 bytes to define each one. (33 would make it 2 bytes bigger than the existing PNG.)

You can define an X/Y inside of 500X500 image with 18 bits. I would be happy with 256x256, 512x512, or any other size if the byte count was lower, so lets assume each rectangle gets 1 byte to define the X and one byte to define the Y of one corner and 2 bytes for the opposite corner. 4 bytes x 22 rectangles = 88 bytes to define the rectangles. (176 bytes if the format makes you define 4 corners instead of 2).

If you use 2 bytes for each of the RGB colors that's 6 x 22 = 132 bytes. Or would 1 byte per color be enough? those blacks are pretty close to each other...

132 + 88 bytes = 220 bytes, so in theory you could define a 256x256 version using 70% fewer bytes than the 724 bytes I used for the PNG.

Note: by law every online computation must have at least one stupid math error and two typos, so check those numbers yourself. --Guy Macon (talk) 08:15, 4 June 2020 (UTC)[reply]

Here is an example svg rectangle from [ https://www.w3schools.com/graphics/svg_rect.asp ]:

 <svg width="400" height="110">
   <rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)" />
 </svg>

Here is an example svg rectangle from [ http://tutorials.jenkov.com/svg/rect-element.html ]:

 <svg xmlns="http://www.w3.org/2000/svg"
      xmlns:xlink="http://www.w3.org/1999/xlink">
 
     <rect x="10" y="10" height="100" width="100"
         style="stroke:#006600; fill: #00cc00"/>
 
 </svg>

So that answers my color depth question: 1 byte per color, not 2.

Alas, that looks like it will never meet the 32 byte minimum.

--Guy Macon (talk) 08:32, 4 June 2020 (UTC)[reply]

Here it is in EPS format (713 bytes):

%!PS-Adobe-3.0 EPSF-3.0
%%BoundingBox 0 0 12 12
/q{def}def/a{bind q}bind q/b{3{255 div 3 1 roll}repeat setrgbcolor}a/c{19 19 19 
b}a/d{r r r b}a/e{r r 0 b}a/f{0 r r b}a/g{0 r 0 b}a/h{r 0 r b}a/i{r 0 0 b}a/j{0 
0 r b}a/k{0 33 78 b}a/l{1 setgray}a/m{50 0 106 b}a/n{9 9 9 b}a/o{21 21 21 b}a/p 
12 7 div q/r 192 q/s 15 7 div q/t 12 21 div q/A{moveto}a/B{lineto}a/G{p 
D}q/F{translate}q/C{B closepath fill}a/D{0 F}a/E{grestore 0 exch F gsave}a/w{0 
0 A p 0 B p 8 B 0 8 C}a/x{0 0 A p 0 B p 1 B 0 1 C}a/y{0 0 A s 0 B s 3 B 0 3 
C}a/z{0 0 A t 0 B t 3 B 0 3 C} a c 0 0 A 12 0 B 12 12 B 0 12 C
gsave k y s D l y s D m y s D s D n z t D t D o z
3 E i x G G h x G G f x G G d x 
1 E d w G e w G f w G g w G h w G i w G j w 
showpage

I made it 12 by 12 points, as EPS doesn't use pixels anyway. PiusImpavidus (talk) 11:02, 4 June 2020 (UTC)[reply]

It's a little bit of a cheat - but ... I mean, it's not really a cheat - there's a lot of really well-known theory behind self-compressibility, and a lot of quibbling about whether or not the size of the required interpreter has to count against the size of the compressed data stream,...

...but because you've asked for a very standard image, it can be compressed into a simple command to the display- or camera- hardware that generates the image.

For example, most OmniVision Image Sensors contain logic to produce this image using only a few bytes. The magic bytes, 0x70 0x80 yield the colorbar output, at least on the OVT7670. (Other models have other magic-byte sequences).

So - we can encode the SMTPE color bars in just two bytes - as long as we have the right hardware to read those bytes!

And if you're unsatisfied with the amount of compression, all we have to do is compare the size of the digital-logic-device that can run the executable program that decompresses the SVG or PNG or JPG file, and contrast the size of the digital-logic-device on the image-sensor die that is capable of interpreting the two bytes of image sensor control registers... one is, of course, a general-purpose scheme, and the other is a special-case - but that kind of generality wasn't a criteria in our OP's original statement, which specifically used the phrase "any other format" !

I'd be remiss if we didn't direct our readers to our general articles on the mathematics of lossless compression and its limitations...

Nimur (talk) 17:18, 4 June 2020 (UTC)[reply]

Yorkshireman #1:[1] Two bytes? I WISH we had two bytes! When I was a child we used a one bit configuration file to tell the generator whether to generate the image.

Yorkshireman #2: One bit? You were lucky! We had to autostart the image generator, look for a configuration file, and run it if it was zero bytes long.

Yorkshireman #3: Our autorunning image generator would exit if the configuration file existed and would generate it only if it was missing. But we were happy.

Yorkshireman #4: (Pauses) Right then. We had to go back in time look to see if the configuration file ever existed, and if it didn't, generate an image with a size of negative 765 bytes in negative 4.3 seconds using only a system with negative RAM and a negative clock speed. But try to tell the younger generation that. They won't believe you!

Enough silliness. I want an image, of any size but 500x500 or 512x512 preferred, that can be uploaded to commons and then displayed on a Wikipedia page using a normal browser. --Guy Macon (talk) 05:21, 6 June 2020 (UTC)[reply]

Ayup what's this? Four southerners being quoted by a colonist? Martin of Sheffield (talk) 08:59, 6 June 2020 (UTC)[reply]

A Dumb C# Question

Hi!

I'm here asking how do method names work? I'm using Unity with C#, and I'm relatively new. I have only used things like "Public Void Awake" or something like that, but I have seen people using things like "Public Inventory" for their method names. I'm not really asking for any answer but really just more reading material on the subject.

Thanks! JazzClam (talk) 12:22, 4 June 2020 (UTC)[reply]

It is access-type return-type method-name(param-type-1 param-name-1 [, param-type-2 param-name-2…])

so 'Inventory' is a class declared somewhere. LongHairedFop (talk) 17:04, 5 June 2020 (UTC)[reply]

Yeah, that method is returning an object of type Inventory. Inventory will be a class declared somewhere. Given it's something using Unity, it's presumably a class that implements a character's inventory. This is basic object-oriented programming stuff. Sounds like you're new to it, which is great! If you want to learn C#, you will likely find it worthwhile to invest in a good book. Unfortunately I don't really have C# experience so I'm afraid I can't recommend any off the top of my head. Perhaps some others can chime in. I do have a good deal of C++ experience, which is a similar-but-not-identical language. --47.146.63.87 (talk) 21:11, 5 June 2020 (UTC)[reply]