u/Trollercoaster101

I recently bought a couple of these Japanese prints at a sale from a private vendor. They had no further info about these prints apart from the japanese origin.

I passed the pictures to Gemini which told me they should be haiga prints (illustrated haikus) from the Edo or Meijin era of Japan but i trust AI only to a point and i would love to be able to find out more from a reliable source.

I also used google lens to look up for similiar prints but did not find one that matched the style correctly.

Does anyone have any idea?

I recently bought a couple of these Japanese prints at a sale from a private vendor. They had no further info about these prints apart from the japanese origin.

I passed the pictures to Gemini which told me they should be haku-ga prints (illustrated haikus) from the Edo or Meijin era of Japan but i trust AI only to a point and i would love to be able to find out more.

I also used google lens to look up for similiar prints but did not find one that matched the style correctly.

Does anyone have any idea?

For those who missed the original post or didn't have a chance to read it, start here.

Hello again everyone,

You might remember me as the guy who was so bored and sleep deprived that decided to answer the question "could I simulate an hour of bouncing DVD logo, trace the trajectories and count the amount of perfect_corners?"

In my last post many people noticed a certain weird behaviour in my simulation. Specifically, the trajectories were leaning towards the center and also not following a 45 degree trajectory as the bouncing DVD logo simulation would require.

The starting degree issue was actually intentional on my part. I had simulated the 45 degree angle and noticed there were no perfect_corners, therefore an hour of simulation didn't bear an interesting outcome and at that point i had also asked myself if changing the starting angle would push the logo towards a higher number of "perfect corners" match.

The second issue, trajectories showing a bias for the center, was due to the logic behind my DT simulation. The dt parameter I used tried to mimic a 60Hz screen by looking at the trajectory position in discrete timesteps, reaching what was closer to 60FPS being set at 0.0167 (though it was an approximation and not a precise measurement of 60Hz).

You can see in the first picture what happened when i set 45 degrees as a starting angle in my first simulation.

At this point though another, more interesting question popped in my mind. "Could I use a random search to find that angle that optimizes the perfect_corners count?"

To reply to this question though, I had to move on from a monolithic coding approach and use an object-oriented approach to develop a proper engine with an underlying set of physics rules to run over. The entire system is built this way:

- Physics core - Function with a set of physics rules for an enclosed system simulating a rectilinear motion in a space with reflective boundaries

- Three different functions with three different engines running over the established physics rules in order to test three different logics

- compute metrics function that logged the results independently

- plot function that gave out visual results.

Why three different engines though?

I told you how the initial "DT Engine" had issues and also introduced a bias. Not only that but i realized that the perfect corners count was wrong for two reasons:

- First, the DT parameter made it so that my engine "looked up" for trajectory position at given time intervals, therefore it allowed the trajectory to overshoot and then reposition it inside the system, exaggerating the perfect corners count;

- Second, The way i measured the perfect corner in the original simulation was trying to match the logo corner with the border corner, introducing a tolerance measure to log as a perfect corner even if the match was not precise;

To straighten this issue up i decided to introduce two new engines:

- An event-driven engine which just simulates the trajectory and then asks itself "where will the next collision happen?", and then brings the system there next and move on to the next collision;

- A pixel_snapping engine which uses the same event-driven engine logic and then "snaps" the trajectory to a pixel_grid that simulates the pixels of an lcd/led screen. This is a visual quantization and not a change in physics, therefore the underlying trajectory results are equal to the event-driven engine. The amount of pixels used is a hyperparameter.

At this point i redefined how i logged a perfect corner by having the sides of the logo box register a simultaneous collision event with the space borders, meaning it inevitably approached one of the corners. A collision on x and y axis simulataneously means you get a perfect_corner.

The images above are almost all extracted by this system of simulation:

Image 1 - Original simulation with a DT system on a 45 degrees angle.

Image 2 - New physics system simulation for bouncing dvd logo showing what happens when you set 45 degrees on DT Engine running on top of the physics core

Image 3 - 45 degrees on event-driven engine

Image 4 - 45 degrees on the pixel_snapping engine

Image 5, 6, 7 - Results of Random searching a 360° degrees starting angle space to optimize the perfect_corners count. The randomly chosen corner is 279.4613° and it gets the best outcome in perfect corners.

The result i observed is that the systems are essentially quasi-periodic or non-periodic, unless you select a specific "special" set of starting angles like 45, 90 etc. and then you get a periodic trajectory which might avoid giving out perfect corners entirely.

The system i coded keeps logging the trajectories as before, and visualize them alltoghether, though i apologize for not focusing much on data visualization with the charts but all i wanted this time was to get a working plausible system.

Please NOTE: The pixel_snap visualization is smaller in the way it is represented because i wanted to avoid that the logo snapped itself to the container border creating an ambiguous visualization.

As many requested the simulation is now available on github here, commented and explained in the .ipynb notebook.

Hello everyone,

i had some spare time on my hands and my mind was kinda foggy due to sleep deprivation so i decided to use google colab and python to simulate one hour of Bouncing DVD Logo trajectories and trace them into a dedicated chart.

The simulation has the following base parameters:

width, height = the size and shape of the geometry which will serve as a boundary for the bouncing logo. In this case it was set to 4,3 to simulate a CRT 4:3 screen.

dt = the update resolution in terms of seconds per step, which essentially simulates the Hz frequency of the screen. It is set to 0.0167 here to approximate a 60Hz screen

t_total = total simulation duration, set to 3600 here to account for an hour of bouncing dvd logo

speed = logo speed magnitude (unit_measure/seconds). It determines how much the logo moves between steps (speed*dt)

logo_w, logo_h = the final width/height logo size using the same measurement units as the container.

A final numpy random seed.

The logo plotted in the chart marks the final logo position in the simulation.

There is no logo rotation ad here i am assuming a 37 degrees angle for the bouncing logo. The "perfect corners count" checks if one of the four corner of the picture hits one of the four corner of the defined bouncing area.

The colormap highlights the most recent trajectories in yellow and the oldest ones in purple.

I probably didn't add anything valuable to data science today. but I'm fairly new to Python and programming in general and this was mostly a joke project in had in my mind so i hope you people appreciate the stupid effort.