antmicro-labs / raw-image-data-previewer Goto Github PK

It would be nice to make it possible to append or remove n bytes from the beginning of the image.

This could help interpret images for which the capture started in the middle of a line.

When one tries to upload new picture in to the utility and aborts this action by closing the file choosing dialog, exception is thrown and application now longer works.

Please, try to fix that.

The group chose python to implement the application.

That means we need to check the python code for potential issues each time something is added to the repository.

The goal of this task is to add automatic code checking. Consider using yapf or flake8.

For example you could run:

python3 -m yapf -p -i <list of python files>
test $(git status --porcelain | wc -l) -eq 0 || { git diff; false; }

in the CI.

This depends on #2.

There are some issues with GUI attributes previewing.

TODO:

• disable HEIGHT property - user should not be able to change it and it should be updated with loaded image properties
• add event listener to color format property dropdown - right now it doesn't update properly

See: https://docs.github.com/en/actions

Make sure to trigger the CI on push (to master) and on PRs.

As there is no code yet it can run a simple echo "hello world" and exit. The goal here is to prepare the infrastructure to run actual tests at a later stage.

The first usecase for this feature would be to simply display the dimensions of the selected area.

Additionally, it would be nice to be able to export only selected area (both as raw data and as higher formats, like png)

it would be nice to have some rulers on the canvas (use pixels as the unit).

In addition it would be nice if mouse hover over the image would show its current coordinates (in image pixels, in relation to the top left corner of the decoded image)

For example, for RGB there could be three checkboxes: R, G, B.
They would be checked by default. Upon disabling any of them, the value for this channel for all pixels would be zeroed.

when zooming the images, it would be better to see sharp pixels.

This would make it easier to investigate the issues with the captured image.

At the moment, after zooming, the image looks like this:

Please take a look at opencv and imagemagick and their image transformation capabilities.

imagemagick can be used to generate test data for the application.

Currently our utility is started with a command consisting of at least file name to load.
It's ok, but we should also create a way to start application without providing ANY arguments - just start GUI with empty image frame.

TODO:

• remove height attribute from CLI - now only width should be provided (height is not used anymore)
• leave current way of starting utility, but make it OPTIONAL
• provide a way to start utility without providing ANY arguments (i. e. python -m app/)
• make it easy to add new CLI options like converting images that will be used WITHOUT starting GUI at all

Utility should be expanded by packed YUV color format support.

Color formats that should be implemented:

• UYVY
• YUY2
• and all other components order variations
• Should be considered - normally packed YUVs

Actually it depends on #17.

Define a basic data structure that will contain vital information about defined color format.

Info that should be included:

• color family (RGB, RGBA, BGR etc. - possibly an enum?)
• amount of pixel components (e. g. 3 for RGB)
• bits per every pixel component
• endianness
• pixel plane

At the moment there is a button that opens a new windows and displays the current format info. The size of the text with the information is pretty much the same as the button that opens it, so it would be better if the info was just displayed in the main window (instead of using the popup)

Enter a string literal in the width field, press enter, the console renders:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.9/tkinter/__init__.py", line 1892, in __call__
    return self.func(*args)
  File "/tmp/raw-image-data-previewer/app/gui.py", line 189, in <lambda>
    self.ent_width.bind('<Return>', (lambda _: self.update_image()))
  File "/tmp/raw-image-data-previewer/app/gui.py", line 60, in update_image
    elif int(self.ent_width.get()) <= 0:
ValueError: invalid literal for int() with base 10: 'asdas'

It should be caught and the warning window should be updated

Modify current CI environment so it runs Python tests located in tests/.

What can be used:

• unittest module and simple command
• pytest - it can also run unittest tests and overall is more powerful

Remember to include requirements.txt while setting up Python environment.

Proper README should be created and filled with descriptions of current functionalities and classes/modules.
Depends on #18 #17 and partially on #16, but can be prepared independently.

What should be included:

• short description of utility
• supported operating systems, color formats
• requirements (python etc.)
• installation process
• usage
• documentation of modules/classes

Add proper terminal usage functionality with argument parsing and help description.
For now there should be only one positional argument:

• path_to_file (the file which will be previewed)

Optional arguments that should be implemented:

• color format (with default value and, for now, only defined color formats possible)
• width and height (also with default value)

Of course color format and resolution are required arguments in our previewer, but making them optional will later make possible to start GUI, when providing only a positional argument.

Right now entire window is resizing to meet image resolution requirements. It works for average size frames, but becomes really hard to use when large width is provided.

Window should not resize with loaded frame. Frame on the other hand should be embedded in some kind of movable container (with mouse or with scrollbars). Additionally, user should be able to zoom parts of the picture.

