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

Converters #47

Closed
wants to merge 24 commits into from
Closed

Converters #47

wants to merge 24 commits into from

Conversation

dietzc
Copy link
Member

@dietzc dietzc commented Sep 17, 2014

REVIEW NEEDED

@dscho I tried to implement Normalizers and Converters in a clean way, especially such that we can optimize each and every op. Can you please review, comment, etc on the design. I'm aware of the fact that the commit messages aren't perfect, but I really wanted to see progress while I'm here and we really have to discuss design issues. (I will clean up the history later of course :-))

You can start reviewing the design by following the examples provided in the ConvertIterableTest I guess.

Anyway: We also need to figure out a way to auto-generated e.g. fast variants of GenericScaleIterableRT (ArrayImg/PlanarImg etc, for all the type combinations). We will see this pattern occur more frequently: Given one or two ArrayImgs of same or different type apply a pixel-wise function on them. Maybe we can have a more generic way for creating such classes? any idea?

to make this clear: this is not intended to be merged. I will redo the commit history after we agreed if the design is OK. I'm really nitpicking on the design here because I have no idea if this is good or not. Please simply start from the provided test-case and have a look.

We can introduce this command later!
Conflicts:
	src/main/java/net/imagej/ops/normalize/NormalizeImgRT.java
	src/main/java/net/imagej/ops/scalepixel/ScalePixelsIterableRT.java
* Remove RealType restriction on generics
We need to be more specific about what we want to create. the assumption
that the OpService actually can figure out what to create given the
input parameters may not always hold.
this implementation is easier to understand and even more flexible
@ctrueden ctrueden added this to the medium-priority milestone Sep 23, 2014
@ctrueden
Copy link
Member

@hinerm's work on the convert-numbers branch (see also #54) may impact this work. From our planning doc: "Could also have SJC converters that convert whole images, as well as single element type objects."

@ctrueden
Copy link
Member

@dietzc Unless you want feedback sooner, I will wait on this one till the January hackathon.

@dietzc
Copy link
Member Author

dietzc commented Nov 23, 2014

@ctrueden thats completely fine. I want to go over this stuff anyway as soon as the automatic "op-converters" are available (hackathon?!).

@dietzc dietzc closed this Feb 4, 2015
@dietzc
Copy link
Member Author

dietzc commented Feb 4, 2015

needs more polishing!

@dietzc dietzc deleted the converters branch October 13, 2016 08:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants