Display (bitmap overlay) - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2 3 4 5 6 ... 41   Go Down

Display (bitmap overlay)

  • 402 Replies
  • 103972 Views
*

Offline srsa_4c

  • ******
  • 4451
Display (bitmap overlay)
« on: 13 / March / 2016, 20:03:42 »
Advertisements
My aim with this topic is to start a discussion on improvement possibilities of the CHDK display routines, focusing on DIGIC 6.
I only have some ideas, but no complete plan.

Difficulties on D6:
  • framebuffers are larger, resolutions and aspect ratios are different
  • the "final" overlay consists of 2 separate buffers (bitmap is YUV (2 pixels share chroma), alpha channel is in a separate buffer)
    - these are used by current CHDK routines
    - shared chroma makes drawing difficult
  • the source buffer is also available (RGBA), but it's unknown how to transfer its content to the "final" overlay
  • buffer dimensions change when switching to a different output device (LCD, video out, HDMI)
    - this one does not seem to make problems
  • reading bytes from uncached RAM seems very slow
    - not currently a problem, but good to know when searching for solutions
  • no known simple way to erase the whole overlay
    - the current workaround is to display and remove a known and almost empty Canon dialog box
  • D6 has a dedicated core for drawing overlay
    - there is some sort of communication between ARM and that core
    - finding out more about those communication routines would likely improve our display possibilities

CHDK:
  • all drawing ends up using a single pixel drawing routine
    - not optimal for performance, but easy to manage and overview
    - current D6 routine is ugly and slow
  • some CHDK features do read (and store) parts of the overlay
      - on D6, this would require huge amounts of memory

The sx280 has the lowest frame buffer resolution: 640x480 in LCD mode. An easy way to handle this would be using half resolutions is one or both directions. I chose not to do that, because 320x240 is just too low for my taste. On the other hand, the g7x's lowest resolution is 720x480, drawing with half (quarter) resolution would yield a familiar 360x240 dots.

What I'm considering

  • adding the possibility of different "default" fonts, more suitable for higher resolutions
  • using faster routines for drawing text
I have an RBF font utility in the works. Also managed to export the default CHDK font to RBF (to my surprise, it appears to be a subset of unicode characters). If it's really unicode, it will likely be possible to make higher resolution variants (does somebody know where the CHDK font comes from?).


Sorry about the lengthy and messy post.



edit: this post looks worse than I anticipated. Repeated newlines don't get displayed, there's huge space between paragraphs...
« Last Edit: 13 / March / 2016, 20:26:53 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 13946
Re: Display (bitmap overlay)
« Reply #1 on: 13 / March / 2016, 20:26:03 »
Thanks for starting this. I haven't really dug into the display code much yet, I hope to get into that a bit more now that I have most of the basic functionality working.
Quote from: srsa_4c on 13 / March / 2016, 20:03:42
- D6 has a dedicated core for drawing overlay
  - there is some sort of communication between ARM and that core
    finding out more about those communication routines would likely improve our display possibilities
In the 3rd dryos ROM in both the sx280h and g7x dumps, I found
"TAKUMI Corporation"
"GV550"
Which looks like an IP core GPU http://www.gshark.com/en/products/gv550/index.html
This is the same ROM with references to OpenGL ES. Since this is an IP core people license to integrate in their own chips, it seems unlikely we'll find much in the way of documentation.

The binary gk.log generated along with the romlog appears to be related to the GPU.

The main ROM display code on G3X and G5X seems to be quite different from other D6 cams, although it still has the GV550 string mentioned above. Other r57 cams code seems to be similar to g7x / sx280.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #2 on: 13 / March / 2016, 20:39:43 »
Quote from: reyalp on 13 / March / 2016, 20:26:03
In the 3rd dryos ROM in both the sx280h and g7x dumps, I found
"TAKUMI Corporation"
"GV550"
Which looks like an IP core GPU http://www.gshark.com/en/products/gv550/index.html
This is the same ROM with references to OpenGL ES. Since this is an IP core people license to integrate in their own chips, it seems unlikely we'll find much in the way of documentation.

The binary gk.log generated along with the romlog appears to be related to the GPU.
I'm somewhat confused about this D6 display stuff. I'm assuming the 3rd core is not _the_ GPU, because it runs DryOS. If this is true, then I would expect the 3rd core to interface the GPU and the (ARM<->graph) message routines I mentioned should then be a the interface to Canon's display routines running on the 3rd core...?
Logged
*

Offline reyalp

  • ******
  • 13946
Re: Display (bitmap overlay)
« Reply #3 on: 13 / March / 2016, 21:06:09 »
Quote from: srsa_4c on 13 / March / 2016, 20:39:43
I'm somewhat confused about this D6 display stuff.
Me too.
Quote
I'm assuming the 3rd core is not _the_ GPU, because it runs DryOS. If this is true, then I would expect the 3rd core to interface the GPU and the (ARM<->graph) message routines I mentioned should then be a the interface to Canon's display routines running on the 3rd core...?
That's pretty much what I've been guessing, but it's just a guess at this point.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #4 on: 01 / April / 2016, 19:56:10 »
Quote from: srsa_4c on 13 / March / 2016, 20:03:42
I have an RBF font utility in the works. Also managed to export the default CHDK font to RBF (to my surprise, it appears to be a subset of unicode characters).
Almost unicode, some non-alphabet characters differ though.
I still don't know what the source of CHDK default font is, but I have noticed similarity to some (PC) text mode bitmap fonts.
I'm now able to create and use different fonts* as CHDK built-in font. Two examples attached, one is "PxPlus IBM VGA8" from this site, the other is unifont. Both were converted from their truetype versions.

