A590IS porting...

ShubinPavel

Thank you. With the new firmware everything was fine

dvip

What does optional EXMEM support for A590 101b do?
Will we see some speed when saving DNG raw files? Or will it speed dark frame subtraction?

msl

No, this not a speedup feature. It's more for developers.

The normal memory of the camera is limited. With this function we can load CHDK in an area with more memory capacity. Read more about EXMEM here: https://chdk.setepontos.com/d/5980

msl

dvip

Ok, so it is more about exmem_heap allocation. Wish it could be used as a buffer to speedup raw processing... but I'm sure it isn't big enough.

Thanks msl!

dvip

One possible idea for this cam and chdk is to give the cameras Custom settings. Some sort of memory that can help the camera remember aperture, shutter speed and focal length. Something like C1, C2... from a menu.

dvip

When using http://www.rawtherapee.com/ (64-bit), I'm getting a border that looks like hotpixels when I load my chdk's DNGs into RawTherapee.

I wonder if this is normal. I see it more in night shots. I hope is not a chdk DNG problem or my A590IS 🙁.

dvip

The new RawTherapee fixed the problem! 😀

blackhole

Please,can someone explain to me why the option CAM_EV_IN_VIDEO is disabled in platform_camera.h for the A590 because it works well, or is there some hidden problem that I have not seen.
I tested the firmware 101b.

dvip

With the A590IS (a590-101b-0.9.9-1341-full.zip) If you set:

Override Subj. Dist. V [1]
Value Factor (mm) [1]

and half-press the cam sometimes crashes.

dvip

Another possible bug:

From time to time the cam takes an image with the wrong orientation.
The jpg is fine but not the raw file.
So I get a raw file with the wrong orientation. 🙁

waterwingz

dvip
From time to time the cam takes an image with the wrong orientation.
The jpg is fine but not the raw file. So I get a raw file with the wrong orientation. 🙁

I don't think RAW files have any orientation. They are just a dump of the camera's sensor buffer. There is no information stored with the RAW file to indicate anything about the camera's orientation. So if you turn the camera 90 degrees, the image in the RAW file will look like its 90 deg turned.

Just like an old film camera would.

I suspect that even the Canon jpg's are not oriented in the camera - the camera simply records the camera's orientation in the EXIF header and lets your PC software sort it out.

dvip

I know it is odd, waterwingz. But that's what I get sometimes.
And it has happened more than once.
I have opened the raw file with Rawtherapee, Ufraw and IrfanView and the same problem there with raw files. I have both the raw and the jpg file if you want them to see for yourself. The image was taken as it is in the jpg but the raw has the wrong orientation.

In the jpg's Exif I have:

Orientation - Top left

raw/jpg files:

http://www.box.net/shared/qyy8uncisi7gci9db3p8

philmoz

dvip
I know it is odd, waterwingz. But that's what I get sometimes.
And it has happened more than once.
I have opened the raw file with Rawtherapee, Ufraw and IrfanView and the same problem there with raw files. I have both the raw and the jpg file if you want them to see for yourself. The image was taken as it is in the jpg but the raw has the wrong orientation.

In the jpg's Exif I have:

Orientation - Top left

raw/jpg files:

http://www.box.net/shared/qyy8uncisi7gci9db3p8

Your sample raw file is actually saved in DNG format (even though it has a .CRW file extension), so you have the option for CHDK to save DNG files set.
There is an option in CHDK to change the raw file extension - if you set it to .DNG it will be less confusing.

Anyway CHDK gets the orientation sensor value from the camera and saves it to the DNG header - in the case of your sample the orientation is set to 8 (270 degrees).

Unless your orientation sensor is broken, the only thing I can think of is you lowered your hand very quickly after taking the shot thus putting the camera in a vertical orientation? It takes a little bit of time after you press the shutter before CHDK generates the DNG file header.

Phil.

dvip

