keogram --image-expand

[pablo-blake]

Hello,

I was looking to make my keograms wider and came across the wiki section describing the use of the keogram executable.

keogram -d imagedir -e ext -o outputfile [KEOGRAM_EXTRA_PARAMETERS]

-x | --image-expand : expand image to get the proportions of source

I tried:
./keogram -d ./images/20220104/ -e jpg -o ./images/20220104/keogram/keogram-20220104-wide.jpg --rotate 0 --font-size 1.0 --font-line 1 --font-color '255 255 255' --image-expand

and

./keogram -d ./images/20220104/ -e jpg -o ./images/20220104/keogram/keogram-20220104-wide.jpg --image-expand --rotate 0 --font-size 1.0 --font-line 1 --font-color '255 255 255'

along with variations using "-x" instead of --image-expand.

keogram executes and generates jpg output; however, image is still 759 x 976 (tall & skinny). Original jpgs are 1304 x 975.

I'm presuming there is an issue with my syntax.
Any suggestions on the proper usage of '--image-expand' in [KEOGRAM_EXTRA_PARAMETERS] ?

Thanks, Paul

[EricClaeys]

@pablo-blake Try creating a directory called allsky/images/test, then copy a half-dozen images from yesterday (allsky/images/20220111) to the "test" directory". Then remove "--image-expand" from the KEOGRAM_EXTRA_PARAMETERS, then run cd allsky; scripts/generateForDay -k test. Look at the keogram it created in images/test/keogram. Then add "--image-expand" to KEOGRAM_EXTRA_PARAMETERS" and run generateForDay again. See if the new keogram looks any different. If it does, it's working correctly.

[pablo-blake]

@EricClaeys,

Thanks for suggesting a test w/fewer images.

The syntax I used was OK; however, '--image-expand' does not increase horizontal scale if the number of frames is greater 1/2 the number of horizontal pixels in the original images. Below is a summary of some keograms I generated using a range of image frames. Keogram code likely uses a whole number (x) multiplier to increate image width. Guessing a code change would be the only way to force a minimum multiplier factor of 2.

Examples for 599 & 659 frame keograms (using '--image-expand') are attached. Due to html stretching, the tall skinny image is not obvious (need to click link).

example syntax used:
./keogram -d ./images/test_keo -e jpg -o ./images/test_keo/keogram/keogram-20220104-wide-60img.jpg --font-size 1.0 --font-line 1 --font-color '255 255 255' --image-expand

======================
summary: test keogram option '--image-expand'
input img size -> 1304 x 976
60 images no--image-expand -> 60 x 976
60 images w/--image-expand -> 1260 x 976 - expanded - 60 x21 ->1260
120 images w/--image-expand -> 1200 x 976 - expanded - 120 x10 ->1200
240 images w/--image-expand -> 1200 x 975 - expanded - 240 x5 ->1200
419 images w/--image-expand -> 1257 x 975 - expanded - 419 x3 ->1257
599 images w/--image-expand -> 1198 x 975 - expanded - 599 x2 ->1198
659 images w/--image-expand -> 659 x 976 - not - 659 x1 -> 659
759 images w/--image-expand -> 759 x 976 - not - 759 x1 -> 759

code may calculate a whole number (x) for scaling when the '--image-expand' argument is used
x = largest whole number where 'Num_frames(x) < input_image_x_px-cnt'

source not looked at - above is just a guess

======================

[pablo-blake]

I don't code CPP, but below looks like the expander function (column multiplier).

