#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

good day

I dont know how to do the "is here" thing, but I am also here ��

eppisai: https://gist.github.com/xero/2d6e4b061b4ecbeb9f99

have to leave for a sec

no problem

lets start with our interns, then eppisai and then the core team

Hi, so last week was quite fruitful :)

my image button PR was finally merged, then i started working on the visualizer display task (T1215)

great!

many thanks!

BAndiT1983 has some more ideas to improve the visualizer like flashing to pic16 but we are still discussing

ehm, not visualiser, we will turn more to the hardware

bluez, what do you have in terms of news for us?

sorry, got delayed ... here now :)

s/writting/written

and here is the full project for bitstream generation: https://github.com/Swaraj1998/axi-lite-slave-prj

while doing this.. i also stumbled upon a small typo in the beta axi slave code... which as Bertl mentions could potentially be the reason for some of the axi related issues

we can now use this test setup later to compare with our new approach to registers

Bertl: thanks! :)

many thanks

not too great

our python compressor can now also do huffman encoding so we have all the blocks together

lossless compression gives us roughly a factor of 1.37:1 - 1.7:1

this is with real world sample footage already?

lossy compression can give us about 4.5:1 - 13:1 with a psnr of 50db to 55db

this is using the collected realworld dataset I collected

great

probably one could do something smart there but there is a red patent that covers some of the things one can do there :(

yes

vup worked on a port of the compressor to rust for improved performance

the next step would be either to improve on that and add the missing compression building blocks there to be able to experiment faster with parameters

se6ast1an: this one has atleast some stuff: https://patents.google.com/patent/US9245314B2/en

thats it from me

ah one more thing: the images vary a lot in compressability and noise seems to be quite a showstopper

but thats quite expected I assume as noise is a rather high frequency image content

yep, but it would be nice to have something that removes the rcn noise before the compression

well thats what we are already doing is essence using the wavelet transformation

Bertl: do you have references for that?

anuejn: nothing I can link here ...

the problem with proper FP and NUPR noise removal is that it requires a lot of resources

sure we will have to experiment a lot with many different parameters I think

not this week

BAndiT1983: any news from your side?

not much

also improved some code in the visualiser and also continuing there

regarding the LCD contrast, it's solely for the visualiser, will add also a toggle button to switch it on and off, it simulates the real display a bit, but also helps to simulate LCD brightness setting to make it darker etc.

besides axiom remote was also working a bit on the "pick and place" data script, but haven't reached the milestone i wanted yet, have to adjust the position of components for the orientation of the PNP machine

many thanks

yeh! was just waiting, had typed in notepad..

Also since the last 3 days I am trying to add a working keyboard.. se6ast1an is helping me with this..

Have took care of corner cases like when user is at A and he/she presses left then cursor will move to Z, or erasing without inputting etc..

This is how it looks..

do we need a hash map there or can we use ASCII values?

: D

yeh, but still buttons need to be stored so, memory will be used..

yes knob plus buttons around LCD I would assume

the idea would be to see what works best from the user experience

Yeh, with knob I think, But i will figure it out how to add..

yes, left button moves "right and right button moves "left" is not optimal, but for a first prototype ... and the music made up for it :)

chiptune, ohk I'll see

good idea

and we need a button to "finish"

there is nothing more annoying than moving through all the letters in the alphabet (and possibly the numbers as well :)

Bertl: ask game console users in the 90s and 00s

Yeh I thought of up and, but Like "WASD" type something would work, but if up/down are in top button drawer, and left/right in button, would have made made bit hassle for user

what about using the side buttons there?

nah, bottom for left/enter/right

actuallu,yeh that would be good..

you can use the middle side button for e.g. backspace/del/erase

or to switch between characters and numbers/special symbols

ohk so two screen keyboard

for example, also the side buttons do not need to be large and/or present on both sides

so they do not necessarily use up a lot of space

BAndiT1983 : ohk..

manfred visited me in the factoryhub today

also the oshpark delivery of mixed panels has arrived today

bertl still needs to verify at least one component on the stencil

component purchase will start shortly after tele have approved our suggestion who sources which parts

we will print teles bar code and number onto labels that we stick to the reels

I think thats it from me

Well, I was swamped with non Axiom related work last week, so besides working with bluez and helping out with pcb/stencil reviews not much did happen

many thanks

Hi, here is my personal progress report.

They are wonderful works!

great to hear, thanks :D

It's a little exciting for me that the "first angle method" is used for mechanical drawing, instead of the "third angle method"  which is used in Japan :)

interesting details :D

and i am looking for a graphics designer to collaborate on the redesign

ok then

many thanks everyone!

It was a bit unclear to me what the exact problem is they are trying to solve

"have a healthy and active community"

I think the "problem" is that there are many different tools for graphics design

and the "input" and "output" of one software to the other in some cases resulted in color representation differences

ok, gotta leave

just another image lib

*image loading/saving

do they implement concrete algorithms?

they seem also to target RAW and such -> https://github.com/OpenImageIO/oiio/issues/1944

off for now ... bbl

off to bed

uploaded the preview of the LCD simulation for the visualiser -> https://lab.apertus.org/T1212

for the birghtness control, not for the toggle button

I don't know what part of the device tree could be so different

anyway now that it's failing to boot from SD card, it's running apparently some wacky demo flash-loaded default firmware, that flashes RGB LEDs and uses buttons as control for audio recording and playback... https://github.com/Digilent/ZYBO/blob/master/Projects/dma/sdk/dma/src/audio/audio.c

Ah apparently the demo was running was because it's midnight and I'm cognitively impaired and I forgot I removed the microSD card.

and I did check that the UART used for console in the u-boot environment variables is the same one at the same address

flash being the nand flash or the sd card?

IIRC, on the Zybo it has some random number and a globally unique EUI

is anything on the SD card boot partition required to be... aware of the identifier?

i.e. if you boot an Axiom Beta boot image there, we definitely won't check any EUI or whatnot

how about getting a new one?

I will, I just forgot to write down to get one

All that was on the boot partition of the pynq image was two binary blobs

hm... the zynq has at least two uarts

I was getting output with the pynq image and it had the same console UART settings so I think that's not the issue

hm...

xilinx sure does love monsterblobs with no docs since you're expected to use their tooling

nobody at Xilinx understands the tools :)