>Unless your orientation sensor is broken, the only thing I can
>think of is you lowered your hand very quickly after taking the
>shot thus putting the camera in a vertical orientation? It takes a
>little bit of time after you press the shutter before CHDK
>generates the DNG file header.

Thanks for the tips, Phil.
Yes, the raw file is a DNG.
The cam or chdk has been doing this for about a year now
and it is hard to test because it doesn't happen all the time.
At one point I got 4 images like this in a row and
it seems to happen when taking several pictures.

The worse part is that I can't check the image at site
since the JPG looks just fine on the cam's LCD screen but the DNG is wrong.

dvip

Hi Phil,
Yep, this happens when lowering the hand, I tested it today, but it never did this with older chdk versions (from a year ago or so).
Any way to fix this?

dvip

Is there any way to download the zip file in this posting:

https://chdk.setepontos.com/d/2361/701

CHDK-a590-101b-0.9.8.zip

I like this one beacause it trims the DNG borders.

Or better yet, an updated version that does the same with the latest chdk.

dvip

I tested:

#define CAM_EV_IN_VIDEO 1

with a590-101b-1.0.0-1597-full.zip and it works 😀.
I find it useful since the A590IS tends to overexpose.
Shouldn't it be enable?

But noticed that I have a red hot pixel in my videos 🙁 Anyway to fix that?

rudi

Hi,

here is my investigation for bitmap overlay palette on A590-101b.
CHDKcam from ewavr use overlay palette on ram address 0x3D518, but newer cams use only alpha value 0x3 or 0x0. I found in ROM routine on 0xFFCCB53C a conversion part for overlay palette to RAM address 0x763C.

RAM dump on 0x3D518 (rec mode)

         A  Y  U  V
0x3D518: 00 00 00 00
0x3D51C: FF E0 00 00
0x3D520: FF 4D F6 4A
0x3D524: FF 9F 00 00
0x3D528: 7F 00 00 00
0x3D52C: FF 7B B4 B1
0x3D530: FF C0 94 0F
0x3D534: 7F 60 7B E2
0x3D538: 80 10 00 00
0x3D53C: 7F 28 00 00
0x3D540: FF 7A 00 00
0x3D544: FF 4D F6 4A
0x3D548: FF FF AA 19
0x3D54C: FF 80 5D B4
0x3D550: FF 97 E9 64
0x3D554: FF 00 00 00

RAM dump on convert address 0x763C

        V  U  Y  A
0x763C: 00 00 FF 00 
0x7640: 00 00 E0 03
0x7644: 5C F8 4D 03
0x7648: 00 00 9F 03
0x764C: 00 00 00 00
0x7650: 9E BE 7B 03
0x7654: 12 A2 C0 03
0x7658: DB 6B 60 00
0x765C: 00 00 10 00
0x7660: 00 00 28 00
0x7664: 00 00 7A 03
0x7668: 5C F8 4D 03
0x766C: 1F B5 FF 03
0x7670: A1 51 80 03
0x7674: 7D EC 97 03
0x7678: 00 00 00 03

Routine on 0xFFCCB53C can used to set a new palette. Attached is a example to change the white overlay color to orange (!!only for A590-101b). The orange color is cleared on each palette change eg. switch play/rec mode or show canon menu.

rudi

A590_setcolor_overlay_palette.lua

498b

dvip

Thanks for the poke() and call_func_ptr() examples, rudi. Very cool!
I wonder what else we could do in lua, those functions, and the A590IS-101b.

Today Canon came up with some new cams with AA batteries
but nothing with PASM like the A590IS... and the A650IS.
It looks like those times are gone 🙁
They are great cams and with chdk they are fantastic.
To get a new A590IS now is like $379 or more.

dvip

Color bug?

1. Go into Visual Settings
2. Select Cursor Background Color (default is red)
3. Select blue
4. Turn the cam off
5. Turn the cam on

The cam will now have a different color, not blue nor red 😀
I have always used the default red and white because of this.

« Previous Page Next Page »