Issues with image preview pane

[WesGilster]

Major Issues: "Project image on printer" button doesn't work. Add another token to browser cache querystring "&calibration=[number]" I consider this important because I'm using your "project image on printer" in combination with the calibration tool to determine my printed objects are sizing properly as a sanity check.

Minor Issues: Floating scrollbar on some screens Preview box window doesn't properly size when printer aspect ratio is "landscape"(x/y values are different than it's height) I'm not sure I trust the printer build area extents when I open the slacer.js integration. This might be because I haven't set the built the printer extents properly? When an image is too large for the printable area and is clipped, it continues to be cut off even when a subsequent translation would allow the clipped region to show properly. X/Y Density doesn't update on calibration completion It would be nice if slacer.js was started with the selected stl file (I'm guessing this is a feature request to slacer) Clicking on the printable twice will allow the preview window to appear even though it's not supported due to an incorrect file type or unstarted printer.

[jmkao]

Image preview was fixed in the the latest PR I picked up 2 days ago from @wilbur-shi, but I haven't generated a new build yet. I'll tag and create one later today.

Currently the SLAcer.js build area is calibrated purely from the DLP X and Y resolutions and the calibrated pixel density. The other dimensional properties in the machine confit are not used. That does mean that if a printer does no allow the full projected area to be printed, the area will be too big.

I'll take a look at the behavior with alternative aspect ratios.

[WesGilster]

Yeah, I think I'll need your code when you are ready because somehow I've gotten some of your front end code(without the backend) mixed in my dev branch and I've got a couple of nasty issues:

1. Clicking on a Printable causes an error that it can't find a customizer.
2. I don't have any way to go to the printer page after a printer has been started because it keeps forwarding to the controls page.

[jmkao]

Hmm... that's weird, you don't seem to have any of the code from the kudo3d branch. I just merged your repo into mine and it seems to work the same as before. It may be possible that your browser has some of the Kudo3D fork HTML and JS cached, which is not mixing well with the old backend. A Shift-reload should clear that.

[WesGilster]

Ahh, I'll bet that's the problem.

[WesGilster]

I'm loving this image preview. I'm not sure what I did without it.

I just noticed a pretty nasty issue in that it's actually doubling up on the first translation. You can see this in two different ways:

1. The image will become noticably darker due to applying the bulb mask a second time.
2. You'll see a larger jump in your first translation than the subsequent translations. This is generally only visible with 100px translations since the other are too small of increments

I know how it's happening, but the fix isn't too pretty right now. This method: org.area515.resinprinter.job.AbstractPrintFileProcessor.buildPreviewSlice(Customizer, File, Previewable, boolean)

will render the preview on line 348, but captures the image "after" image translations. The fix would be to capture the image before translations, but we don't have access to the image before that time...

[WesGilster]

Couple more questions:

1. Slacer doesn't seem to be bundled in as it's a dead link when I deploy. I know it was working at one point.
2. Are the install scripts ready for the repo rename to Photonic3d on prod and dev?

[jmkao]

1. To initialize and populate the SLAcer subproject, you need to do a git submodule init followed by git submodule update. I forgot to do this step in my repo as well. This won't affect push/pull's, it just makes sure that your local clone get the subproject contents and not just a reference to it.
2. Yes, the install scripts are ready for a repo rename.

[WesGilster]

Fixed the double transform problem. Not nearly as bad as I had imagined.

[WesGilster]

All other issues are fixed, but we've still got a nasty issue with the way we are performing offscreen image rendering. As I mentioned above, this has come up now because we allow x/y transforms and part of the image that was rendered offscreen now has to become placed onscreen. By that point, it's too late and the image has already been cropped. We probably need to start doing our rendering on the graphics context instead of a bufferedImage. It's also possible that we start increaasing our buffered image size to accommodate the full size of the rendering.

[WesGilster]

Ok, so all known bugs are fixed now. I found problem after problem after problem dealing with post transform area computation, invalid clipping regions, inappropriate creation of bufferedimages, scattered image rendering and inconsistant image caching. Almost all of these issues where due to my own making, due to having different ideas and different requirements as I started building each file processor. I ended up rewriting the entire rendering logic because of these issues and now all processors should have the same rendering engine, area/cost computation and geometry processing(if applicable). A side effect of this is that the model is rendered in the top left instead of the center of the build platform. I'm guessing this isn't a problem since we have the customizer for proper placement if they don't like where the image is placed.

I'll leave this bug, and #251 open for a few more days. If I don't hear anything I'll assume every one likes it.

[WesGilster]

I still had issues with this darn cache. The cache can now become directed by invalidating it anywhere from within the client. For now I'm doing it every time that the user browses to the printers page, but a better idea would be to invalidate it only after a printer save/start/stop/printer calibration.

[WesGilster]

Closed in cwh-1.0.0-beta3.