Bug when converting pixel into text value. ASCII

[RomainGr]

Hi,

Sorry I’m unable to explain the issue I have in the title without showing the example.
So here is the little p5 sketch

and the version with the code

When you drop an image it vectorises the image, something very simple, goes around each pixel, get the luminance and convert each pixel in a black rectangle (wider rectangle when the pixels are darker).
You can also see in the top right corner of the screen some kind of mapping of the current image, I’m converting each pixel to a number from 0 to 10 (0,1,2,3,4,5,6,7,8,9,#), but the “ASCII Image” is actually mirrored and rotated, why does it happens?

on line 141

var lumRounded = Math.round(lum*10) != 10 ? Math.round(lum*10) : '#';

on line 171

if(y == 0 && x != 0){
	document.getElementById('textarea').value += lumRounded + '\n';
} else {
	document.getElementById('textarea').value += lumRounded;
}

Why is the ASCII image on the top right mirrored and rotated compared with canvas version?

Thank you.

[mnse]

Hi @RomainGr,

the problem seems to be order of how you process the image and your line-beak condition …

Cheers
— mnse

// I would change this ...
for (let x = 0; x < p.width; x += pixelLevel ) {
  for (let y = 0; y < p.height; y += pixelLevel ) {
// ... to this
for (let y = 0; y < p.height; y += pixelLevel ) {
  for (let x = 0; x < p.width; x += pixelLevel ) {

// ... and this ...
if(y == 0 && x != 0) {
  document.getElementById('textarea').value += lumRounded + '\n';
// ... to this	  
if(y != 0 && x == 0)  {
  document.getElementById('textarea').value += '\n' + lumRounded;

[RomainGr]

Hi @mnse,

Thanks, that’s working now, but still, I’m not sure if I understand why the ascii image wasn’t matching the pixelated.

So instead of going from left to right then going up to down :

for (let x = 0; x < p.width; x += pixelLevel ) {
  for (let y = 0; y < p.height; y += pixelLevel ) {

we are doing it from top to bottom then left to right :

for (let y = 0; y < p.height; y += pixelLevel ) {
  for (let x = 0; x < p.width; x += pixelLevel ) {

and same for the line break.

Can this be done without changing the loop (first x then y)? Well, it’s working and I’m happy to keep it like this , but I don’t understand (yet), why changing the loop order affects the ASCII result and not the pixelated one.

Thank you.

[glv]

@mnse

// I would change this ...
for (let x = 0; x < p.width; x += pixelLevel ) {
  for (let y = 0; y < p.height; y += pixelLevel ) {
// ... to this
for (let y = 0; y < p.height; y += pixelLevel ) {
  for (let x = 0; x < p.width; x += pixelLevel ) {

@RomainGr

Can this be done without changing the loop (first x then y)?

There is a discussion here about performance benefits of one over the other:

Java single Array best choice for accessing pixels for manipulation?

:)

[mnse]

Hi @RomainGr

@RomainGr

but I don’t understand (yet), why changing the loop order affects the ASCII result and not the pixelated one.

For the pixelated it doesn’t matter, but maybe below demonstrates you why your ascii is “transposed” …

Cheers
— mnse

[RomainGr]

I think I’ve got it now, took me a bit of time, but the reason is quite simple!

The problem wasn’t about performance tho I understand why one way of doing is more performant now. It’s just about text flow.

The problem is that when you write text, it’s necessarily from left to right and top to bottom (at least in most western countries). When you draw pixels, the position of the pixel is always the same, whether you start from top or bottom, when it’s about text, the “flow” of the text is set based on the computer “language settings”. That’s why changing the loop affects only the textarea and not the rendering in pixels.

I’ve been actually able to reproduce the “bug” by simply change 2 css properties on the textarea :

writing-mode: vertical-lr;
text-orientation: revert-layer;

Let me know if I understood right!