Current unit tests does not use mocks, so they aren't actually "unit".
They should be refactored, so there is no dependencies on other classes.

That issue also includes refactoring CI - it should support tests with mocks!

Mocking library that should be used - pytest-mock

At the moment after changing the width all the pixels are recalculated.

This sometimes takes a very long time as the conversion algorithms do not seem to be optimal.

Changing the width should be instant, this can be achieved by not recalculating all the pixel data each time the width is changed - the old pixel data can be reused and only arranged differently (the data should be continuous in the memory anyway).

It would be nice to be able to change the width using a slider (set the max val to the width of 4k for example, but still allow bigger values in the text box).

We need to add graphical user interface to our utility.

Functionalities that MUST be implemented:

• choose input file (prompt)
• dropdown of implemented color formats
• input fields for width and height
• an overview of color format (all the details like pixel format or bits per component)
• editable fields for color format (it can be combined with color format overview) - user can edit/create own color format
• display of an image - it needs to be MOVABLE and ZOOM-ABLE

Future functionalities that CAN be implemented:

• prompt to convert file to higher format and save it (i.e. under File menu)

When it comes to GUI library I recommend choosing between:

• Kivy (MIT License)
• TKinter - built-in

Unfortunately we can't use PyQt, because it is GPL licensed (not compatible with Apache).

Before implementing entire interface I would recommend preparing some kind of mockup to show planned structure of the interface (just put it in this thread for us to discuss about).

Define image class - the core of entire utility.

Should contain:

• raw, unprocessed data (straight from a file)
• current color format (depends on #6)
• processed data (in current format)
• width and height set on parsing to current format

Define parsing utility from raw data to processed in chosen color format.

Current solution is an abstract class containing min. two methods - for parsing TO format and parsing to displayable format.
Then there should be classes for every color family (#6) overriding methods with their implementations.

Should contain:

• target color format
• parsing function (change unprocessed data to NumPy array in-line with the color format)
• function used to convert image from the color format to the displayable format (BGR3 for OpenCV?)

Returned value should be a new image object (depends on #7).

We could display pixel bytes when hovering it with a mouse.

We could display it both as raw data and as decoded rgb/yuv values where applicable.

There should be an option to save parsed frames in chosen color format to higher-level formats like PNG or JPEG.

TODO:

• implement converter from getDisplayable of parsed frame to PNG or JPEG
• arguments of converter could be output format (JPEG/PNG) and output file path
• add option of using it in CLI (proper starting option i. e. --convert or something like that)
  ! GUI SHOULD NOT BE STARTED WHEN USING THIS OPTION!

There should be some built-in color formats defined in our utility. Currently they are defined in image/color_format.py and I think they should stay there.
What color formats should be defined depends on #17.

There needs to be a way to retrieve ALL the defined formats. It can be an array or map, but in user interface there needs to be easy way to retrieve and use them (i. e. formats can be "private" and there would be a public array containing them).

It should be done ASAP, because #16 partially depends on it.

Right now image is updated when the user presses Update image button.
The button should be completely removed and updates should be performed every time user changes any of the frame attributes (color format, width or frame data - by loading new file).

We need to define, which color formats are supported by our utility. It will be useful for development purposes but mainly it will be an addition to documentation:

Structured color formats (color components ARE IN ONE BLOCK i. e. rrrbbbggg):

• these are easy to implement and parsing is quite universal
• a definition which pixel planes are supported
• a definition which pixel formats (ARGB, RGBA, BGR etc.) are supported
• user will be able to define their own

Unstructured color formats (color components are spread around pixel i. e. rbbbgggrr):

• are they supported at all?
• if yes, which ones are supported (parsing utility won't be universal so we must declare which ones will be available)
• user won't be able to define their own unstructured color format

YUV color formats:

• for now only packed (so we must implement at least UYVY and YUY2)
• we need to remember that they are packed differently than RGB-like
• user should be able to define their own (bits per component, endiannes etc.)

It needs to be consulted with company members, which formats should we focus on.

It would be nice to have a separate tab on which users can configure v4l2 cameras and gather frames directly.
Those frames could be then analyzed in raw-image-data-previewer - there would be no need to gather the frames and analyze them separately in some cases (assuming the software is run on the target device).

Hi @MaciejFranikowski and @Ty7ak

Please tell the remaining group members to adjust their github handles so that we can easily identify everyone (the current ones are not acceptable).

If they do not wish to change their github names, they can create new accounts.

We would like to create Github Projects board to organize tasks and then convert them to issues (for example kanban with extra columns).
Is it acceptable?
[during the meeting I said "Github Pages" - I don't even know why, but I actually meant Github Projects - sorry :( ]