Templates, filtering and image sizes

[maehw]

While browsing the self-o-mat code and where I may want to place changes, I've developed some diagrams which describe the software architecture (or my understanding of it) as well as the image processing chain. This is what I came up with for a combination of

self-o-mat/src/logic/ImageProcessor.cpp

Line 66 in af62ea5

ImageProcessor::frameImageForPrint(void *inputImageJpeg, size_t jpegBufferSize, FILTER filter, double filterGain) {

and

self-o-mat/src/logic/ImageProcessor.cpp

Line 164 in af62ea5

ImageProcessor::decodeImageForPrint(void *inputImageJpeg, size_t jpegBufferSize, FILTER filter, double filterGain) {

I have some remarks/questions which I'd be happy if someone commented on (most likely you, @ClemensElflein ):

1. When using templates. Does the applyFilter function call really work as expected?

   self-o-mat/src/logic/ImageProcessor.cpp

   Line 129 in af62ea5

   applyFilter(decodedImage, filter, filterGain);

   -- Shouldn't variables result or decodedImageROI be used to apply the filter? In my understanding decodedImage won't be used anymore. Can you confirm? (Maybe it just did not pop up because the default filter is not very prominent.)
2. Why did you call it "compression" here? I think it's "just" applying the alpha channel of the template... or blending template and resized image together... - nothing is really "compressed" here, right?

   self-o-mat/src/logic/ImageProcessor.cpp

   Line 153 in af62ea5

   LOG_D(TAG, "Compression Took", std::to_string(((double) tend.tv_sec + 1.0e-9 * tend.tv_nsec) -

3. When no template is applied, the target size is 1773 pixels x 1182 pixels (hard-coded) -- that's a perfect aspect ratio of 1.5 (or 3:2). Assuming 300 dpi printers, this yields 5.91" x 3.94"print size. However, we've documented that the "Hagaki" format ("postcard") has 148 mm x 100 mm or 5.83" x 3.94". Do you see a problem in the .2mm difference? Not too many pixels lost probably.. but do you think this will cause the printer to re-scale unnecessarily?
4. I've never used templates before, but I'd like to give them a try. In https://github.com/xtech/self-o-mat/wiki/Configuration#templates we started documenting them in the wiki. How are the other hard-coded values related?

   self-o-mat/src/logic/ImageProcessor.cpp

   Lines 273 to 274 in af62ea5

   	float widthFactor = 1864.0f / image.cols;
   	float heightFactor = 1228.0f / image.rows;

   -- Yet another slightly different aspect ratio (approx. 1.518). 1864 pixels x 1228 pixels seems to be "the perfect size" and would match the template file you provided once, but why this size?

I'd be happy if we could make sense out of these numbers.

[ClemensElflein]

It has been some time, so I might be off about some of the things, so forgive me if anything doesn't seem to make sense. The drawing looks good to me.

1. Yes looks like you are right - this would mean that filtering in combination with the Template is not working as expected
2. Good question, this indeed does not do any compression at all. It combines template and image, must be an old log or copy/paste mistake.
3. I'm not sure where this number came from, sorry. Is it really 0.2mm difference or is it 2mm difference? In my head the most common picture format is 10x15 cm, so if it's 2mm difference I probably did 10x15 cm format (now that I'm reading up on it, it doesn't seem to be exactly 15x10 cm after all, but it would explain why those numbers are there).
4. If I remember correctly, these pixels are the screen resolution of the provided LCD of the self-o-mat boxes. The scaling was done in a way, that the template matches the screen's width or height (or both, if aspect ratio was correct).

Hope any of that helps

[maehw]

Hi Clemens,

thanks for your (always!) fast and helpful reply!

3. Indeed, 5.91" - 5.83" = 0.08" = 0.2032 cm or around 2 mm - so that might make sense that you assume 150 mm x 100 mm (instead of 148 x 100)
4. Unfortunately, no. The screen size is 1280 pixels x 800 pixels (see also https://github.com/xtech/self-o-mat/wiki/Hardware#screens); this can be seen in taking a larger snippet from the code linked above:

   self-o-mat/src/logic/ImageProcessor.cpp

   Lines 271 to 284 in af62ea5

   	{
   	// TODO: Remove Hardcoded Size
   	float widthFactor = 1864.0f / image.cols;
   	float heightFactor = 1228.0f / image.rows;
   	float factor = std::fmax(widthFactor, heightFactor);
   	cv::resize(image, imagePrint, cv::Size(image.cols * factor, image.rows * factor));
   	}
   	{
   	// TODO: Remove Hardcoded Size
   	float widthFactor = 1280.0f / image.cols;
   	float heightFactor = 800.0f / image.rows;
   	float factor = std::fmax(widthFactor, heightFactor);
   	cv::resize(image, imageScreen, cv::Size(image.cols * factor, image.rows * factor));
   	}

[ClemensElflein]

You are right, it has the screen one separately. So I think there's really no reason for the different resolution