I am running a python-tensorflow-keras jupyter notebook on Colab, training a CNN on Caltech-256 images. The data is loaded from the Caltech site directly to the Colab area with a wget, and never appears on my PC. The notebook includes Tensorboard, and some Callbacks. Obviously, as I first upload the notebook to Colab, that will use some internet bandwidth. I would expect that the rest of the time there should be very little traffic - only enough to update my screen at the end of each epoch (every 600 seconds) or as I click on it. However, there is actually quite a lot of traffic - enough to impact the other people in my house significantly. I believe that the problem is with our upload speed (ie data going from my PC to Colab). I am using Firefox web browser. When I switch to Colab Playground mode, the issue disappears.
What is being uploaded, and why?
Is there any workaround?
I've found the answer here https://github.com/tensorflow/tensorboard/issues/3196
I don't totally understand it, but the workaround listed there works for me:
While the notebook is running, in the tensorboard display, click the settings cog (top right), and uncheck the auto-update box. (You then need to click the refresh icon whenever you want to update your graphs.)
This has to be repeated every time you open the notebook, but it's a small price to pay for family harmony.
Related
I used the Googl Colab to extract the tables from the images using Paddle OCR. It was working fine till last week. But from Monday onwards, the colab is crashing when I run the code to finding layout. Not sure what causes this issue.
Any Suggestions?
runtime crashes when I run this cell
Attached the link below
https://colab.research.google.com/drive/1ShBSvJSTyCOLkln0I9aq-oc5V5OrTRdE?usp=sharing
I have created a pdf viewer using react-pdf. When I display certain pdfs, the text is choppy and unreadable. I have tried zooming in and out of the document and it is choppy in different ways at different scales. Sometimes the text even looks okay at a certain scale after zooming out and then zooming back in.
(Sample at 1.5 scale)
(Sample at 1.6 scale)
At first, I thought it might be an issue with react-pdf, but I saw that react-pdf is basically a wrapper around PDF.js. I found that I can replicate the issue in the PDF.js demo page.
Unfortunately, I'm working with a pdf that contains identifying information, so I can't share the full pdf or full screenshot. I'll include as much as I can figure out to share.
What I have tried
My initial thought was that maybe the component was rendering small initially and then had issues scaling up. So I made the initial size really large, but that didn't fix it.
I made sure that standard fonts were included following the instructions on the react-pdf home page
I tried using pdf repair tools online to maybe fix the pdf itself. That didn't help.
I tried changing the renderMode to 'svg' as detailed in the Document api documentation. This was the most helpful fix, as it does render the text correctly, but it then makes it so the images on the pdf don't load.
Thanks for your help/suggestions.
If I can find a way to edit the pdf to not have sensitive information, I'll try to find a place to make it available for testing. I apologize that I cannot provide that at this time. I know it's difficult to give advice when you can't replicate it yourself. I'll work on that.
From a programming point of view there is only "Providing a standardFontDataUrl and disabling the font face" (see later), however it affects many pdf.js based code developers outputs, thus I consider as still "OnTopic"
This issue is still open in react-pdf, though I have seen it mentioned by other pdf.js users since mid year (MS or Chrome update ?) , so unsure if it is not a wider fail affecting Mozilla PDF.js code users.
https://github.com/wojtekmaj/react-pdf/issues/1010
https://github.com/wojtekmaj/react-pdf/issues/1025
There semes to be earlier reports back in Early March and then later suggestions to change win 10 drivers. However also reported by win 11 Pro users. PDF.js versions from 2.8.335 to 2.14.305, and it doesn't affect version 2.7.570. so partially down to updated versions ! But seen only in Chromium.
It is entirely possible that we started doing something that trips Chrome,
The symptoms seem to be hardware or settings orientated since it is reportedly seen on some identical groups of users but not affecting others.
toggling back and forth between single page and multi-page views the issue resolves. It also seems dependent on the resolution or appears on some machines and not others so it is a little tricky to repro.
I am not getting it personally, but a guy in my team get it.
Unclear which browsers are affected but looks like its a chromium / web kit rendering bug ?
Several browsers have been tested and only chrome faces this.
My colleague gets the same in Edge Version 101.0.1210.47 (Official build) (64-bit) and Brave (1.38.118 Chromium 101.0.4951.67) Will edit the issue
The suggested workaround is :-
Providing a standardFontDataUrl and disabling the font face fixes the issue.
if we disable Accelerated 2D canvas in chrome://flags then the preview appears nice and okay. But since this flag is on by default so user see the pixelated preview. Unless we ask them to turn off this flag.
Figured out that this only happens when hardware acceleration is enabled in your Chrome settings.
When its turned off the issue does not happen.
In address bar paste chrome://gpu or edge://gpu etc (its a long report of current onboard fixes) in my case (currently unconfirmed via reboot for my Edge) is showing Accelerated 2D canvas is unavailable: either disabled via blocklist or the command line. Disabled Features: 2d_canvas, thus I cannot see problems.
To change setting you can use
chrome://flags/#disable-accelerated-2d-canvas
but its a manual choice between options.
so on reboot I see
Graphics Feature Status
Canvas: Hardware accelerated
Canvas out-of-process rasterization: Disabled
but have little problem with the domo (except normal fuzzy text as pixels) so either Edge update or my hardware is not visibly affected or my default settings are reasonable.
This issue has been finally fixed in the latest version of react-pdf library. Check here: https://github.com/wojtekmaj/react-pdf/releases/tag/v6.2.2
I also faced the same error and I fixed it by setting render mode to canvas (earlier it was SVG) and scale value to more than 1. Try scale = 1.5
In Google's colab jupyter notebook I have a canvas object which displays nicely on the scree. Now I want to save it on the disk as a figure using toyplot:
import toyplot.pdf
toyplot.pdf.render(canvas, "fig.pdf")
Upon execution the code runs quitely and returns no error.
However, no file is saved nor a dialog is shown.
Using Chrome on Ubuntu.
Am I missing something?
There used to be an option in Google Colab under File called Update Drive preview. I no longer see that option and my previews are very out of date. I assumed if it was removed that maybe the preview was updated when saving, but that does not appear to be the case. The worst part is that I have renamed the files and the preview still shows the old filename along the top, which can be confusing. Is another way that I can make this update occur?
Edit:
It is important to note that I do not want the URL for sharing to change, so making a copy would not work as a solution.
The Update Drive preview is now available through the command palette in Colab which is available through Tools->command palette, [CMD/CTRL]+SHIFT+P, or in the menu along the left side of the notebook.
When I save changes to a html file, the browser refreshes the page quickly and correctly. The first time I save changes to a scss file, the page starts to reload, but stops without loading any of the style sheets (although it does load images). If I save it a second time, the page reloads fully. Thereafter, most I only need one save. However, sometimes I have to do a second save in order to get it working properly again.
I am running rails v4.2.5.1, guard v2.13.0, guard-livreload v2.5.1, chrome browser v48 with livereload extensions 2.1.0.
It turned out that when I upgraded by hard drive from a mechanical to a SSD drive, this problem stopped occuring. Maybe something was timing out.
Best to open issues like that in guard-livereload. There are lots of moving parts here. And there are debugging options on both sides.
If an SSD drive fixed things, your editor may have had a lot of plugins activated during save - and if the "total save time" is longer for multiple files, things can get wacky. It could be lots of issues, so it's best to open an issue and ask for help. (There are debugging tutorials in Wikis too).