Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support rgb files #8

Merged
merged 3 commits into from
Feb 3, 2015
Merged

Support rgb files #8

merged 3 commits into from
Feb 3, 2015

Conversation

bennoleslie
Copy link
Collaborator

This supports loading RGB files (rather than just RGBA files).

It isn't great. It converts things to RGBA internally, rather than tracking the format type. Additionally, it is kind of slow as the rgb2rgba isn't exactly fast.

Despite these limitations it does provide functionality that at least one user (me!) needs, and shouldn't impact anyone not using the feature.

There is a relatively simple test accompanying the changes.

Support for RGB only (as opposed to RGBA) images is desired.
This provides a baseline to test support against.

The assumption is that when loading an RGB image it will be
converted to the internal RGBA format. This provides a good
baseline of support without needing to change other parts
of the module.

In the future the color type (RGB vs RGBA) may be supported
directly and preserved with a round-trip, however that is
beyond the scope of initial support.
for i in range(0, len(rgb), 3):
rgba += rgb[i:i+3]
rgba.append(255)
assert len(rgba) == len(rgb) / 3 * 4
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather not use assert in production code.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly is the concern with using assert? I can remove it, but I don't think the performance advantage of removing it is really worth it. I think it adds some useful documentation, and helps to make sure any modifications to the function internals don't break stuff.

But if it is a big concern I can just remove it.

@BYK
Copy link
Collaborator

BYK commented Feb 2, 2015

Would you mind making the changes I suggested?

1. Removed unwanted assert
2. Added numeric constants for PNG color types.
3. Added data structure for supported types.
4. Slight rework of main loading loop to make logic clearer.
step_size = 1 + row_size
bytes_per_pixel = SAMPLES_PER_PIXEL[color_type]
bytes_per_row = bytes_per_pixel * width
bytes_per_rgba_row = SAMPLES_PER_PIXEL[COLOR_TYPE_TRUECOLOR_WITH_ALPHA] * width
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, now I understand why you need both. I missed a few things in the previous version. You may want to add a comment here saying "We need the RGBA length regardless since we cast RGB to RGBA".

@BYK
Copy link
Collaborator

BYK commented Feb 3, 2015

I think this looks good enough so I'm gonna merge. You can do any improvements based on my suggestions in a follow-up.

Thank you very much for all your efforts!

BYK added a commit that referenced this pull request Feb 3, 2015
@BYK BYK merged commit 4b8c67f into rcarmo:master Feb 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants