Display (bitmap overlay)

  • 64 Replies
  • 7874 Views
Re: Display (bitmap overlay)
« Reply #40 on: 20 / March / 2017, 09:50:00 »
Advertisements
Quote
Does the CHDK histogram do anything that the Canon one does not? 
I wondered the same thing.

*

Offline reyalp

  • ******
  • 10244
Re: Display (bitmap overlay)
« Reply #41 on: 20 / March / 2017, 13:34:39 »
Does the CHDK histogram do anything that the Canon one does not?
Yes: Various RGB modes, log scale, auto-scaling, over/under indicators ...

How useful these things are is a different question.
Quote
  I've been under the impression that histogram was added in the early days of CHDK when it was not common for Canon firmware to provide one.
Yes.
Quote
  But I'm guessing every D6 camera will include a Canon histogram so maybe it could be dropped from the D6 CHDK builds?
I'm not sure if this is true of the lower end D6 cameras. The SX280 manual only mentions the playback histogram.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3316
Re: Display (bitmap overlay)
« Reply #42 on: 20 / March / 2017, 21:40:45 »
I'm not sure if this is true of the lower end D6 cameras. The SX280 manual only mentions the playback histogram.
Correct, there's no live histogram in the sx280 (and, according to the manual, the followup models don't have it either).
Feel free to adjust the default position as you see fit in order to make a complete patch.
Items with "should be fixable" note will eventually get fixed sooner or later.
Quote
Is there any generic way we can make this patch work for all digic 6 cams without by hand changes for updates in the platform specific directory?
That would require a generic palette header for D6, probably in include/. The two stubs could go in stubs_entry.S (but I don't know the thumb2 sigfinder enough to do it).
One thing I did notice about the zebra on g7x is that I had to set the thresholds quite high (25+ for both over and under) to see the zebra, even when pointing at a light in a dark room.
This seems camera model dependent. The sx280 also needs high thresholds, but the sx60 and m10 do not.
« Last Edit: 20 / March / 2017, 21:54:29 by srsa_4c »

*

Offline reyalp

  • ******
  • 10244
Re: Display (bitmap overlay)
« Reply #43 on: 20 / March / 2017, 23:10:42 »
That would require a generic palette header for D6, probably in include/.
Since (as far as I understand) the palette code should be the same for all, that seems like it would be a good idea anyway.
Quote
The two stubs could go in stubs_entry.S (but I don't know the thumb2 sigfinder enough to do it).
I can add these quickly, but just for information:

Ones that already appear in the CSV, you should be able to just remove the UNUSED in sig_names. The OPTIONAL should also be removed if it's expected to be needed in every port. memset32 probably needs a new match type in sig_rules.
Don't forget what the H stands for.


Re: Display (bitmap overlay)
« Reply #44 on: 20 / March / 2017, 23:32:24 »
It might be safe to say memset32 equals bzero +4 since the sigfinder will find bzero matches anyway.

*

Offline reyalp

  • ******
  • 10244
Re: Display (bitmap overlay)
« Reply #45 on: 21 / March / 2017, 03:12:50 »
I added both to the sig finder.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3316
Re: Display (bitmap overlay)
« Reply #46 on: 25 / March / 2017, 14:46:16 »
Here's the latest version of the patch, adapted to current trunk.
The only change is that I've removed the useless camera specific platform_palette.c and platform_palette.h files and placed a generic d6 palette in platform/generic/palette.c (which is referenced in makefile_platform.inc).
No other platform changes are needed.

Re: Display (bitmap overlay)
« Reply #47 on: 25 / March / 2017, 16:53:47 »
Here's the latest version of the patch, adapted to current trunk.
Nice - I'm a fan !  New vs old on my G16.

Colors are better on this one - have not played with a custom palette for the G16.

Also, I wasn't able to get the d6_display_lores_on_sx280_v1.diff version to work well - looked like buffer sizes were wrong - so I gave up on that one.



*

Offline reyalp

  • ******
  • 10244
Re: Display (bitmap overlay)
« Reply #48 on: 26 / March / 2017, 02:11:02 »
I spent a bit more time looking at this.
The only think I think is a must-have before checking in is to ensure MD for pre-digic 6 cameras is not broken. I've attached an updated patch that uses two completely separate implementations of md_detect_motion. Tested OK on G7X and SX160.

The updated patch also cleans up some trailing whitespace that caused extra noise in the histogram diff, removes the unneeded vid_get_bitmap_active_palette from G7X.

I tested the histogram R G B displays using the same test page I used for MD, seems OK.

I would prefer the unrelated OSD rotate fix be checked in separately.


Other thoughts (nothing that needs to be addressed before checking in)

direct access to things like bitmap_buffer[active_buffer_index] in gui_draw.c concern me a bit, because the logic required to get the current buffer could easily change in future cameras. Wrapping in a lib.c function lets ports handle that, at the cost of function call overhead.

An alternate approach would be to have a CHDK variable that is only updated at defined points: e.g. before every gui redraw, and/or every kbd_task iteration. The canon firmware swapping buffers in the middle of a gui_redraw could cause some parts to be drawn on the "wrong" buffer, but I'm not sure how bad it would be in practice. A better solution would be to find a way to hooked into something that gets called when the canon firmware actually swaps buffers. Being able to use the current buffer directly without any index etc could provide a slight performance benefit.

platform dependent #defines in module code are proliferating, specifically the font size stuff. This technically OK if it only depends on THUMB_FW, but it's going to be easy to forget and accidentally make a change that makes the modules no longer platform independent.

register is almost certainly ignored by the compiler, and if it's not, is very likely to do more harm than good (I know existing code uses it too).

Using THUMB_FW to represent both the instruction set and display architecture also seems likely to bite us in the future. I have ideas about this, but it's probably a topic for another post.

Quote
- The CHDK boot logo doesn't display correctly, the bitmap part is unscaled and misplaced. Should be fixable.
A simple workaround would be to just disable the logo and have the text only splash screen.

jog dial control in the OSD editor is added, should be documented.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 3316
Re: Display (bitmap overlay)
« Reply #49 on: 26 / March / 2017, 21:08:45 »
Thanks for the comments.
Also, I wasn't able to get the d6_display_lores_on_sx280_v1.diff version to work well - looked like buffer sizes were wrong - so I gave up on that one.
I agree that setting up the required display dimensions for the lo-res "rework" is a bit frustrating - the sx280 parts of that patch were meant to give hints on what to do.

The only think I think is a must-have before checking in is to ensure MD for pre-digic 6 cameras is not broken. I've attached an updated patch that uses two completely separate implementations of md_detect_motion. Tested OK on G7X and SX160.
Did the CHDKPTP based test on the sx280 and checked that motion is still detected on the ixus115. It was not a very thorough test though.

Quote
An alternate approach would be to have a CHDK variable that is only updated at defined points: e.g. before every gui redraw, and/or every kbd_task iteration.
I actually tried something similar to this earlier, on the sx280.
First attempt was to read and store the current buffer in a spytask hook (the get_mode one). It did not work at all - hook was called before vid_bitmap_refresh() request in spytask, which flipped buffers and most of drawing went into the wrong buffer.
Second attempt was reading current buffer in vid_bitmap_refresh(), after the busyonscreen procedures. This one worked better, but was not 100% reliable.
Did not try doing it from a different task (or a timer).
Quote
platform dependent #defines in module code are proliferating, specifically the font size stuff.
Unfortunately, font size is hardcoded (using macros) rather than being part of some camera_info structure. I did not feel like changing that at this moment - it could easily affect some calculations and compile time optimizations.
Quote
This technically OK if it only depends on THUMB_FW, but it's going to be easy to forget and accidentally make a change that makes the modules no longer platform independent.
That happened already - some games look now quite broken due to unexpected font size.
Quote
Using THUMB_FW to represent both the instruction set and display architecture also seems likely to bite us in the future. I have ideas about this, but it's probably a topic for another post.
I was using a separate #define for yuv overlay before the D6 support was integrated in trunk. I chose to remove it at one point (the sx280 was the only D6 port at that time).
Quote
jog dial control in the OSD editor is added, should be documented.
I only put that in because I wanted to use something that could replace the missing zoom buttons on my M10. Could probably stay because it can be operated faster than the zoom/halfshoot buttons.

 

Related Topics