// expand ?
if (cf->img_expand) {
cf->num_img_expand = std::max(1, (int) (imagesrc.cols / (float) nfiles));

Updating to 'num_img_expand = std::max(2, (int) (imagesrc.cols / (float) nfiles))' would provide a min increase of 2x ?

[EricClaeys]

@pablo-blake Sorry for the late response. I didn't make the changes to keogram so am not very familiar with it.
One way to see if your idea works is to change the code and run

cd src
make keogram
cp keogram ..
../scripts/generateForDay -k DATE   # where DATE is a directory in allsky/images.

@AndreasLMeg, did you make the --expand-image changes to keogram.cpp?

[pablo-blake]

HI Eric,

Change worked - looks like a winner.
If '--image-expand' argument is used for keogram command, there is a minimum increase of 2x.

Appreciate the advice and quick tutorial on compiling.

update
cf->num_img_expand = std::max(2, (int) (imagesrc.cols / (float) nfiles));

orig
cf->num_img_expand = std::max(1, (int) (imagesrc.cols / (float) nfiles));

Tested a few cases where (imagesrc.cols / nfiles) >= 2, and keogram behavior appears unaffected by function change (a good thing).

summary: test keogram option '--image-expand' w/min increase of 2x
419 images w/--image-expand -> 1257 x 975 - expanded - 419 x3 ->1257
599 images w/--image-expand -> 1198 x 975 - expanded - 599 x2 ->1198
659 images w/--image-expand -> 1318 x 976 - expanded - 659 x2 ->1318 - 659 images did not expand before update

Thanks, Paul

[AndreasLMeg]

@pablo-blake yes i made this extension "expand".

Sorry, I'm a bit stressed and can't take care of it right away. After a quick read, I still can't understand your problem (English is not my mother tongue)

But I'll look at that over the weekend

[AndreasLMeg]

@pablo-blake @EricClaeys

this code change will bring you better results. (untested)

Is it possible for you to test this code change ?

		// expand ?
		if (cf->img_expand) {
			cf->num_img_expand = std::max(1, (int) (imagesrc.cols / (float) nfiles));
			if (((float)(cf->num_img_expand * nfiles) / imagesrc.cols) < 0.8) // minimal size 0.8 * imagesrc.cols 
				cf->num_img_expand++;
		}

[pablo-blake]

Hi Andreas,

Apologies for not getting around to test your change - sometimes the day job gets in the way of my hobbies. Your response was much appreciated - danke.

Looks like your function increases num_img_expand by 1 if '((num_img_expand * nfiles) / imagesrc.cols) < 0.8' ? Is that correct? I do most of my script writing in Perl & bash, but I think I'm understanding the C++ function.

Is it basically the same as:
cf->num_img_expand = std::max(2, (int) (imagesrc.cols / (float) nfiles));

I think the original function was OK unless 'imagesrc.cols / (float) nfiles < 2'. In that case, num_img_expand = 1, and no expansion is done. This is why I think I was getting tall skinny keograms ( 1304[img-cols]/659[files]) = 1.97 -> (int)1.97=1 ).

Thanks & Take care, Paul

[AndreasLMeg]

@pablo-blake
I don't want to lose any information, so I have to use a multiple of the number of images. With a large number of images, however, an ugliness occurs: suddenly the keograms are only half as wide again.

With this change I have now limited the minimum size to 80% of the original image. That gives very nice results.
Should I make the adjustment like this?

[pablo-blake]

Hi Andreas,

Appreciate your time and effort. I agree, you would want to use a integer as a multiplier so that no data is lost.

I'm trying to understand the "ugliness" when the number of images becomes large. Is this displayed in the image you attached? ...they all seemed to look OK, except the tall skinny one (...without.jpg).

I presume that if the numberOfImages was close to the number of cols and this:
cf->num_img_expand = std::max(2, (int) (imagesrc.cols / (float) nfiles));
function was used, you would get a short wide keogram (2x multiplier).
Is this the "ugliness" you were referring to? ... and the reason for the '< 0.8' ratio test?
if (((float)(cf->num_img_expand * nfiles) / imagesrc.cols) < 0.8) cf->num_img_expand++;

It's also possible that someone is using '--image-expand' because they want wider keograms, even if they are 2x wider that their height.

Thanks again, Paul

[AndreasLMeg]

I'm trying to understand the "ugliness" when the number of images becomes large. Is this displayed in the image you attached? ...they all seemed to look OK, except the tall skinny one (...without.jpg)

Without means: starting keogram without -x parameter

It's also possible that someone is using '--image-expand' because they want wider keograms, even if they are 2x wider that their height.

