G7 X porting thread [G7_X]

reyalp

Updated build (r4682) posted https://chdk.setepontos.com/d/12692/8

* Includes preliminary PTP live view support https://chdk.setepontos.com/d/6231/895
* Fixes false triggering in motion detection

hiker_jon

Hi,
Just tried out r4682 on my G7X. It booted, but has a problem with alt mode. Sometimes it boots up in alt mode, sometimes not. I cannot get in or out of it by short press on video button. Is is some other button or combination? I also tried turning on edge display, since getting the address of the image buffers is my interest in this camera. It sort of worked: clearly the buffer size is wrong but the edge display seemed somewhat related to the image. I would like to help find out the image buffer addresses and would appreciate any help pointing me in the right direction.

Jon

Ant

hiker_jon
would appreciate any help pointing me in the right direction

Try this: edgeoverlay.c

hiker_jon

Another problem for me is that I have the old windows GUI environment and need to figure out how to compile in whatever new system exists.

msl

hiker_jon
Another problem for me is that I have the old windows GUI environment and need to figure out how to compile in whatever new system exists.

Maybe this helps: https://chdk.setepontos.com/d/12752

msl

reyalp

hiker_jon
Just tried out r4682 on my G7X. It booted, but has a problem with alt mode. Sometimes it boots up in alt mode, sometimes not.

CHDK should never start in alt mode, and I have not seen it do so on G7X.

I cannot get in or out of it by short press on video button.

The default alt button is the playback button, not video.

I also tried turning on edge display, since getting the address of the image buffers is my interest in this camera.

It's not just a matter of buffer addresses or sizes, the code needs to be re-written to take into account the different viewport and display buffer formats. I believe that Ant did some work on this, but I don't know what state it is in. See https://chdk.setepontos.com/d/12542/118

hiker_jon

Hi,
I commonly turn on the camera using the play button. I think that causes it sometimes to open in alt mode.
I changed the alt button to video to avoid this.
Jon

hiker_jon

I've been looking at the display buffers in PLAY mode. There seem to be two buffers. The first to be displayed (when I start the camera in play mode) is
vid_get_viewport_active_buffer() (same as vid_get_viewport_fb_d(), 0x5e608000 ). This buffer gets used for every other image display. I don't know the address for the other one. I tried writing into vid_get_viewport_fb(), 0x43334300. This seems to mess up future displays, but is not alligned with the images.

I'm confused about writing into vid_get_viewport_fb(), doesn't always seem to change the future displays, but do think that there are two display buffers.

reyalp

hiker_jon
I've been looking at the display buffers in PLAY mode. There seem to be two buffers. The first to be displayed (when I start the camera in play mode) is
vid_get_viewport_active_buffer() (same as vid_get_viewport_fb_d(), 0x5e608000 ). This buffer gets used for every other image display.

As far as I know, the vid_get_viewport_fb_d() in the current SVN is correct.

I'm confused about writing into vid_get_viewport_fb(), doesn't always seem to change the future displays, but do think that there are two display buffers.

In general, CHDK does not write into the viewport buffer, we use the bitmap/UI buffers like the Canon UI does. What are you expecting to accomplish by doing this? The functions to get the buffer are implemented to provide the most recent buffer for display, MD etc., not a buffer to write to.

On Digic 6, the bitmap buffer is full color, so there's even less possible reason to write to the viewport.

edit:
See the sx60 thread https://chdk.setepontos.com/d/12532/501 for some discussion of vid_get_viewport_fb_d()

hiker_jon

Hi,
I will look at the sx60 stuff.
I want to modify the image shown: for instance show a stereo pair using side by side or anaglyph or do some image processing on the image, like sharpen it. This used to be possible in CHDK.
I can write to the buffer vid_get_viewport_fb_d(). This works fine (at least the buffer can be modified, I am not sure of the colors) for every second displayed image.

What do you mean by "full color". For the bitmap? Is the viewport encoding not UYVY 4 bytes for 2 pixels? Is the color a different format from the old UYVYYY format? I think I am seeing this.

Jon

reyalp

hiker_jon
Hi,
I will look at the sx60 stuff.

To be clear, the buffer suggested for vid_get_viewport_fb_d in that thread is implemented in the current svn G7X code.

I want to modify the image shown: for instance show a stereo pair using side by side or anaglyph or do some image processing on the image, like sharpen it. This used to be possible in CHDK.

You mean in custom code you wrote? It has certainly never been a feature of mainline CHDK, and I don't recall ever seeing source for such a feature.

I can write to the buffer vid_get_viewport_fb_d(). This works fine (at least the buffer can be modified, I am not sure of the colors) for every second displayed image.

What do you mean by "full color". For the bitmap?

In cameras before digic 6, the canon UI used a paletted display, with 256 (or less) possible colors, so displaying something like a camera jpeg was not practical. In digic6, it's a full UYVY in the same format as the viewport, plus an alpha buffer.

Is the viewport encoding not UYVY 4 bytes for 2 pixels? Is the color a different format from the old UYVYYY format? I think I am seeing this.

Yes, it's UYVY (two Y values per UV pair rather than 4). For most buffers (the viewport and bitmap used by the G7X) port, it is also in a different format: you have to subtract 0x80 from the U and V values when converting to RGB.

Reading up through some of the general digic 6 related threads might save you some time.

Thread about digic 6 display https://chdk.setepontos.com/d/12788

sx280 porting thread (first digic 6 port, by srsa_4c) https://chdk.setepontos.com/d/11550

General CHDK/D6 https://chdk.setepontos.com/d/11316 (old, might want to start at the end)

