Current Server Time: 05:25 (Central Europe)

#apertus IRC Channel Logs

2020/04/30

Timezone: UTC


02:02
Bertl
off to bed now ... have a good one everyone!
02:02
Bertl
changed nick to: Bertl_zZ
03:34
metal_dent[m]
Morning!
04:13
Spirit532
left the channel
04:13
schmoggie
joined the channel
04:13
Spirit532
joined the channel
04:16
schmoggie1
left the channel
05:45
BAndiT1983|away
changed nick to: BAndiT1983
05:46
BAndiT1983
hi metal_dent[m]
06:21
metal_dent[m]
Hello
06:21
BAndiT1983
how is it going?
06:22
metal_dent[m]
Good, I added the _leftButtonBar in IScreen yesterday and also tested it, it works!
06:22
BAndiT1983
very good
06:23
metal_dent[m]
So what are the next steps?
06:23
BAndiT1983
please check the docs about show/hide the button bar, would be good to have automatic enabling when button is added, but also ShowLeftButtonBar(bool show)
06:24
BAndiT1983
but there is additional important step to implement
06:24
BAndiT1983
as the button bars will reduce the size of the dialog, the logic has to be reworked a bit
06:25
metal_dent[m]
> please check the docs about show/hide the button bar, would be good to have automatic enabling when button is added, but also ShowLeftButtonBar(bool show)
06:25
metal_dent[m]
Show it when an ImageButton is created..?
06:26
BAndiT1983
base class should have general logic, like drawing the dialog and button bars, latter one at last, but the dialog drawing should be something like DrawContext() which will be overridden in the derived class, this drawing method should get x, y, width and height of available content area, which will be calculated in the base class, when it's clear which bars will be drawn
06:26
BAndiT1983
no, show it when a button is added to it, which button types does the button bar accept?
06:27
metal_dent[m]
It can accept any, but the left is only for the ImageButton, right?
06:28
BAndiT1983
in current concept is, but we won't limit it
06:29
metal_dent[m]
Okay
06:30
metal_dent[m]
Also I think the width of the left bar is too much, what should be the ideal dimensions?
06:31
BAndiT1983
do you have a screenshot?
06:32
metal_dent[m]
No, let me take one
06:38
BAndiT1983
added a task to lab, for the screenshot button, so it's easier to do
06:42
metal_dent[m]
here -> https://pasteboard.co/J6aii04.png
06:45
BAndiT1983
as you are in control of the sidebar, which width did you supply?
06:45
BAndiT1983
also the button can be a bit smaller, which width does it have at the moment?
06:45
BAndiT1983
the edges are still jagged, the conversion seems to be not that optimal
06:46
metal_dent[m]
bar -> 50x180
06:46
metal_dent[m]
button 24x24
06:46
metal_dent[m]
> the edges are still jagged, the conversion seems to be not that optimal
06:46
metal_dent[m]
yes, maybe we need a different method, other than the xbm format for the conversion
06:48
BAndiT1983
it has nothing to do with the format, but with conversion from SVG
06:48
BAndiT1983
bar is too wide, you can make it 30 or 32, as you don't need that much space around it
06:50
BAndiT1983
straight lines at the bottom of the home icon are totally jagged, this is clear sign for problems in the conversion
06:52
metal_dent[m]
Okay
06:57
se6ast1an
good day
06:57
se6ast1an
great to see sidebar progress!
07:42
mumptai
joined the channel
07:59
se6ast1an
onto the parametermenu now
07:59
se6ast1an
I decided for a slight design change there
07:59
se6ast1an
and instead of making it a small pop up inside the settingsmenu decided to make the parametermenu fullscreen, very similar to an actual menu
08:03
BAndiT1983
ok, but we would still use the same screen, was thinking about the parameters and buttons yesterday, as handling will be similar through handler methods
08:04
se6ast1an
same screen?
08:04
BAndiT1983
although my canon EOS does both, popup and separate screen, in case there are more settings than just on/off
08:04
se6ast1an
I would derive the parameter menu from IMenu
08:04
BAndiT1983
IMenu is for menu screens, but there will also be the menu widget soon
08:05
BAndiT1983
if you will only have like 3 selections, i don't see a need for a separate screen, but to be able to handle it, the widget is required
08:05
BAndiT1983
like main menu and another one which will dynamically present available options
08:06
BAndiT1983
later we can ditch the IMenu, as it has no real purpose that is different from IScreen
08:07
se6ast1an
yeah I agree if the choices are simple and "small" the "pop-up menu" is better but you can quickly run out of space with longer more complex choices, the question is if its confusing if there is this inconsistency
08:08
se6ast1an
sometimes popup sometimes whole screen
08:08
BAndiT1983
what about a popup like smartphones do it, in the center of the screen?
08:08
BAndiT1983
we could dim everything behind
08:09
se6ast1an
well that for me is basically the full screen menu option as it makes it hard to see anything of the things in the background
08:09
se6ast1an
the advantage of the pop-up menu I consider that you still see all the other menu items and current values
08:11
BAndiT1983
i think that a small popup menu does not force the user attention to switch suddenly, but we can just test things out, either way requires a menu widget, so it is possible to position it everywhere
08:11
se6ast1an
right, you convinced me to implement both options
08:12
BAndiT1983
not me, canon EOS ;)
08:12
BAndiT1983
full screen menu -> https://media.gettyimages.com/photos/menu-screen-on-a-canon-eos-450d-dslr-camera-the-cairngorms-february-4-picture-id133036820?s=612x612
08:13
BAndiT1983
and now i can't find their popup screenshot
08:14
se6ast1an
so fo the small popup parameter menu would you derive imenu orr iwidget?
08:14
BAndiT1983
from iwidget, as it's the interface for widgets
08:15
BAndiT1983
imenu was added for menus, but as we can have multiple different, e.g. WB will also use menu widget, the decision was changed to widget
08:16
BAndiT1983
which was also not avoidable, otherwise we wouldn't get flexible and stable solution
08:17
se6ast1an
ok
08:25
BAndiT1983
btw. this is how canon does the input -> https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcT_aRTJDPK0PVP8z6OPkigqzvu94dsacuwsvNQHBlRh4w9XijbA&usqp=CAU
08:26
BAndiT1983
but we have multiple buttons around and can do it like T9
08:27
BAndiT1983
ah, finally found some popup menu from them -> https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcTQ5J6XeG0C0wrOMk_kwNLSBFyOcQNo4DE9zuIgVWqW_3axm6a8&usqp=CAU
08:29
se6ast1an
added to https://lab.apertus.org/T1182
08:29
se6ast1an
thanks, thats very similar to the old style popup parametermenu
08:30
BAndiT1983
never noticed, but they really hide other entries, when menu comes up
08:31
BAndiT1983
i would just dim, but this are details for now
08:31
se6ast1an
agreed
08:56
elkos
left the channel
08:56
ashok_singh[m]
left the channel
08:56
aleb
left the channel
08:56
pratyush[m]
left the channel
08:56
MarkVandenBorre[
left the channel
08:56
RexOrMatrix[m]
left the channel
08:56
preetimenghwani[
left the channel
08:56
promach3
left the channel
08:56
metal_dent[m]
left the channel
08:56
abeljj[m]
left the channel
08:56
parasew[m]
left the channel
08:56
bluez_[m]
left the channel
08:56
sergio__[m]
left the channel
08:56
WalterZimmermann
left the channel
08:56
shashwat1999[m]
left the channel
08:56
apurvanandan[m]
left the channel
09:08
preetimenghwani[
joined the channel
09:09
MarkVandenBorre[
joined the channel
09:14
elkos
joined the channel
09:14
apurvanandan[m]
joined the channel
09:14
aleb
joined the channel
09:14
pratyush[m]
joined the channel
09:14
WalterZimmermann
joined the channel
09:14
ashok_singh[m]
joined the channel
09:14
sergio__[m]
joined the channel
09:14
bluez_[m]
joined the channel
09:14
metal_dent[m]
joined the channel
09:29
shashwat1999[m]
joined the channel
09:29
parasew[m]
joined the channel
09:29
promach3
joined the channel
09:29
RexOrMatrix[m]
joined the channel
09:29
abeljj[m]
joined the channel
11:00
Bertl_zZ
changed nick to: Bertl
11:01
Bertl
morning folks!
11:04
se6ast1an
good day
11:26
anuejn_
changed nick to: anuejn
11:37
metal_dent[m]
BAndiT1983: how about now -> https://pasteboard.co/J6cdKl6.png
11:43
se6ast1an
dimensions look good, the icon scaling looks a bit better but not great yet
11:44
se6ast1an
are the icons 1 bit color?
11:51
Bertl
btw, I strongly suggest to use a font suitable for the size and the fact that it is not anti-aliased ... same goes for the icons
11:57
BAndiT1983
fonts were never generated from scratch, this ones are from adafruit
11:58
Bertl
just saying as it really looks unnecessarily ugly
12:08
BAndiT1983
http://oleddisplay.squix.ch/#/home
12:08
BAndiT1983
display should be set to 320x240 and library version to Adafruit GFX Font
12:10
BAndiT1983
font customiser for adjustments or icon fonts -> https://tchapi.github.io/Adafruit-GFX-Font-Customiser/
12:12
se6ast1an
not a priority atm IMHO
12:24
metal_dent[m]
> are the icons 1 bit color?
12:24
metal_dent[m]
What do you mean? They are black and white
12:24
BAndiT1983
ts, ts, ts, you've forgot the challenge task
12:41
se6ast1an
yeah I am sorry it was a trick question :)
12:42
metal_dent[m]
Oh you meant the depth? ':D
12:42
se6ast1an
for the kind of symbols we are now starting to add it might make sense to make it 2 or more bits
12:43
se6ast1an
because metal_dent[m] how many color would 2 bits give us?
12:44
metal_dent[m]
4
12:44
mumptai
general question: is axiom micro still alive and used/developed?
12:47
se6ast1an
mumptai: yes, version 3 is on the way to design completion
12:47
se6ast1an
metal_dent[m]: correct!
12:48
se6ast1an
for the icons do you currently draw the rounded rectangle in the code and the icon as black image right?
12:51
BAndiT1983
se6ast1an: why 2 or more bits?
12:51
metal_dent[m]
Yes
12:51
se6ast1an
for limited antialiasing
12:52
se6ast1an
of icons
12:54
BAndiT1983
ok, is also possible but has to be checked how to mix colors, only for visuals it would require more power
12:54
se6ast1an
true, but we had 8 bit icons before
12:55
se6ast1an
so it wuld still mean a significant speed up with 2 bits for example
12:55
se6ast1an
but two additional shades might be enough to create smooth edges
12:56
BAndiT1983
i have to check the anti-aliasing topic, but usually it's intermixed with the background or whatever is behind the pixels in question
12:57
se6ast1an
that would indeed be more complicated/resource intensive
12:57
se6ast1an
but we can avoid that by using transparent, light grey, darkgrey, black as the 4 color options
12:57
se6ast1an
no mixing required
12:57
se6ast1an
and will look good on bright background
12:58
se6ast1an
will not look good on dark background
12:58
se6ast1an
but thats OK
12:58
BAndiT1983
sounds good
13:02
se6ast1an
will add lab task
13:05
se6ast1an
https://lab.apertus.org/T1191
13:08
metal_dent[m]
Is this for every images/icons?
13:11
se6ast1an
as long as its monochrome yes
13:12
metal_dent[m]
Okay, you want monochrome image with 2 bit depth, right?
13:13
BAndiT1983
we need proof of concept first to see the improvements of the edges
13:14
BAndiT1983
i still think that proper conversion will reduce many problems
13:15
se6ast1an
https://lab.apertus.org/T1177#16981
13:18
se6ast1an
btw, newRaspberry Pi High Quality Camera revealed: https://www.youtube.com/watch?v=YzEZvTwO7tA
13:19
BAndiT1983
and without images
13:19
BAndiT1983
great!
13:19
BAndiT1983
last sentence for parameter menu, and before that about missing result images of the camera
13:20
BAndiT1983
parameter menu needs more distinguishing, as it drowns among other options
13:21
BAndiT1983
but this we can try with dimming, whitening or hiding
13:22
se6ast1an
I indeed used a dimmed color option for the background in the old C firmware: https://github.com/apertus-open-source-cinema/AXIOM-Remote/blob/dev/Archive/AXIOM_Remote_Prototype_V01.X/menu.c#L41
13:24
BAndiT1983
it's not hard to add, duplicate fill, call it dim and let it go over all pixels and reduce the brightness, then draw the menu
13:37
BAndiT1983
https://drj11.wordpress.com/2009/04/30/2-bit-dither/
13:52
se6ast1an
dithering makes sense for large scale images with gradients, etc - for icons with clear geometry I don't think it will help much
13:53
BAndiT1983
it was meant for conversion, to check the options in IM
13:53
se6ast1an
" let it go over all pixels and reduce the brightness" that would require partial redrawing which is not possible currently or how do you mean?
13:57
BAndiT1983
before the parameter popup is drawn, you can call a Dim() method, which would iterate over all pixels in framebuffer, but this time not fill, but reduce the values
13:57
BAndiT1983
for dimming we have to redraw whole screen, we don't have partial updates yet
13:58
se6ast1an
understood, good idea
14:15
se6ast1an
do you have a quick method how to dim a color565 16 bit color value?
14:19
BAndiT1983
subtract some known 565 value, e.g. use rgb565 converter
14:19
se6ast1an
thanks
14:19
BAndiT1983
http://www.barth-dev.de/online/rgb565-color-picker/
14:20
BAndiT1983
take a grey value and off you go, will end my work in am oment and assist a bit
14:22
BAndiT1983
alright, troubleshooting the backend is never fun, earned the long weekend
14:23
BAndiT1983
will check the debug problems first, maybe then you will have some results on dimming
14:23
se6ast1an
great
14:25
BAndiT1983
debug fixed in launch.json, working directory was wrong, this is the right one -> "cwd": "${workspaceFolder}/AXIOM_Remote_Firmware_Visualizer",
14:27
BAndiT1983
pushed
14:28
se6ast1an
great, I subtract a dark grey to dim, interestingly it creates weird colors...
14:29
BAndiT1983
have suspected it, as overflow is kicking in probably
14:29
BAndiT1983
by the way, haven't set default build type to debug at the moment, so it requires cmake -DCMAKE_BUILD_TYPE=Debug .. for now
14:29
BAndiT1983
only one time
14:31
BAndiT1983
what happens if you multiply the pixel color by 0.8 or so?
14:31
BAndiT1983
will also test quickly
14:34
BAndiT1983
nice, LSD effect
14:36
BAndiT1983
se6ast1an: this isn't looking too bad -> https://pastebin.com/raw/P1fn8h9c
14:36
se6ast1an
thanks , will try
14:37
BAndiT1983
but you also have to check if there is overflow and set to 0, otherwise it will invert the colors, try this one out and i will post fixed version
14:38
se6ast1an
your color makes everything green
14:38
se6ast1an
mine so far pink :)
14:38
BAndiT1983
https://pastebin.com/raw/4ri59Q1h
14:39
BAndiT1983
visualiser shows everything correctly, have to grab my board to test it
14:39
BAndiT1983
dimColor should be calculated only once and placed in the enum of colors of course, so the version is a hacky one for now
14:44
se6ast1an
https://paste.pics/5538e85118b6c9fd096de91cc71858c1
14:44
BAndiT1983
ah, was only checking the main page first, just a moment, my board was crashing because if dimming
14:45
BAndiT1983
ah, i understand, as green has more bits it's much stronger
14:47
se6ast1an
but green is also much "stronger" in the subtracted color...
14:48
BAndiT1983
yep, looking currently into it, but looks nice, reminds me of old DOS graphics, like EGA ;)
14:49
BAndiT1983
it does not affect gray that much, which is interesting
14:58
comradekingu
left the channel
15:01
comradekingu
joined the channel
15:02
BAndiT1983
probably every channel has to be reduced by same value, still looking
15:03
se6ast1an
yeah but thats exactly what should happen with a grey value
15:04
schmoggie1
joined the channel
15:05
schmoggie
left the channel
15:10
Bertl
off for now ... bbl
15:10
Bertl
changed nick to: Bertl_oO
15:31
se6ast1an
BAndiT1983: I now have a rudimentary "complete" first state with the parameter menu, its working on visualizer but crashing the remote currently
15:31
se6ast1an
what would be a good time to push?
15:48
se6ast1an
its the dim function that causes the crash
15:49
mumptai
se6ast1an, can the new micro revision be seen somewhere?
15:49
se6ast1an
check with anuejn and vup
15:50
se6ast1an
the monday irc meeting logs are a good starting point though
15:50
se6ast1an
http://irc.apertus.org/
15:57
se6ast1an
BAndiT1983: pushed, please give it a spin
16:08
vup
mumptai: what do you mean by seen? we are currently still working on the schematic, the current status is regularily pushed to https://github.com/apertus-open-source-cinema/axiom-micro-mainboard/tree/r3
16:08
vup
a pdf export of the schematic can be found here: https://github.com/apertus-open-source-cinema/axiom-micro-mainboard/blob/r3/micro_rev3/micro_rev3.pdf
16:08
vup
note that this is still very work in progress
16:12
mumptai
i just found the branch
16:40
BAndiT1983
changed nick to: BAndiT1983|away
17:33
mumptai
the lfe5 is there for usb3?
17:34
vup
mumptai: partly
17:35
vup
it is also used as gpio expander
17:35
vup
and we are planning to make basic camera functionality (no plugin modules, no shields, only usb 3 for output) available without the zynq dev board
17:36
vup
for usecases where all that flexibility is not necessary
17:38
mumptai
and added benefit: yosys&nmigen might be availiable too
17:38
mumptai
sensor is gonna be an ar0330 again?
17:39
vup
mumptai: yes yosys & nmigen is the main reason we chose an ecp5 for that
17:39
vup
although nextpnr-xilinx is also coming along quite nicely
17:39
vup
the sensor is on a extra board to make it swappable
17:40
vup
the first module we will develop will probably be the ar1335
17:41
vup
(similar size as ar0330, but 4k and only ~$15 as single quantities)
17:42
mumptai
if cost isn't an issue zynq ultrascale wouldn't be a bad option
17:43
vup
yeah, infact I think this might be an option the beta will explore in the future
17:43
mumptai
powersupply is a similar annoyance, only thing, you need a 32bit ddr3 or ddr4 memory
17:44
vup
we are already considering it for a external recorder, so after getting some hands on experience with it, we will probably be able to judge better
17:44
mumptai
okay, its complexity is daunting
17:45
vup
yeah
17:45
vup
but using a ready made devboard again could help there
17:45
mumptai
but sata, GbE and usb3 might be easily available
17:45
vup
for example this one: https://www.avnet.com/shop/us/products/avnet-engineering-services/aes-ultra96-v2-g-3074457345638646173/ is quite cheap for what it is
17:45
vup
yeah thats a big plus
17:46
mumptai
its connected to the PS, and linux support should be "okay"
17:48
vup
yeah seems like most interesting linux drivers are already upstream, which is a big plus
17:48
vup
as xilinx likes to break stuff on their linux fork and always lags behind the upstream by quite a bit
17:48
mumptai
it think xilinx understood that some time ago ;)
17:49
vup
yeah
17:54
mumptai
the ultra96 seem to focused on usb3/mipi/dp, no sata, no GbE
17:54
mumptai
might be hackable though (not so sure about that)
17:57
vup
well sata vs usb3 isn't that big of difference, but yeah its not optimal, otoh its price is unbeatable afaik
17:58
mumptai
https://shop.trenz-electronic.de/de/TE0802-02-2AEU2-A-MPSoC-Development-Board-mit-Xilinx-Zynq-UltraScale-ZU2-und-LPDDR4?c=473
18:01
mumptai
also no sata, but at least M2
18:03
Roopar
joined the channel
18:03
Roopar
left the channel
18:11
vup
nice find
18:11
mumptai
apperently the m2 slot might actually use SATA, or PCIe
18:12
vup
even better
18:15
mumptai
at least that what i would guess, from the schematics and the sole existence of m2 to sata-connector
18:17
se6ast1an
very interesting trenz board, but how would you actually get data into the system? it says Benutzer-I/O but no details...
18:21
vup
i think Benutzer-I/O in this case means the 7-segment displays, leds, switches and buttons
18:21
mumptai
the pmods are likely to be too slow, 33R + ESD
18:25
mumptai
the zynq seems to lack a lot of PL ios, strange
18:26
mumptai
most is used for pmod, buttons, LEDs and a vga output
18:33
mumptai
4-lane csi might possible, at least pin-count wise
18:44
vup
yeah this board seem more like an actual dev board and not like the like a SOM kind of thing
20:11
BAndiT1983|away
changed nick to: BAndiT1983
20:53
alexML
left the channel
20:53
BAndiT1983
changed nick to: BAndiT1983|away
20:54
alexML
joined the channel
20:57
se6ast1an
off to bed
20:57
se6ast1an
good night
21:05
vup
nn
21:14
BAndiT1983|away
changed nick to: BAndiT1983
22:02
BAndiT1983
changed nick to: BAndiT1983|away