edit:
*limited to the current 8x16 pixels. Extending built-in font support to larger fonts is still todo.
edit2:
link added
« Last Edit: 04 / April / 2016, 19:15:02 by srsa_4c »
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Display (bitmap overlay)
« Reply #5 on: 11 / April / 2016, 15:31:44 »
Quote from: srsa_4c on 01 / April / 2016, 19:56:10
I still don't know what the source of CHDK default font is, but I have noticed similarity to some (PC) text mode bitmap fonts.
Finally found the source. It's called Terminus. It also has higher resolution variants, so it will be possible to keep it as default font.
Logged
*

Offline reyalp

  • ******
  • 13946
Re: Display (bitmap overlay)
« Reply #6 on: 05 / July / 2016, 22:18:14 »
I'm not sure if this should go in this thread, or the digic 6 thread
@Ant me asked (in PM)
Quote
When do you plan to add into CHDK support for Digic6 pixel format?
We realy need it:
https://chdk.setepontos.com/index.php?topic=12532.msg129205#msg129205
Short answer:
I'm supposed to have plans?! :haha

Longer answer:
There are a number of interrelated issues, which will require someone to spend a significant amount of time. At the moment, my time for CHDK is limited and tends to be in short chunks. I will continue working on bits and pieces as I have time, but I don't have a specific plan.

srsa_4c's OP in this thread, and reply in the thread Ant linked (quoted below) cover some of the main issues
Quote from: srsa_4c on 05 / July / 2016, 20:43:10
One of the difficulties is that parts of the CHDK code still expect a one byte/pixel overlay. Some routines (maybe zebra, edge overlay) save and restore parts of the overlay during their activity - that is currently impossible on D6 (the overlay data not only has a different pixel format, it also has opacity information in a separate buffer). And of course, the drawing routines need to be optimized for greater speed. All this would have to be solved before "fixing" zebra and edge overlay.

IMO, the stuff that needs to be done falls in a few general categories

1) Do the reverse engineering to find what we need digic 6
We have most of the buffers of interest, but we still need to figure out how to refresh the display without the busy hack. We also don't know how to get the current buffer for the viewports.
It's possible that further investigation would let us use the RGBA buffer rather than split alpha/YUV.  Further work on the Zico/Mzrm/GPU (see https://chdk.setepontos.com/index.php?topic=11316.80) may open up alternative approaches.

2) Resolve how to handle different display types in CHDK code, especially in modules
We could use the THUMB_FW ifdef in modules, but this will break if different D6 cameras have different requirements.
We could build separate modules for different display types, either with ifdefs in the same source, or entirely separate files.
We could (maybe) implement generic methods in the core so modules don't need anything display specific, but this would likely impact performance and code size.

This is a "boring" code organization issue, but as the person who ends up trying to keep several hundred CHDK ports usable and maintainable, it matters to me.

3) Implement the actual code to do what we need on d6
E.g. getting the right values out of the different YUV formats, drawing the zebra/histogram/edge, saving/restoring buffers or changing the code to not need it.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13946
Re: Display (bitmap overlay)
« Reply #7 on: 07 / August / 2016, 23:49:23 »
Looking at @62ndidiot 's motion detection code I realized the current digic 6 ports (including my g7x port) define vid_get_viewport_width and vid_get_viewport_height as the actual sizes (counting by Y values, as returned by GetVRAMHPixelsSize etc)

In older ports, _width is half the real width, and height is half if the real height is more than 240 (and yscale is set to 2). The _proper functions return the real width/height, primarily for PTP live view. The history is complicated, but it stems from the original cameras had a 720x240 viewport and a 360x240 bitmap. Using half width for the viewport allows a 1:1 correspondence, and results in roughly square pixels. Canon added different permutations of viewport and bitmap later and we added workarounds to mostly keep the same "logical" screen layout.

We haven't run into problems with this yet for the D6 ports, because the functions that depend on it being that way don't work for other reasons.

I'm not sure if it makes sense to keep the difference between the CHDK and _proper dimensions for D6, but we should make a specific decision. (we can always make a different specific decision later if the first turns out to be bad ;))

For the moment, I'm inclined to leave _width and _height the real values, and see how it goes.

In any case, the _proper values should always be the real values, not 2x the real value as some currently are. yscale should also be 1 if the height is the real height.

Thread on viewport / bitmap functions in general https://chdk.setepontos.com/index.php?topic=12709.0
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13946
Re: Display (bitmap overlay)
« Reply #8 on: 04 / September / 2016, 22:14:25 »
An observation from working on live view: The "focus peaking" display does not appear in either the viewport or bitmap, unless it's encoded in a way that goes away in the YUV conversion.

The same is true for the playback mode zebra, for both d6 and older cam.
Logged
Don't forget what the H stands for.
*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: Display (bitmap overlay)
« Reply #9 on: 05 / September / 2016, 02:16:03 »
On EOS cameras, digic 4 and 5, playback zebras are implemented with 0xC0F140CC, and there is some sharpening done on the entire screen with 0xC0F14140 (EnableFilter string). The effect of these changes is only visible on the display, not in the image buffers - they appear to be computed by the display device (the one that combines the BMP and YUV buffers, probably some FPGA). Zebras are applied on the YUV buffer only, while the sharpening is applied on the BMP image as well.

Note: on 5D3, playback zebras are implemented with 0xC0F14140 in firmware 1.1.3 and 0xC0F14394 on 1.2.3. This is why I guess the display device is probably not a hardcoded ASIC, but something reconfigurable.

Do you have "hardware" focus peaking on any compacts before digic 6?
Logged
Pages: [1] 2 3 4 5 6 ... 41   Go Up
« previous next »
 

Related Topics