Discussion of PTP live view in chdkptp (starting around https://chdk.setepontos.com/d/6231/849, recently added to trunk https://chdk.setepontos.com/d/6231/895)

hiker_jon

I guess it has been a long time. For old cameras I would read the u as follows:u = (signed char)src;
What should I change? maybe: u = (unsigned char) src - 128?
Why would Canon change this?

I will have time to look more at the videwport bufs next week.
Jon

reyalp

hiker_jon
What should I change? maybe: u = (unsigned char) src - 128?

It depends what you are doing, the subtracting 128 applies to converting to RGB. For that, you can see an example at https://app.assembla.com/spaces/chdkptp/subversion/source/712/trunk/liveimg.c#ln296

https://en.wikipedia.org/wiki/YCbCr may provide some insight.

Why would Canon change this?

You'd have to ask them 😉

jochemlaÂ²

srsa_4c

jochemlaÂ²
I would like to try out your CHDK on my G7X. Its firmware version is 100c instead of 100d, and I cannot launch the CHDK from "Firm update". Do you know if the migration is easy to do - if you explain it to me, I could be able to do it. I could not find how to switch from 100c to 100d for my G7X either.
AFAIK you're the first person reporting a 100c firmware revision. Please make a dump of your camera's firmware: http://chdk.wikia.com/wiki/Canon_Basic/Scripts/Dumper

Hello. With a little delay, here is the firmware dump https://drive.google.com/open?id=0B3QGa8gm4F_TMEhtVFVBaUluTHc
I've tested with the Update firmware menu when starting camera in Play mode, and the green led blinks continuously without ever showing the chdk logo. I've also tested the "lock sd card" install, but then the camera starts in normal mode, and says the card is not writable. Thanks a lot!

reyalp

jochemlaÂ²
Hello. With a little delay, here is the firmware dump https://drive.google.com/open?id=0B3QGa8gm4F_TMEhtVFVBaUluTHc

Thanks. From a quick look it appears 100c is not quite compatible with 100d (all the functions we use are the the same places, but some ROM data has moved), so a new sub port will be needed. I will post a test build when I get a chance, but I'm not sure how much time it will take.

I've tested with the Update firmware menu when starting camera in Play mode, and the green led blinks continuously without ever showing the chdk logo.

There is code that does this if it detects an different version than the build was created for. Nice to know it works 😀

I've also tested the "lock sd card" install, but then the camera starts in normal mode, and says the card is not writable. Thanks a lot!

This means that the card was not actually made bootable. Most likely the canon BOOTDISK string isn't set correctly, or the card is formatted exFAT rather than FAT32. In any case, there's no need to worry about this until there is a build for your firmware version.

reyalp

edit: See https://chdk.setepontos.com/d/12692/85 for the latest 100c build.

Here's a test build for g7x firmware 100c.

This is completely untested, although it's very similar to 100d so there's a fair chance it will work. See the "G7 X notes" section of the included readme for known issues that apply to the G7X port in general.

I strongly recommend using the bootable SD card method to load CHDK for actual shooting, as the "Update firmware" method does not appear to initialize some hardware correctly.

Using the "Update firmware" to load CHDK and make FAT 32 formatted card bootable seems to be OK.

hiker_jon

Hi,
I've looked into some of the buffers used to hold viewport data on the G7X in play mode.
If unzoomed the camera used either 0x5e608000 (first image displayed) or 0x5e208000 (second image displayed) and alternates them.
If you zoom and pan then other buffers are also used.
I looked at these:
edit: Corrected these addresses
0x5e208000; // used for 2nd unzoomed display and every other after (unless a zoom happens)not used for zoom, pans (as far as I can tell)
0x5e608000; // used for 1st unzoomed display, some zooms, pans
0x5ea08000; // some zooms, pans
There may be other ones used as well.

The big problem is how to find out which one the camera is using. Any suggestions how to find this out?

Jon

reyalp

hiker_jon
The big problem is how to find out which one the camera is using. Any suggestions how to find this out?

On my g7x, the current svn implementation of vid_get_viewport_fb_d() appears to return the correct playback buffer in pretty much every situation, as verified by using chdkptp live view.

If you explain in what way you believe this is wrong, that might help.

In my earlier investigation, I found some other variables that contained recent, but not entirely up to date buffers, see https://chdk.setepontos.com/d/12532/500

0x5e208000; // used for 2nd unzoomed display and every other after (unless a zoom happens)not used for zoom, pans (as far as I can tell)
0x5e608000; // used for 1st unzoomed display, some zooms, pans
0x5ea08000; // some zooms, pans
0x5ea08000; // some zooms, pans

IMO, it's extremely unlikely that these are specific to zoom, pan etc. More likely, the camera rotates through a sequence of buffers, and some variable points the current buffer or indexes an array of buffer addresses.

edit:
I understand from the previous posts you want to write to the buffer, but if it contains the most recent data and writing does not have the desired effect, it's seems like getting the current buffer may not be your problem.

hiker_jon

Hi,
Another way to check is to turn on the histogram display. The histogram it displays may be wrong, but it does reflect the buffer data it is accessing.
Notice that it repeats and does not show a unique histogram for each image.

I am using trunk 4685

Jon

reyalp

hiker_jon
Another way to check is to turn on the histogram display. The histogram it displays may be wrong, but it does reflect the buffer data it is accessing.

Unless you have re-written the histogram code for d6, I wouldn't use it for anything.

I am using trunk 4685

Try the version from r4690. You could have saved both of us some time by looking at the svn log or svn blame to see when that code changed.

« Previous Page Next Page »