The number and height of the images are variable.
A review of the available Allsky pages showed me that this usually led to "bad" images.
That's why I had the idea of ​​taking the ratio of the original image as an ideal and just filling in the image. A good compromise I think.

[pablo-blake]

Hi Andreas,

I agree with your conclusion - a ratio is a good compromise, and an improvement one the current --image-expand function. The ratio could be a variable with a default of 0.8 ( config.sh ?), if additional flexibility would be useful.

Thanks again for your feedback.

Take care, Paul

[EricClaeys]

@pablo-blake @AndreasLMeg
How many people would benefit from having the ratio be variable? We would need to add an argument and document it somewhere in order to be useful. We don't have manual pages so putting something in the Wiki would be best. But given that it was just brought up for the first time in a few years my gut says it's not worth the extra effort to make the ratio variable.

Are there any other code changes needed for this item?

[pablo-blake]

@EricClaeys

Hi Eric,

@AndreasLMeg suggestion is the only code update to keogram.cpp I'm aware of: keogram --image-expand
#909

Let me know if you need me to test his suggested update - my testing was done on the initial update I suggested (no ratio test - min expansion of 2x). However, based on Andreas's reply, it appears he tested his suggested update.

my test ->
// expand ? if (cf->img_expand) {cf->num_img_expand = std::max(2, (int) (imagesrc.cols / (float) nfiles)); }

Andreas suggested update to keogram.cpp (ratio test, only expand if <0.8) ->
// expand ? if (cf->img_expand) { cf->num_img_expand = std::max(1, (int) (imagesrc.cols / (float) nfiles)); if (((float)(cf->num_img_expand * nfiles) / imagesrc.cols) < 0.8) // minimal size 0.8 * imagesrc.cols cf->num_img_expand++; }

Thanks for the help, Paul

[AndreasLMeg]

@pablo-blake PR is merged #964

With this change you will get other results: min. size = 1304 *0.8 = 1043
input img size -> 1304 x 976
60 images no--image-expand -> 60 x 976
60 images w/--image-expand -> 1260 x 976 - expanded - 60 x21 ->1260
120 images w/--image-expand -> 1200 x 976 - expanded - 120 x10 ->1200
240 images w/--image-expand -> 1200 x 975 - expanded - 240 x5 ->1200
419 images w/--image-expand -> 1257 x 975 - expanded - 419 x3 ->1257
599 images w/--image-expand -> 1198 x 975 - expanded - 599 x2 ->1198
659 images w/--image-expand -> 659 x 976 - not - 659 x1 -> 659 --> new: 1318
759 images w/--image-expand -> 759 x 976 - not - 759 x1 -> 759 --> new: 1518

[AndreasLMeg]

@pablo-blake
Hi Paul,

With change (min=2) you will get other results:
input img size -> 1304 x 976
60 images no--image-expand -> 60 x 976
60 images w/--image-expand -> 1260 x 976 - expanded - 60 x21 ->1260
120 images w/--image-expand -> 1200 x 976 - expanded - 120 x10 ->1200
240 images w/--image-expand -> 1200 x 975 - expanded - 240 x5 ->1200
419 images w/--image-expand -> 1257 x 975 - expanded - 419 x3 ->1257
599 images w/--image-expand -> 1198 x 975 - expanded - 599 x2 ->1198
659 images w/--image-expand -> 659 x 976 - not - 659 x1 -> 659 --> new: 1318
759 images w/--image-expand -> 759 x 976 - not - 759 x1 -> 759 --> new: 1518
so far so good. the same results

but for long nights/shorter intervalls/more images you may have the problem with too wide images
1000 images w/--image-expand -> 2000 x 976 - expanded (min. 2): 2000 (my solution): 2000
1100 images w/--image-expand -> 2200 x 976 - expanded (min. 2): 2200 (my solution): 1100
2000 images w/--image-expand -> 4000 x 976 - expanded (min. 2): 4000 (my solution): 2000

I think my solution (#964) is the better compromise to get nice pictures (not too thin and not too wide)